/review

Workflow

1. Get the actual scope, never reconstruct it: review a supplied diff; otherwise inspect git diff main...HEAD, git diff --cached, git diff, and git status --short. This includes tracked uncommitted work by default. If untracked files exist, ask the user whether to include them; state which parts were available.
2. Read changed tests and CI/config before implementation. A behavior-changing test rewrite without a sound reason, or an unjustified weaker gate, is a Blocker.
3. Produce structured review with risk, blast radius, and available test/validation evidence. When changed code has obvious callers, dependents, or public surface, recommend checking them and their relevant tests; do not turn every review into call-graph archaeology.
4. Ask ≤5 grill-me questions — one per key design decision; design intent only, not style.
5. On approval of specific fixes: apply them → run relevant tests and lint → stop and grill the user about remaining design or validation questions → ask explicit approval before committing.

Scope Discipline