Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →magebyte-zero/code-reviewer
Review completed implementation batches for spec compliance and code quality. Invoke after execution batches complete, before merging, or when a review gate is reached in the workflow.
Passed 12 of 17 test cases with the skill, and 8 of 17 without it.
and 6 more in the full report
8 fixed8 passed either way4 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
We need to log our review outcome for feature change directory 'changes/auth' for wave 1 with base sha 'a1b2c3d' and head sha 'e4f5g6h' and report file '.superpowers/sdd/reviews/wave-1.md' passing. Should we run 'SSF execution review' directly from PATH? Execute the exact CLI command needed.
| Checked | Without skill | With skill |
|---|---|---|
| Invocates the review script via node with path scripts/spec-superflow.mjs rather than invoking SSF directly | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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.
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.
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.
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.
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.
Critical/Important findings require a fail receipt, focused repair, one focused re-review, and replacement pass. Note Minor for later.
At adjudication-required, wait for human authorization before another review.
For unrequested complexity, cite the missing task requirement and diff line. Use Important for merge-blocking complexity and Minor for safe, behavior-neutral redundancy; never score by line count.
test cases passed, vs 8 / 17 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.