Requesting Code Review

tl;dr: the dispatching half of the Superpowers review pair. It tells the agent to spawn a fresh general-purpose subagent, hand it the diff range (BASE_SHA..HEAD_SHA) plus a one-paragraph description and the plan/requirements, and get back a Critical / Important / Minor triage. Core rule: hand the reviewer precisely crafted context — never your session history.

What it actually does

SKILL.md (obra/superpowers, fetched 2026-09-10) puts the core principle in one line at the top: review early, review often. It then names the moments that are mandatory versus optional:

The mechanics are a three-step recipe the agent runs:

1. Get git SHAs. BASE_SHA=$(git rev-parse HEAD~1) (or origin/main) and HEAD_SHA=$(git rev-parse HEAD). Not eyeballed, not “the diff since my last commit” — named commits.
2. Dispatch a general-purpose subagent filling the template at code-reviewer.md. Four placeholders: {DESCRIPTION}, {PLAN_OR_REQUIREMENTS}, {BASE_SHA}, {HEAD_SHA}.
3. Act on feedback. Fix Critical immediately. Fix Important before proceeding. Note Minor for later. Push back if the reviewer is wrong — with reasoning.

The skill spends more space on what not to do. The named rationalizations table:

The red-flag list is short and concrete: never skip review because “it’s simple”, never ignore Critical issues, never proceed with unfixed Important issues, never argue with valid technical feedback. Push-back, if it happens, demands code/tests that prove it works.

When to load it vs. the receiving side

The frontmatter description is the trigger:

Use when completing tasks, implementing major features, or before merging to verify work meets requirements.

This skill is the dispatch side. The receive side — processing the feedback the reviewer gives you — is a separate skill: Receiving Code Review. Pair them. The dispatch skill produces the review; the receive skill decides what to do with it.

The skill also makes the boundary with the larger Superpowers workflow explicit. It hangs off executing-plans (or the subagent variant): once a task is green, dispatch the review before going on to the next task. A code-reviewer.md template lives next to this SKILL.md in the repo — the published skill expects the surrounding skills/requesting-code-review/ tree, not just SKILL.md in isolation.

Install

The upstream README does not document npx skills add obra/superpowers. Install is per-harness and the README enumerates thirteen of them. The most common paths:

# Claude Code — official Anthropic marketplace
/plugin install superpowers@claude-plugins-official

# Claude Code — Superpowers marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# Codex CLI — official Codex marketplace
/plugins
# search: superpowers → Install Plugin

# Cursor
/add-plugin superpowers

# Gemini CLI
gemini extensions install https://github.com/obra/superpowers

# OpenCode — host fetches install doc itself
# Say: "Fetch and follow instructions from
#       https://raw.githubusercontent.com/obra/superpowers/main/.opencode/INSTALL.md"

# Antigravity
agy plugin install https://github.com/obra/superpowers

If your host only watches a local SKILL.md, clone the repo and drop the skill folder:

git clone https://github.com/obra/superpowers
# place at any path your host's skill loader watches:
#   ~/.claude/skills/requesting-code-review/SKILL.md
#   .claude/skills/requesting-code-review/code-reviewer.md
#   .claude/skills/requesting-code-review/SKILL.md

The published SKILL.md references code-reviewer.md as a sibling template. Install the whole skills/requesting-code-review/ directory, not just SKILL.md.

Gotchas

• The reviewer gets the diff range, not the session. The whole skill sits on that distinction. Anyone dispatching with “here’s what I did over the last 30 minutes…” breaks the model — the reviewer ends up evaluating your reasoning instead of the change.
• general-purpose is the named subagent type. Not code-reviewer, not a custom agent, not the same session. SKILL.md is explicit about this.
• SHAs are mandatory, not optional. “Diff since last commit” is wrong; HEAD moved since you started thinking. The recipe is git rev-parse, full stop.
• Three-bucket triage is fixed. Critical / Important / Minor come back from the reviewer; the dispatch skill decides which to fix now, before merge, and later. Re-bucketing the triage (“everything is Minor”) is the failure mode.
• Pushback must come with evidence. “Show code/tests that prove it works” — feelings are not pushback.
• Confused with executing-plans. requesting-code-review dispatches a reviewer mid-plan. executing-plans walks the plan tasks. The plans skill calls code review out as one of the checkpoints between tasks, not as a replacement for plan walking.
• sandbox_test.verdict: untested — we read SKILL.md and the README; we did not dispatch a reviewer subagent in the sandbox.

Related: Receiving Code Review (obra/superpowers) — the receive half of the same review loop; Executing Plans (obra/superpowers) — the workflow this skill checks in at between tasks; Brainstorming (obra/superpowers) — the upstream HARD-GATE that produces the plan that reviewers will read against.