{ }
Resource profile / Requesting Code Review
About this skill

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

PACKAGE TRANSPARENCY

Inspect before installing

Source: obra · MIT · SHA-256 shown alongside the download.

6 files8453 ZIP bytes0 script/code files

License file included. A license and checksum are not a security certification. Review package instructions and scripts before running them.

View files and uncompressed sizes

An adaptation record is bundled. Inspect the declared changes and archived original before use. Review adaptation and original-file hashes →

Machine-readable installation guide →
SCENARIOS

Inputs, criteria and recorded outcomes

Records are supplied by the site administrator and bound to a specific package. They are not third-party safety certification. This page does not execute skills.

No published scenario records yet. Resource availability and download counts do not imply measured task performance.

Community reviews

★ New

Be the first to share your experience.

Sign in to leave a review →

More to explore

View all ↗