Requesting a Focused Code Review

What it does

This Superpowers workflow makes review context deliberate. The reviewer receives a concise implementation description, plan or requirements and verified base/head commits, rather than the coordinator’s entire conversation. Its companion template asks for read-only inspection of the checkout, specific file-and-line findings and an explicit readiness assessment. It also asks reviewers to state behavior they considered but declined to judge, exposing gaps that a narrow specification might otherwise hide. The selected source expects a reviewer subagent facility.

When to use it

• Review a completed feature against its approved behavior before merge.
• Catch integration errors between tasks while the implementation is still small.
• Obtain an independent inspection of a difficult refactor or bug fix.

Step-by-step workflow

1. Identify the exact base and head commits covering the intended change; avoid an arbitrary last-commit range.
2. Prepare the implementation summary, requirements and relevant test evidence without copying unrelated session history.
3. Dispatch the read-only reviewer using the source template and the precise range.
4. Evaluate concrete findings by actual impact, fixing critical and important issues and questioning unsupported conclusions.
5. Verify corrections and report readiness, remaining limitations and any consciously deferred minor findings.

Example request

Use requesting-code-review for the billing export change between the verified feature-base and current HEAD. Give the reviewer the approved requirements and test commands, not our full chat. Ask for read-only inspection of file permissions, partial-write failure, CSV escaping and backward compatibility. Require file:line evidence and a clear merge-readiness verdict. Do not let the review modify this checkout or publish comments externally.

Worked example

A feature spread over four commits cannot be reviewed reliably with HEAD~1 as its base. The coordinator should use the known branch starting point and include all four commits. If the reviewer finds that quoted customer names break CSV output, the finding needs the relevant line and a reproducible input. Fixing it should add or run a behavioral case; a revised diff alone does not prove the output is now parseable.

What you get

A scoped independent review containing strengths, severity-ranked findings, recommendations and a reasoned readiness assessment.

How to evaluate the result

• The review covered the whole intended change range and actual requirements.
• Each actionable finding has evidence, consequence and a technically plausible correction.
• Material fixes have fresh verification; the final verdict states unresolved risks.

What you need

A readable Git change range, explicit requirements and a harness supporting the reviewer workflow. The reviewer needs access to necessary code and tests, with secrets excluded from its context.

Setup and activation

The publisher documents separate installation routes for Claude Code, Codex App and CLI, Cursor and other harnesses. Use the README for your exact client; installing the whole Superpowers framework can activate additional workflows automatically. Preserve this skill’s companion files and relative references. Review and security-scan the exact selected version before installation. This directory only reviews sources; it has not installed, executed or tested this skill on those clients. Retain code-reviewer.md with the skill. Its read-only and no-recursive-delegation boundaries are part of the reviewed workflow.

Limits and considerations

A fresh model is another reviewer, not a guarantee of independence from common model errors. The coordinator remains responsible for validating claims and deciding actual severity. Review scope should include reasonable failure behavior even when the specification is silent. Sending a review to another agent does not authorize posting to GitHub or changing branch state.

Related workflows

• Use receiving-code-review to evaluate returned feedback before edits.
• Use finishing-a-development-branch after review and verification are complete.

License and reuse

MIT, copyright 2025 Jesse Vincent. Preserve the copyright and permission notice when redistributing substantial source portions; inspect separately supplied dependencies and assets under their own terms.

Further reading

• Reviewed skill version (immutable commit)
• Publisher setup, compatibility and telemetry notes
• Reviewed MIT license