requirements-specificationlisted

# 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 with status `LOCKED` or `DONE` - 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) ## Lane + documentation-budget classification first (FR-21 + FR-23) Before drafting a spec, classify the ticket **Full** or **Lightweight** using the eligibility gate in `flow-skills/lightweight-lane/SKILL.md`. If the change is small, reversible, security-neutral, mechanically-verifiable, needs no architectural decision, and the root cause is known → it is **Lightweight**: do NOT draft spec/clarify/decisions/tasks/gate. Instead produce a single **change-note** (`templates/change-note.md`) and route to `workflows/lightweight-lane.md` (one build→verify→deploy pass, plain operator go-ahea