Requesting Code Review

by obra5bf4e7801107No license290K starsListed Sep 23, 2026Updated Sep 23, 2026Repository updated yesterday

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

Instructions only

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:

bash

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

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

2. Dispatch code reviewer subagent:

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

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 | awk '{print $1}')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]

[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 | awk '{print $1}')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 [blocked]

Source and attribution

Source:obra/superpowersinskills/requesting-code-reviewat commit5bf4e78

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from obra/superpowers

Writing Plans

obra

Use when you have a spec or requirements for a multi-step task, before touching code

Awaiting classification290Kupdated yesterday

Verification Before Completion

obra

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Awaiting classification290Kupdated yesterday

Using Superpowers

obra

Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions

Awaiting classification290Kupdated yesterday

Using Git Worktrees

obra

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Awaiting classification290Kupdated yesterday

Test Driven Development

obra

Use when implementing any feature or bugfix, before writing implementation code

Awaiting classification290Kupdated yesterday

Receiving Code Review

obra

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Awaiting classification290Kupdated yesterday