requesting-code-review

Use it when: a task or feature is done, before merging, or when you're stuck and want fresh eyes
It does: sends a reviewer subagent the commit range and the plan, with none of the session's history
You get: strengths, issues graded Critical, Important or Minor with file and line, and a verdict on whether it's ready to merge
Then: the agent fixes Critical issues at once and Important ones before going on, notes Minor ones, and argues back with code or tests when the reviewer is wrong
Unlike receiving-code-review: which covers how to act on feedback you've been given; this one asks for the review

Skill 8 of 14 in the Superpowers bundle · Before it: test-driven-development · After it: receiving-code-review

TLDR

The agent fills the reviewer prompt that ships with the skill with what was built, what it was meant to do, and the first and last commits of the work, then starts a subagent with it. The reviewer reads the diff without changing the checkout or starting reviewers of its own. It checks that the code matches the plan, then its quality, architecture, tests and readiness for production. Where the spec says nothing, it judges by what a reasonable user would expect. It also names anything it decided was out of scope, so the agent can rule on it rather than lose it. subagent-driven-development and executing-plans use the same reviewer prompt for their final review of the whole branch.

Summarizes the skill at bb92a77.

npx skills add https://github.com/obra/superpowers --skill requesting-code-review

skills.sh page · Source on GitHub · All skills from obra/superpowers

Installs: 233,838 on skills.sh, Sep 21, 2026
Repo stars: 289,267 obra/superpowers
First seen: Jan 19, 2026 on skills.sh

Weekly installs

6.4K

-12% over 8 weeks · week to Sep 21

Weekly values

Week to	Installs
Aug 3	7,311
Aug 10	6,787
Aug 17	6,711
Aug 24	6,840
Aug 31	6,184
Sep 7	6,650
Sep 14	6,141
Sep 21	6,414

Category	category:debugging category:software-engineering Find root causes, review code and test what you built. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:none Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code.
Needs	needs:subagents Relies on the agent being able to spawn subagents.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	code-review multi-agent agent-workflows

SKILL.md

From obra/superpowers at bb92a77. Checked daily, last changed Oct 20, 2026.

Frontmatter

name: requesting-code-review
description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Requesting Code Review

Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.

Core principle: Review early, review often.

When to Request Review

Mandatory:

After each task in subagent-driven development
After completing major feature
Before merge to main

Optional but valuable:

When stuck (fresh perspective)
Before refactoring (baseline check)
After fixing complex bug

How to Request

1. Get git SHAs:

BASE_SHA=$(git rev-parse HEAD~1)  # or: git merge-base origin/main HEAD
HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch code reviewer subagent:

Dispatch a general-purpose subagent, filling the template at code-reviewer.md

Placeholders:

{DESCRIPTION} - Brief summary of what you built
{PLAN_OR_REQUIREMENTS} - What it should do
{BASE_SHA} - Starting commit
{HEAD_SHA} - Ending commit

3. Act on feedback:

Fix Critical issues immediately
Fix Important issues before proceeding
Note Minor issues for later
Push back if reviewer is wrong (with reasoning)

Example

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | cut -d' ' -f1)
HEAD_SHA=$(git rev-parse HEAD)

[Dispatch code reviewer subagent]
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

Common Rationalizations

Excuse	Reality
"I'll just review the diff myself instead of dispatching a reviewer"	You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you.
"The reviewer needs my whole session history to understand the change"	Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process.

Red Flags

Never:

Skip review because "it's simple"
Ignore Critical issues
Proceed with unfixed Important issues
Argue with valid technical feedback

If reviewer wrong:

Push back with technical reasoning
Show code/tests that prove it works
Request clarification

See template at: code-reviewer.md