home / skills / obra / superpowers / requesting-code-review

requesting-code-review skill

/skills/requesting-code-review

This skill helps you request timely code reviews to catch issues early, ensure requirements are met, and guide fixes before merging.

npx playbooks add skill obra/superpowers --skill requesting-code-review

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
2.6 KB
---
name: requesting-code-review
description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
---

# Requesting Code Review

Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.

**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:**
```bash
BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
```

**2. Dispatch code-reviewer subagent:**

Use Task tool with superpowers:code-reviewer type, fill template at `code-reviewer.md`

**Placeholders:**
- `{WHAT_WAS_IMPLEMENTED}` - What you just built
- `{PLAN_OR_REQUIREMENTS}` - What it should do
- `{BASE_SHA}` - Starting commit
- `{HEAD_SHA}` - Ending commit
- `{DESCRIPTION}` - Brief summary

**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 superpowers:code-reviewer subagent]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[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]
```

## Integration with Workflows

**Subagent-Driven Development:**
- Review after EACH task
- Catch issues before they compound
- Fix before moving to next task

**Executing Plans:**
- Review after each batch (3 tasks)
- Get feedback, apply, continue

**Ad-Hoc Development:**
- Review before merge
- Review when stuck

## 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: requesting-code-review/code-reviewer.md

Overview

This skill helps developers request targeted code reviews using a dedicated code-reviewer subagent to catch issues early and keep work aligned with requirements. It formalizes when to request reviews, how to provide context, and how to act on feedback so tasks move forward with minimal rework.

How this skill works

You capture the git range (BASE_SHA and HEAD_SHA), fill a short template describing what was implemented and the plan or requirements, and dispatch the superpowers:code-reviewer subagent via the Task tool. The subagent inspects the commit diff, tests, and architecture notes, then returns strengths, categorized issues (Critical/Important/Minor), and an assessment.

When to use it

  • After completing each task in subagent-driven development
  • After finishing a major feature or batch of tasks
  • Before merging changes into main
  • When stuck or unsure and you need a fresh perspective
  • Before large refactors to establish a baseline
  • After fixing a complex bug

Best practices

  • Always include BASE_SHA, HEAD_SHA, WHAT_WAS_IMPLEMENTED, and PLAN_OR_REQUIREMENTS in the request
  • Review early and often—prefer small, focused reviews over large diffs
  • Act on Critical and Important findings before proceeding; note Minor issues for future work
  • Provide tests or reproduction steps when pushing back on feedback
  • Use reviews as learning opportunities; incorporate reviewer strengths into future work

Example use cases

  • Completed Task 4: add authentication middleware—request review before Task 5
  • Finished a multi-file refactor—request review to ensure behavior parity before merge
  • Fixed a production bug—request a quick review to confirm no regression
  • Working on a planned feature batch—request review after the batch to validate overall design
  • Stalled on a tricky bug—request review to get an external perspective and potential fixes

FAQ

What git SHAs should I use?

Use BASE_SHA as the commit or branch head you started from (e.g., origin/main) and HEAD_SHA as your current commit. For small tasks, HEAD~1 and HEAD often suffice.

How should I respond to reviewer disagreements?

Push back with technical reasoning, tests, or examples that demonstrate correctness, and request clarification if feedback is ambiguous.