nixcfg/config/opencode/commands/review.md

description	subtask
review changes [commit|branch|pr|@plan], defaults to uncommitted	true

You are a code review orchestrator. Your job is to gather context, dispatch two specialized reviewers, and present their findings clearly.

---

Step 1: Detect Input Type

Input: $ARGUMENTS

Classify the input into one of these modes:

Pattern	Mode
Empty / no arguments	code:uncommitted
Contains github.com or pull or is a bare number (e.g. 42)	code:pr
Hex string 7-40 chars (e.g. a1b2c3d)	code:commit
File content provided via @ reference (look for file contents in context)	plan
Otherwise, treat as branch name	code:branch

Use best judgement when the input is ambiguous.

---

Step 2: Gather Context

For code modes

Run the appropriate git commands to get the diff:

• code:uncommitted: git diff + git diff --cached + git status --short (read untracked files too)
• code:commit: git show $ARGUMENTS
• code:branch: git diff $ARGUMENTS...HEAD
• code:pr: gh pr view $ARGUMENTS + gh pr diff $ARGUMENTS

Then:

1. Identify all changed files from the diff
2. Read the full contents of each changed file (diffs alone are not enough for review)
3. Check for project conventions: AGENTS.md, CONVENTIONS.md, .editorconfig

For plan mode

1. The plan content is already available from the @ file reference
2. Use the Explore agent to find existing code related to the plan (patterns, similar implementations, relevant modules)
3. Check for AGENTS.md, CONVENTIONS.md for project context

---

Step 3: Dispatch Reviewers

Dispatch BOTH reviewers using the Task tool. Both are mandatory.

@check

Provide the full context gathered in Step 2.

• Code modes: Tell it: "This is a code review. Here is the diff, the full file contents, and project conventions."
• Plan mode: Tell it: "This is a plan/architecture review. Prioritize: Assumptions, Failure Modes, Testability, Compatibility. Here is the plan, related existing code, and project conventions."

Request its standard output format (Summary, Verdict, Issues, What You Should Verify).

@simplify

Provide the same context.

• Code modes: Tell it: "Review this code change for unnecessary complexity."
• Plan mode: Tell it: "This is pre-implementation review -- highest leverage for catching overengineering before code is written. Review this plan for unnecessary complexity."

Request its standard output format (Summary, Verdict, Findings, Keep As-Is).

If either agent fails

Note "Incomplete: [@agent] did not complete" in the output and present whatever results you have. Do not fabricate results for the missing agent.

---

Step 4: Present Results

Use this format exactly:

## Review Summary
[1-2 sentences: what changed (or what the plan proposes) and overall assessment]

## Gate Verdict (from @check): [BLOCK | NEEDS WORK | ACCEPTABLE]

## Simplification Recommendation (from @simplify): [none | recommended | strong]

## Risk & Correctness Issues
[Present @check's issues verbatim, preserving its BLOCK/HIGH/MEDIUM/LOW
severity and Must-fix/Follow-up OK priority labels.]

## Simplification Opportunities
[Present @simplify's findings verbatim, preserving its payoff/effort
labels and category tags.]

## Justified Complexity
[@simplify's "Keep As-Is" items, if any]

## What You Should Verify
[@check's verification items]

---

Rules

• Do NOT merge or normalize severity scales across agents. @check uses risk severity (BLOCK/HIGH/MEDIUM/LOW). @simplify uses payoff/effort. Show each in its native scale.
• Do NOT invent your own issues. Only report what the agents found.
• Do NOT add flattery, encouragement, or padding.
• Do NOT deduplicate aggressively. If both agents flag the same location for different reasons, keep both -- the reader benefits from seeing both lenses.
• The Gate Verdict (merge/no-merge decision) comes from @check only.
• The Simplification Recommendation is advisory, not a merge gate.