| name | code-reviewing |
| description | Two-axis code review of a diff — Standards (is the code well built?) and Spec (does it actually solve the stated problem?) — run as parallel sub-agents and reported separately, never merged. Use when reviewing implementation output (a phase, a wave, a branch, a PR), when the user says "review the code", "review the diff", "review this phase", or when another desplega skill (implementing, v-implementing, verifying, delegate-work) calls for a per-phase or final code review. For reviewing DOCUMENTS (plans, research, brainstorms), use desplega:reviewing instead. |
code-reviewing
You are reviewing a code diff on two independent axes:
- Standards — is the code well built? Judged against repo standards first, then the
desplega:engineering-standards baseline.
- Spec — does it do the right thing? Judged against the strongest available statement of intent.
The axes are reviewed by separate parallel sub-agents and reported under separate headings, never merged or reranked. Code that follows every standard but implements the wrong thing must show as Standards-pass / Spec-fail — averaging the axes is how wrong-but-pretty code ships.
Findings are NEVER produced in the main session. The orchestrator wrote or supervised this code — it is biased toward believing the work is done and reading the diff as intended rather than as written. Both axes always run as fresh sub-agent contexts (route per desplega:delegate-work), even for small diffs, even when the session "already knows" the code. The orchestrator's job is the join afterwards: dedupe, verify findings against the code, discard false positives, deliver the verdict — it judges findings, it does not generate them.
Step 1: Pin the diff
Fix the review target explicitly — never review "recent changes" by vibes:
- Phase/step review:
git diff <commit-before-phase>...HEAD (or the phase's commit range)
