requesting-code-review
byobra· 95 skills
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
How to install requesting-code-review?
obra/superpowers/requesting-code-review
$npx -y skills add obra/superpowers --skill requesting-code-reviewInstalls into the current project.
›Prefer a prompt? Paste this to your agent
Run `npx skills use "https://github.com/obra/superpowers" --skill "obra/superpowers/requesting-code-review"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.
Use the skills in "https://github.com/obra/superpowers" that are relevant to the current task. Run `npx skills add "https://github.com/obra/superpowers"` and select the relevant skills, then follow their instructions.
SKILL.md
| 1 | # Requesting Code Review |
| 2 | |
| 3 | Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. |
| 4 | |
| 5 | **Core principle:** Review early, review often. |
| 6 | |
| 7 | ## When to Request Review |
| 8 | |
| 9 | **Mandatory:** |
| 10 | - After each task in subagent-driven development |
| 11 | - After completing major feature |
| 12 | - Before merge to main |
| 13 | |
| 14 | **Optional but valuable:** |
| 15 | - When stuck (fresh perspective) |
| 16 | - Before refactoring (baseline check) |
| 17 | - After fixing complex bug |
| 18 | |
| 19 | ## How to Request |
| 20 | |
| 21 | **1. Get git SHAs:** |
| 22 | ```bash |
| 23 | BASE_SHA=$(git rev-parse HEAD~1) # or origin/main |
| 24 | HEAD_SHA=$(git rev-parse HEAD) |
| 25 | ``` |
| 26 | |
| 27 | **2. Dispatch code reviewer subagent:** |
| 28 | |
| 29 | Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md) |
| 30 | |
| 31 | **Placeholders:** |
| 32 | - `{DESCRIPTION}` - Brief summary of what you built |
| 33 | - `{PLAN_OR_REQUIREMENTS}` - What it should do |
| 34 | - `{BASE_SHA}` - Starting commit |
| 35 | - `{HEAD_SHA}` - Ending commit |
| 36 | |
| 37 | **3. Act on feedback:** |
| 38 | - Fix Critical issues immediately |
| 39 | - Fix Important issues before proceeding |
| 40 | - Note Minor issues for later |
| 41 | - Push back if reviewer is wrong (with reasoning) |
| 42 | |
| 43 | ## Example |
| 44 | |
| 45 | ``` |
| 46 | [Just completed Task 2: Add verification function] |
| 47 | |
| 48 | You: Let me request code review before proceeding. |
| 49 | |
| 50 | BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}') |
| 51 | HEAD_SHA=$(git rev-parse HEAD) |
| 52 | |
| 53 | [Dispatch code reviewer subagent] |
| 54 | DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types |
| 55 | PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md |
| 56 | BASE_SHA: a7981ec |
| 57 | HEAD_SHA: 3df7661 |
| 58 | |
| 59 | [Subagent returns]: |
| 60 | Strengths: Clean architecture, real tests |
| 61 | Issues: |
| 62 | Important: Missing progress indicators |
| 63 | Minor: Magic number (100) for reporting interval |
| 64 | Assessment: Ready to proceed |
| 65 | |
| 66 | You: [Fix progress indicators] |
| 67 | [Continue to Task 3] |
| 68 | ``` |
| 69 | |
| 70 | ## Common Rationalizations |
| 71 | |
| 72 | | Excuse | Reality | |
| 73 | |--------|---------| |
| 74 | | "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. | |
| 75 | | "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. | |
| 76 | |
| 77 | ## Red Flags |
| 78 | |
| 79 | **Never:** |
| 80 | - Skip review because "it's simple" |
| 81 | - Ignore Critical issues |
| 82 | - Proceed with unfixed Important issues |
| 83 | - Argue with valid technical feedback |
| 84 | |
| 85 | **If reviewer wrong:** |
| 86 | - Push back with technical reasoning |
| 87 | - Show code/tests that prove it works |
| 88 | - Request clarification |
| 89 | |
| 90 | See template at: [code-reviewer.md](code-reviewer.md) |
Related
6 picksType
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.Jul 2026
- domain-modelingBuild and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision,…Jul 2026
- caveman-reviewUltra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix.Jul 2026
- codebase-designShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a…Jul 2026
- code-reviewReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding…Jul 2026
- resolving-merge-conflictsUse when you need to resolve an in-progress git merge/rebase conflict.Jul 2026
