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
277,183
Declared platforms
0
Static risk flags
0
Last source update
2026-08-19
Source checked
2026-08-25

Decision brief

What it does: 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/b36e0829c6d0140e93cfef2ca599b1b07d4a7797/skills/requesting-code-review/SKILL.md at commit b36e0829c6d0140e93cfef2ca599b1b07d4a7797. 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 stars277,183SourceRepository 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
b36e0829c6d0140e93cfef2ca599b1b07d4a7797
License
MIT
Collected
2026-08-25
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

Frequently asked questions

What to verify before installation and use

What does the requesting-code-review source document cover?

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

How do I install requesting-code-review?

The source record exposes this install command: npx skills add https://github.com/obra/superpowers --skill "skills/requesting-code-review". Inspect the command and pinned source before running it.

Alternatives

Compare before choosing

Computed 987

event4u-app/agent-config

requesting-code-review

Use when asking for a review or creating a PR — self-review first, frame the right context, test plan included — even when the user just says 'open a PR' or 'ready to merge'.

Computed 9889

aAAaqwq/AGI-Super-Team

code-review-quality

Conduct context-driven code reviews focusing on quality, testability, and maintainability. Use when reviewing code, providing feedback, or establishing review practices.

Computed 9858

magnus919/agent-skills

software-architecture-analysis

Use this skill to reverse-engineer an existing software system, map its architecture, data flow, privacy posture, coupling, quality characteristics, and feature surface, then produce an evidence-grounded clean-room design document, PRD, or migration plan under new constraints. Use for codebase archaeology, implicit contract extraction, architecture health assessment, or decomposition-readiness analysis. Do not use for greenfield architecture design, direct code review, bug hunting, security audi

Computed 9724,921

alirezarezvani/claude-skills

adversarial-reviewer

Adversarial code review that breaks the self-review monoculture. Use when you want a genuinely critical review of recent changes, before merging a PR, or when you suspect Claude is being too agreeable about code quality. Forces perspective shifts through hostile reviewer personas that catch blind spots the author's mental model shares with the reviewer.