29 lines
1.6 KiB
Markdown
29 lines
1.6 KiB
Markdown
---
|
|
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).
|