Reviewer Specification — Claude Code Guide

A specification for the reviewer

A reviewer-oriented specification is not advertising copy; it is a compact contract for an independent decision. It must let another person understand the problem, replay the bounded flow, check acceptance, and see what remains Unknown.

SPEC.md can be a long-lived project contract, TASK_SPEC.md a statement of specific work, and EVIDENCE.md a record of actual checks. Do not merge these roles into one text or call a filled documented example evidence of actual execution.

Reviewer checklist

• Is it clear who the user is and which JTBD should improve?
• Are the value proposition, scope, non-goals, and release slice aligned?
• Does each acceptance criterion have a verification method?
• Are facts, assumptions, Unknowns, and future claims separated?
• Can one core flow be reviewed without hidden dependencies?
• Does the reviewer have enough evidence for GO, HOLD, or a scope-change request?

Minimal reviewer-ready contract

# SPEC.md
Problem: reviewers lose context while checking a bounded AI-assisted change
User: reviewer of one repository workflow
Core flow: intake -> AI-assisted outline -> human review -> evidence note
In scope: one flow, one metric, one review checklist
Non-goals: autonomous merge, production deployment, broad product roadmap
Acceptance: reviewer can reproduce the outline and locate Unknowns
Verification: static checks and documented review steps; execution status: Unknown
Status: documented example; no product outcome is claimed.