requesting-code-review by obra

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 | 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

Third-party checks

No alerts12d5 checks · Risk SAFE

Gen Agent Trust Hub12d
The skill provides a structured workflow for performing code reviews via subagents. It is intended for development use and includes instructions for maintaining a clean and restricted review environment. The primary security consideration is the potential for indirect prompt injection, as the skill processes un-sanitized code diffs which could contain malicious instructions designed to influence the reviewer subagent's findings.
Socket12d
No alerts
Snyk12d
Risk: LOW · No issues
Runlayer6mo
2 files scanned · No issues
ZeroLeaks5mo
Score: 93/100 · 2 sections analyzed

What it does

Dispatches a code reviewer subagent to evaluate work before merge, passing only the diff and requirements without session history to keep the reviewer focused. Targets subagent-driven development workflows where tasks are completed in sequence and each requires verification before proceeding to the next.

Generated from the current SKILL.md.

Frequently asked

When should I request a code review with this skill?

Mandatory after each task in subagent-driven development, after completing major features, and before merging to main. Optional but valuable when stuck, before refactoring, or after fixing complex bugs.

Does the reviewer get my full agent session history?

No. The reviewer receives only precisely crafted context—the description, requirements, and git diff between two SHAs—keeping them focused on the work product and preserving your own context for continued work.

How do I dispatch the code reviewer subagent?

Use the Task tool with type `general-purpose` and fill the template at `code-reviewer.md`, providing a brief description, plan/requirements, BASE_SHA, and HEAD_SHA from your git history.

What should I do if the reviewer's feedback is wrong?

Push back with technical reasoning and show code or tests that prove your implementation works, then request clarification if needed.

Generated from the current SKILL.md. These answers refresh after source changes.

/requesting-code-review

SKILL.md