| name | code-review |
| description | Use when reviewing code changes with explicit stage, target, and focus so own-code checks and others’ PR reviews stay distinct but share one contract. Uses write tools, shell execution, and may spawn subagents. Invoke with enable_write_tools=true and enable_subagent_tools=true. |
| status | draft |
Code Review Workflow
Trigger
Start when code changes need review before commit, before PR, during PR review, or while responding to review feedback.
Inputs
review_target — own | others
review_stage — pre-commit | pre-pr | pr | post-feedback
input_shape — diff | branch | pr | comments
focus — correctness | regression | security | scope | docs | mixed
validate — expected review output or follow-up path
Purpose
Catch correctness, regression, scope, and evidence problems before the code ships or before feedback is answered.
Four Points
- WHAT: Produce an actionable review of the code changes.
- HOW: Read the relevant diff/context, compare against specs/docs/tests, classify findings by severity and evidence.
- DON'T WANT: Generic praise, style-only noise, or comments without proof.
- VALIDATE: Review output names concrete findings or explicitly states none were found in the checked scope.
Behavior Scenario
- Given the proposed code change and its claimed behavior
- When the relevant diff, tests, and supporting docs are reviewed
- Then the review identifies real issues or explicitly confirms the checked scope is clear
TDD Mode
n/a for review-only runs. If review feedback reveals missing behavior coverage, point back to the required TDD mode for the implementation workflow.
Steps
- Confirm review target, stage, focus, and source material.
- Read the diff and the smallest surrounding context needed to judge it.
- Check behavior/test evidence against the claimed outcome.
- Classify findings by severity, evidence, and whether they are questions or change requests.
- Return the review summary and the smallest concrete next action.
Adapters
- Claude Code: markdown workflow only; reviewer/feedback-review style work stays in existing tools and docs.
- OpenCode: markdown workflow only; no workflow runtime claims.
- OMP/Pi: markdown-only guidance.
Exit Gate
Stop only when the review scope is explicit, every non-trivial finding is evidence-backed, and the next action is clear.
Failure
Stop and report when the diff/context is incomplete, the claimed behavior has no observable evidence, or the requested verdict would require guessing.