---
name: review
description: >
  Review an existing SPEC.md before implementation when asked to review or red-team the spec, or when spec review is part of the authorized task.
scope: global
---

# Spec review

1. Read the relevant goals, constraints, interfaces, research, invariants, and tasks.
   Inspect implementations and callers affected by the proposed change.
2. Test consequential assumptions against code, existing tests, and current primary
   sources where needed. Look for mismatched requirements, contract conflicts,
   missing failure behavior, and tasks without observable completion evidence.
   For substantial specs, a fresh-context pass can expose assumptions inherited
   from drafting. When an isolated reviewer is available, give it the spec, relevant
   source, and review criteria without the drafting conversation. If isolation is
   unavailable, reread the spec as a standalone document and note that the review
   shared drafting context. Skip this extra pass for small or straightforward specs.
3. Report demonstrated defects with file/line or source evidence and concrete remedies.
   Distinguish material hardening from optional notes; unverified claims stay notes.
4. Draft useful invariant/interface/task amendments when needed. Do not edit a spec
   during a report-only review; apply amendments only within an authorized edit.
5. Give a go/no-go verdict if requested or useful for the pending implementation.
   A sound spec needs a short conclusion, not fabricated blockers.

Scale review to the actual change. Do not introduce a separate approval or invocation
requirement for routine work. Follow [shared workflow](../../protocols/workflow.md).