Requesting Code Review

Dispatch code reviewer subagents to catch issues before they cascade

Dispatch the superpowers:code-reviewer subagent to review your work and catch issues early. Review early, review often.

When to Request Review

Mandatory Reviews

You must request review:

• After each task in subagent-driven development
• After completing a major feature
• Before merging to main

Optional but Valuable

Consider requesting review:

• When stuck (get a fresh perspective)
• Before refactoring (establish a baseline)
• After fixing a complex bug

How to Request Review

1. Get git SHAs

   Identify the commit range to review:

   BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
   HEAD_SHA=$(git rev-parse HEAD)
   
2. Dispatch code-reviewer subagent

   Use the Task tool with superpowers:code-reviewer type, filling the template from code-reviewer.md.

   Required 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

   Prioritize issues by severity:

   • Critical: Fix immediately
   • Important: Fix before proceeding
   • Minor: Note for later
   • Questionable: Push back with reasoning if reviewer is wrong

Code Review Template

The skill uses a template at requesting-code-review/code-reviewer.md that structures the review:

# Code Review Agent

You are reviewing code changes for production readiness.

## What Was Implemented
{DESCRIPTION}

## Requirements/Plan
{PLAN_REFERENCE}

## Git Range to Review
Base: {BASE_SHA}
Head: {HEAD_SHA}

## Review Checklist

**Code Quality:**
- Clean separation of concerns?
- Proper error handling?
- Type safety (if applicable)?
- DRY principle followed?
- Edge cases handled?

**Architecture:**
- Sound design decisions?
- Scalability considerations?
- Performance implications?
- Security concerns?

**Testing:**
- Tests actually test logic (not mocks)?
- Edge cases covered?
- Integration tests where needed?
- All tests passing?

**Requirements:**
- All plan requirements met?
- Implementation matches spec?
- No scope creep?

Example Review Request

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

Review Output Format

The code reviewer provides structured feedback:

Strengths

What’s well done, with specific file:line references

Example:

- Clean database schema with proper migrations (db.ts:15-42)
- Comprehensive test coverage (18 tests, all edge cases)
- Good error handling with fallbacks (summarizer.ts:85-92)

Issues by Severity

Critical (Must Fix):

• Bugs, security issues, data loss risks, broken functionality

Important (Should Fix):

• Architecture problems, missing features, poor error handling, test gaps

Minor (Nice to Have):

• Code style, optimization opportunities, documentation improvements

Each issue includes:

• File:line reference
• What’s wrong
• Why it matters
• How to fix (if not obvious)

Assessment

Clear verdict: Ready to merge? Yes/No/With fixes

Technical reasoning in 1-2 sentences

Integration with Workflows

Subagent-Driven Development

Review after each task to catch issues before they compound. Fix before moving to next task.

Executing Plans

Review after each batch (3 tasks). Get feedback, apply fixes, continue.

Ad-Hoc Development

Review before merge or when stuck on a problem.

Red Flags

Never:

• Skip review because “it’s simple”
• Ignore Critical issues
• Proceed with unfixed Important issues
• Argue with valid technical feedback

If reviewer is wrong:

• Push back with technical reasoning
• Show code/tests that prove it works
• Request clarification on unclear feedback

Related Skills

• Receiving Code Review - How to handle feedback from reviews
• Verification Before Completion - Verify work before requesting review