Source profileQuality 66/100

obra/superpowers/skills/requesting-code-review/SKILL.md

requesting-code-review

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

Source repository stars
262,331
Declared platforms
0
Static risk flags
0
Last source update
2026-07-24
Source checked
2026-07-28

Decision brief

What it does—and where it fits

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

Best for

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

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/obra/superpowers --skill "skills/requesting-code-review"
Safe inspection promptEditorial

Inspect the Agent Skill "requesting-code-review" from https://github.com/obra/superpowers/blob/3dcbd5c4b48e02263fbf4a3c01e3fe4f81d584d9/skills/requesting-code-review/SKILL.md at commit 3dcbd5c4b48e02263fbf4a3c01e3fe4f81d584d9. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    When to Request Review

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

    After each task in subagent-driven developmentAfter completing major featureBefore merge to main
  2. 02

    How to Request

    2. Dispatch code reviewer subagent:

    {DESCRIPTION} - Brief summary of what you built{PLANORREQUIREMENTS} - What it should do{BASESHA} - Starting commit
  3. 03

    Example

    Review the “Example” section in the pinned source before continuing.

    Review and apply the “Example” source section.
  4. 04

    Common Rationalizations

    Review the “Common Rationalizations” section in the pinned source before continuing.

    Review and apply the “Common Rationalizations” source section.

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score66/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars262,331SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
obra/superpowers
Skill path
skills/requesting-code-review/SKILL.md
Commit
3dcbd5c4b48e02263fbf4a3c01e3fe4f81d584d9
License
MIT
Collected
2026-07-28
Default branch
main
View the original SKILL.md

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 origin/main
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

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

Alternatives

Compare before choosing