Requesting Code Review
Dispatches a reviewer subagent with isolated context to check your changes, instead of self-grading in the same session that wrote them
The skill addresses review after tasks, major features, and before merging, using an isolated-context reviewer subagent and severity-based follow-up to reduce defect propagation. Its audience and triggers are clear, but boundaries, fallback behavior when review fails, and adaptation for different project types are under-specified.
The procedure includes obtaining BASE_SHA and HEAD_SHA, filling a review template, processing Critical/Important/Minor findings, and requiring a read-only review, which supports some repeatability. The evidence does not define handling for unavailable subagents, insufficient Git history, incorrect ranges, a missing template, or incomplete results, and no automated behavior tests for this skill are shown.
The reviewer template explicitly requires read-only behavior and prohibits changes to the working tree, index, HEAD, or branch state; it also recommends a separate worktree for other revisions. However, the skill sends code changes, requirements, and Git diffs to a subagent without discussing sensitive-data redaction, user consent, access boundaries, external data flows, or rollback controls before applying feedback.
The skill asks the reviewer to inspect Git diffs, plan alignment, error handling, security, testing, and production readiness, and to provide file/line references, impact, and fixes. The static material shows no execution tests, independent evaluation, or real review record for this skill; test and merge assessments in the template are requested outputs rather than verified facts, and fact/inference separation is not explicit.
Triggers, the three-step procedure, placeholders, and expected review output are understandable. Missing details include the concrete subagent dispatch interface and configuration, behavior for missing inputs, cost and latency expectations, cross-harness compatibility, troubleshooting, and a clear exit condition when review cannot be completed.
The skill has a stable name and description, and the adjacent template defines a reasonably complete review format. The selected skill has no version, changelog, maintainer commitment, response expectation, or update path; repository MIT licensing and version metadata are contextual only, and publisher provenance is not verified by the curated enterprise registry.
- Before sending code, requirements, and Git diffs, check for credentials, personal data, and confidential material, and define the subagent's access boundaries.
- Do not treat the template's requested claims such as tests passing or merge readiness as verified facts; this assessment did not execute the skill or perform independent testing.
- Add explicit stop, retry, and human-handoff procedures for unavailable reviewers, invalid Git SHAs, a missing template, or conflicting feedback.
What it does & when to use it
After finishing a task, a major feature, or before merging to main, this dispatches a reviewer subagent that receives only the necessary context — description, requirements, start/end commit SHAs — rather than letting the same session that wrote the code review itself. That keeps the review focused on the work product rather than the coordinator's thought process, and doesn't eat into the coordinator's own context. The doc is short: when review is mandatory, how to dispatch, and how to act on feedback.
Grabs the start and end commit SHAs; dispatches a general-purpose subagent using the code-reviewer.md template, filling in four placeholders — description, plan/requirements, base SHA, head SHA; on the reviewer's response, acts by severity — fixes Critical issues immediately, fixes Important issues before proceeding, notes Minor issues for later; allows pushing back with technical reasoning if the reviewer's verdict seems wrong. Lists mandatory-review moments (after each task in subagent-driven development, after a major feature, before merging to main) and optional-but-valuable ones (when stuck, before refactoring as a baseline, after fixing a complex bug).
- After each task in subagent-driven-development, dispatch a review subagent before moving to the next task
- Before merging to main, get an isolated-context review pass rather than self-reviewing your own diff
- Request a review deliberately when stuck, to get a fresh perspective from a subagent
Pros & cons
- The reviewer subagent gets a deliberately constructed context, not the coordinator's full session history — keeps the review focused on the actual change
- Gives a concrete severity-handling order (fix Critical now / fix Important before proceeding / log Minor for later), preventing "known issue, deal with it eventually" from turning into indefinite delay
- Explicitly allows technical pushback against the reviewer subagent's verdict — not a one-way "reviewer always wins" arrangement
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- Depends on the code-reviewer.md template file living alongside the skill — if only the top-level SKILL.md is read without the template, the workflow is incomplete
- Review quality depends on the reviewer subagent's own capability and how complete the context handed to it is — a sloppily filled template produces a shallow review
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Triggered automatically or manually at task-completion checkpoints. Core action: grab the git SHA range, fill in the code-reviewer.md template, dispatch the subagent, then handle the returned feedback by severity.
Compared to similar skills
Compared to no independent review — the model checking its own work in the same context it wrote it in — this skill's "independent subagent + deliberately constructed review context" gets closer to the isolation of a real team code review. Compared to the two-stage review baked into subagent-driven-development, this skill is more general-purpose and can be invoked standalone at any checkpoint in any workflow.