Code Reviewer

Bundled runtime

Before executing a CLI line below, replace its leading SSF with node "<plugin-root>/scripts/spec-superflow.mjs"; <plugin-root> is the absolute directory two levels above this file. Never run SSF literally or call an ssf from PATH.

Two responsibilities: reviewing the recorded Git range and acting on findings with technical rigor. Review according to the persisted policy; verify feedback before implementing it.

Part 1: Requesting Review

Mandatory: one whole-range review for Native final; one review per planned wave for wave and legacy plans. Avoid redundant per-task or final reviews of unchanged evidence. Optional: when stuck, before refactoring, after fixing complex bugs.

Procedure

1. Get the review range from recorded execution evidence. For final review resolve the base in order: the recorded state.review_base start anchor, then the review_base in the recorded isolation context, then git merge-base <target-branch> HEAD for a legacy/manual branch with an unambiguous target; head is git rev-parse HEAD. The CLI verifies this complete range. A failed final review retains the same base across fixes; wave repairs use the prior wave head. For a wave review use the recorded wave-start base. Never substitute HEAD~1; it misses earlier commits in multi-commit work.
2. For Native final, the current executor reviews the complete diff locally and writes the report; do not dispatch a reviewer subagent. For user-authorized SDD with wave review, dispatch at most one reviewer for that wave using skills/code-reviewer/code-reviewer-prompt.md. If dispatch is unavailable, review locally.
3. When dispatching, fill only [DESCRIPTION], [PLAN_OR_REQUIREMENTS], [BASE_SHA], [HEAD_SHA], [WAVE_ID], and [REVIEW_REPORT_FILE]. Do not send the whole planning bundle.
4. Write a non-empty report at .superpowers/sdd/reviews/<wave-id>.md, then record that path with SSF execution review <change-dir> --wave <wave-id> --base <base-sha> --head <head-sha> --report .superpowers/sdd/reviews/<wave-id>.md --verdict <pass|fail>. For schema-2 plans, failed receipts also require --issue <stable-finding-id> for the blocking defect being repaired; reuse its ID across retries. Other findings keep their own IDs in the report. Identical failed input cannot consume another attempt.