Produce docs/specs/<YYYY-MM-DD>-<feature>/requirements.md from the approved frame-change outcome. Requirements are the durable source of intent: they outlive this conversation, and every task, test, and commit will cite their IDs.

Two modes — pick by what you were handed

Tier-1 mini-spec — a fix plus a guard for an already-approved feature (from amend-feature or root-cause). Not a new requirements.md: append to the owning feature's requirements.md (or docs/specs/fixes.md if unowned) the fix requirement (one EARS criterion, Step 2's forms) and its SHALL CONTINUE TO guard (Step 3, for the behavior the fix must not break).

Self-review just those two criteria: the ambiguity and testability scans, plus the code-claim check (Step 5) only when a criterion asserts how the system currently works — a guard usually does. Present both for approval, keep the feature's Status, and exit to test-first. Skip Steps 1 and 4 and the whole-file review — those are for a new feature, not a two-line mini-spec.

specify-behavior

Two modes — pick by what you were handed