requirements-specification

# Requirements Specification ## Purpose Turn vague operator intent into a versioned spec with explicit acceptance criteria, unresolved clarify questions, and risk notes. The output is the contract every later skill (planning, implementation, validation, code review, security, deploy) reads. ## When to invoke - Operator says "let's ship <feature>" / "build <feature>" / "add <feature>" / "fix <workflow>" / "we need <capability>" - Backlog ticket exists at `docs/backlog/<slug>/README.md` and operator says "promote it" - Active phase is `Specify` or `Clarify` (per FLOW_RULES state announcement) ## Do not invoke when - A spec at `docs/specs/<slug>/spec.md` already exists and is scope-locked (decisions frozen; `decisions.md` shows **Lock status: LOCKED**) or its status is `DONE` (spec Status is DRAFT-until-DONE; scope-lock is a `decisions.md` flag, not a Status value) - Operator is asking how something already works (use code-review or repo-onboarding-context-map instead) - Task is a one-line bug fix that does not need clarify (see "Skip-clarify gate" below) ## Diagnosis, lane, and documentation-budget classification first (FR-21 + FR-23) Before drafting a spec, allow bounded read-only diagnosis to identify the behavior, likely diff, and risk evidence. Run the changed paths through `hooks/local/lane-router.sh --json`, then inspect the diagnosed behavior/diff and declare every semantic risk trigger with evidence path/reason through `hooks/local/lane-assessment.py`. A mechani...