code-review

/code-review — Implementation Code Review

⚠️ CONTRACT — READ FIRST

This skill's entire value comes from dispatching four intent-isolated sub-agents in parallel and synthesizing their independent reports. You are the orchestrator.

You MUST:

1. Dispatch all four sub-agents via the Task tool, using their plugin-namespaced names: sdd-planner:drift-detector, sdd-planner:quality-scanner, sdd-planner:spec-compliance, sdd-planner:blind-spot-finder.
2. Dispatch them in parallel — a single message containing the four built-in Task tool calls, plus one additional Task call for each matching project review lane (see Step 2e and Step 3).
3. Give each sub-agent only the inputs for its lane. See Step 3 below for the exact input map. Passing extra context destroys the intent isolation that makes the review worthwhile.
4. Wait for all dispatched lanes (the four built-ins plus any project lanes) to return, then synthesize.

You MUST NOT:

1. Read the full diff, the phase doc contents, spec contents, or design contents in the primary context and write findings yourself. That is a single-pass review cosplaying as a four-lane review. It is the bug this contract exists to prevent.
2. Skip the Task dispatch because "you already know the answer" after loading context. The answer you'd produce is exactly the single-pass review this skill exists to replace.
3. Fall back to self-synthesis if a Task dispatch fails. If dispatch fails, STOP and return a loud error to the user describing which sub-agent failed and why. Do not silently continue.
4. Use bare sub-agent names (drift-detector, quality-scanner, etc.) for the four built-in lanes in Task calls — plugin agents require the sdd-planner: prefix or they will not resolve. (Project lanes are the exception — they resolve by bare name; see the external-lanes block below.)

External review lanes (best-effort, additive). Beyond the four, a project can plug in its own specialized lanes via the socket defined in shared/review-lanes.md (e.g. a read-only .claude/agents/sql-reviewer.md carrying reviewLane: true). These are additive, read-only, and never abort the four:

• The four built-ins are the floor and always run. A project lane only ever adds findings — never removes, replaces, or weakens a built-in lane's inputs or dispatch.
• A project lane that fails to dispatch, errors, or is malformed is recorded and dropped — never aborts the four. The strict "STOP on dispatch failure" rule in this contract applies to the four built-ins only. Synthesis proceeds over the four plus whatever project lanes returned. (Lane responsiveness is the project's responsibility — the socket dispatches and waits; it imposes no timeout, so a lane that hangs will hold up the review.)
• Failure is not silent: a declared lane that didn't run degrades the verdict (the Output Format's Lane status line — Alignment itself always reflects the returned lanes' findings), and an opt-in required: true lane that didn't run forces Lane status to BLOCKED (it gates the verdict, not the floor). The verdict is computed from the four plus any successful project lanes.
• Lanes execute repo-supplied instructions with session tool access, so /code-review confirms discovered lanes with the user before dispatch when the target repo isn't the session's own project.