speclisted

# spec — Author a feature spec Produce ONE document a teammate can review *before* any code is written. That document is the contract `implement` executes. ## Steps 1. **Require a tracker issue. No issue, no spec.** `.steering/tech.md` names this project's tracker and the command to read issues. Read the issue you were given. If there is no issue, **stop and say so.** Do not create one to proceed. An issue created here is unplanned work entering through the side door, bypassing the sprint that was supposed to decide what gets built — and the sprint stops meaning anything the first time it is bypassed silently. Offer to run `sprint`, or to create the issue explicitly as acknowledged unplanned work; either way it is the user's call, made out loud. The slug is `<n>-<kebab-title>`. It names **both** the branch and the spec directory, so an issue, a branch, a spec, and a PR are always the same unit of work. **The issue's type decides the spec's shape** — take it from the template used or the label applied: `feature`, `bug`, or `chore`. If it is genuinely unclear, ask. Do not default to feature; feature is the shape that fits a bug worst. 2. **Read the context you are about to design against**, and do not skip it: `.steering/product.md`, `.steering/tech.md`, `.steering/structure.md`, the issue body, and any design docs those point to. 3. **Draft section 1 (Requirements) only. Then stop and run `clarify`.** Design decided on top of a misread requirement is the most expensive rewo