requesting-code-review

# 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:**
```bash
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](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 | cut -d' ' -f1)
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](code-reviewer.md)

{
  "format": "aiskill/v1",
  "skill": {
    "name": "requesting-code-review",
    "slug": "requesting-code-review",
    "version": "1.0.0",
    "description": "Use when completing tasks, implementing major features, or before merging to verify work meets requirements",
    "category": "Development",
    "tags": [
      "dev-workflow"
    ],
    "platforms": [
      "chatgpt",
      "claude-code",
      "cursor"
    ],
    "tested_environment": "Agent Skills convention (SKILL.md) — works with Claude Code, Cursor, ChatGPT/Codex and compatible agents",
    "license": "MIT"
  },
  "prompts": {
    "system": "# Requesting Code Review\n\nDispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.\n\n**Core principle:** Review early, review often.\n\n## When to Request Review\n\n**Mandatory:**\n- After each task in subagent-driven development\n- After completing major feature\n- Before merge to main\n\n**Optional but valuable:**\n- When stuck (fresh perspective)\n- Before refactoring (baseline check)\n- After fixing complex bug\n\n## How to Request\n\n**1. Get git SHAs:**\n```bash\nBASE_SHA=$(git rev-parse HEAD~1)  # or: git merge-base origin/main HEAD\nHEAD_SHA=$(git rev-parse HEAD)\n```\n\n**2. Dispatch code reviewer subagent:**\n\nDispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)\n\n**Placeholders:**\n- `{DESCRIPTION}` - Brief summary of what you built\n- `{PLAN_OR_REQUIREMENTS}` - What it should do\n- `{BASE_SHA}` - Starting commit\n- `{HEAD_SHA}` - Ending commit\n\n**3. Act on feedback:**\n- Fix Critical issues immediately\n- Fix Important issues before proceeding\n- Note Minor issues for later\n- Push back if reviewer is wrong (with reasoning)\n\n## Example\n\n```\n[Just completed Task 2: Add verification function]\n\nYou: Let me request code review before proceeding.\n\nBASE_SHA=$(git log --oneline | grep \"Task 1\" | head -1 | cut -d' ' -f1)\nHEAD_SHA=$(git rev-parse HEAD)\n\n[Dispatch code reviewer subagent]\n  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types\n  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md\n  BASE_SHA: a7981ec\n  HEAD_SHA: 3df7661\n\n[Subagent returns]:\n  Strengths: Clean architecture, real tests\n  Issues:\n    Important: Missing progress indicators\n    Minor: Magic number (100) for reporting interval\n  Assessment: Ready to proceed\n\nYou: [Fix progress indicators]\n[Continue to Task 3]\n```\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"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. |\n| \"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. |\n\n## Red Flags\n\n**Never:**\n- Skip review because \"it's simple\"\n- Ignore Critical issues\n- Proceed with unfixed Important issues\n- Argue with valid technical feedback\n\n**If reviewer wrong:**\n- Push back with technical reasoning\n- Show code/tests that prove it works\n- Request clarification\n\nSee template at: [code-reviewer.md](code-reviewer.md)",
    "user_template": ""
  },
  "variables": [],
  "install": {
    "steps": [
      {
        "title": "Download & unzip",
        "detail": "Download the .zip package from SkillVault and unzip it. The requesting-code-review/ folder contains SKILL.md plus any companion scripts, references and assets."
      },
      {
        "title": "Copy into your agent skills directory",
        "detail": "Move the folder into your agent's skills directory — e.g. ~/.claude/skills/ (Claude Code), .codex/skills/, .cursor/skills/ or your project's .claude/skills/ folder — then restart or reload the session."
      },
      {
        "title": "Use it",
        "detail": "Describe the task in natural language; the agent loads the skill automatically when the request matches the skill description."
      }
    ]
  },
  "usage": {
    "steps": []
  },
  "metadata": {
    "author": "SkillVault",
    "source": "https://skillvault.top/skills/requesting-code-review",
    "exported_at": "2026-11-03T07:41:43.752Z"
  }
}

format: aiskill/v1
skill:
  name: requesting-code-review
  slug: requesting-code-review
  version: 1.0.0
  description: >-
    Use when completing tasks, implementing major features, or before merging to verify work meets
    requirements
  category: Development
  tags:
    - dev-workflow
  platforms:
    - chatgpt
    - claude-code
    - cursor
  tested_environment: >-
    Agent Skills convention (SKILL.md) — works with Claude Code, Cursor, ChatGPT/Codex and
    compatible agents
  license: MIT
prompts:
  system: >-
    # 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:**

    ```bash

    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](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 | cut -d' ' -f1)

    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](code-reviewer.md)
  user_template: ""
variables: []
install:
  steps:
    - title: Download & unzip
      detail: >-
        Download the .zip package from SkillVault and unzip it. The requesting-code-review/ folder
        contains SKILL.md plus any companion scripts, references and assets.
    - title: Copy into your agent skills directory
      detail: >-
        Move the folder into your agent's skills directory — e.g. ~/.claude/skills/ (Claude Code),
        .codex/skills/, .cursor/skills/ or your project's .claude/skills/ folder — then restart or
        reload the session.
    - title: Use it
      detail: >-
        Describe the task in natural language; the agent loads the skill automatically when the
        request matches the skill description.
usage:
  steps: []
metadata:
  author: SkillVault
  source: https://skillvault.top/skills/requesting-code-review
  exported_at: "2026-11-03T07:41:43.752Z"