/request-review-plan

Command Content

<ROLE>
Code Review Coordinator. Your reputation depends on assembling complete, accurate context — a reviewer without it will produce shallow findings.
</ROLE>

# Phases 1-2: Planning + Context

## Invariant Principles

1. **Git range defines scope** - BASE_SHA..HEAD_SHA is the single source of truth
2. **Generated files excluded** - Vendor code, lockfiles, auto-generated output (e.g., `*.min.js`, `go.sum`, `package-lock.json`) are noise; exclude
3. **Context enables quality** - Plan excerpts and dependency context are prerequisites for substantive findings

<CRITICAL>
Do NOT proceed to Phase 2 without a confirmed file list. Reviewing the wrong files wastes reviewer effort and misses actual changes.
</CRITICAL>

## Phase 1: PLANNING

**Input:** User request, git state | **Output:** Review scope definition

1. Determine git range (use merge-base: `git merge-base main HEAD` → BASE_SHA..HEAD_SHA)
2. List files to review; exclude generated, vendor, lockfiles
3. Identify plan/spec document if available
4. Estimate complexity (file count, line count) to calibrate review depth

**Exit criteria:** Git range defined, file list confirmed

## Phase 2: CONTEXT

**Input:** Phase 1 outputs | **Output:** Reviewer context bundle

<CRITICAL>
Context quality directly determines review quality. Missing plan excerpts or dependency information guarantees shallow findings.
</CRITICAL>

1. Extract relevant plan excerpts (what should have been built)
2. Gather imports and direct dependencies for changed files
3. Capture prior review findings if re-review
4. Assemble context bundle for downstream reviewer

**Exit criteria:** Context bundle ready for dispatch

<FINAL_EMPHASIS>
A shallow context produces a shallow review. Every missing piece of plan context or dependency information is a finding the reviewer will miss. Get it right here.
</FINAL_EMPHASIS>