---
name: spec-review
description: Review an existing spec driving change before implementation or completion. Use when the user asks to review, verify, check readiness, confirm done, accept a change, or stress-test an existing specs/changes/<change-id>/ directory.
---

# Spec Review

Review existing artifacts. Do not add new scope.

## Modes

- Proposal review: Status is `draft` or `ready`.
- Completion review: Status is `verifying`.
- If Status is `implementing` and core work is incomplete, return to `spec-apply`.

## Proposal Review

1. Read README, tasks, and optional requirements/design/decisions/evidence.
2. Check that Why, What, and Non-Goals do not conflict.
3. Check that acceptance criteria are observable and testable.
4. Check that tasks are vertical slices with validation actions.
5. Check compatibility, rollout, failure paths, evidence, and ownership.
6. Ask one blocking decision question at a time, with a recommended answer.
7. If no blockers remain, set Status to `ready`; otherwise keep/set `draft`.

For cross-repo checks, read `references/cross-repo.md`.

## Completion Review

1. Mark each acceptance criterion as `pass`, `fail`, or `unknown`.
2. Confirm checked tasks have validation or evidence.
3. Confirm implementation discoveries were written back to spec files.
4. Run or inspect relevant validation where feasible.
5. Record important evidence in `evidence.md` when useful.
6. If complete, set Status to `done`; otherwise set/keep `implementing` and update remaining tasks.

For evidence rules, read `references/verification.md`.

## Output

Report change path, review mode, final status, findings, validation evidence or gaps, and the next skill: `spec-apply`, `spec-review`, or `spec-archive`.