> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/obra/superpowers/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Warning>
  You **must** request review:

  * After each task in subagent-driven development
  * After completing a major feature
  * Before merging to main
</Warning>

### Optional but Valuable

<Tip>
  Consider requesting review:

  * When stuck (get a fresh perspective)
  * Before refactoring (establish a baseline)
  * After fixing a complex bug
</Tip>

## How to Request Review

<Steps>
  <Step title="Get git SHAs">
    Identify the commit range to review:

    ```bash theme={null}
    BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
    HEAD_SHA=$(git rev-parse HEAD)
    ```
  </Step>

  <Step title="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
  </Step>

  <Step title="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
  </Step>
</Steps>

## Code Review Template

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

```markdown theme={null}
# 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:

<Accordion title="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)
  ```
</Accordion>

<Accordion title="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)
</Accordion>

<Accordion title="Assessment">
  Clear verdict: Ready to merge? Yes/No/With fixes

  Technical reasoning in 1-2 sentences
</Accordion>

## Integration with Workflows

<CardGroup cols={2}>
  <Card title="Subagent-Driven Development" icon="list-check">
    Review after **each task** to catch issues before they compound. Fix before moving to next task.
  </Card>

  <Card title="Executing Plans" icon="diagram-project">
    Review after each batch (3 tasks). Get feedback, apply fixes, continue.
  </Card>

  <Card title="Ad-Hoc Development" icon="code">
    Review before merge or when stuck on a problem.
  </Card>
</CardGroup>

## Red Flags

<Warning>
  **Never:**

  * Skip review because "it's simple"
  * Ignore Critical issues
  * Proceed with unfixed Important issues
  * Argue with valid technical feedback
</Warning>

<Tip>
  **If reviewer is wrong:**

  * Push back with technical reasoning
  * Show code/tests that prove it works
  * Request clarification on unclear feedback
</Tip>

## Related Skills

* [Receiving Code Review](/skills/receiving-code-review) - How to handle feedback from reviews
* [Verification Before Completion](/skills/verification-before-completion) - Verify work before requesting review
