speclisted

# Spec Pin down what "done" means before writing code. Even a five-line spec beats none: it forces the boundary question (what are we *not* doing?) and gives `/verify` something concrete to check against. This is the lightweight entry to the Define phase — reach for `/rfc` only when there are genuinely competing architectural options to weigh. ## Rationalizations | Rationalization | Rebuttal | |---|---| | "Task too simple for a spec." | Acceptance criteria apply at any scale. A simple task gets a five-line spec, not zero. | | "The requirements are obvious from the ask." | Then writing them down costs a minute and catches the one place they weren't. | | "We'll figure out the edge cases while coding." | Edge cases decided mid-implementation default to whatever is easiest to code, not what's right. | | "A spec will slow us down." | Rework from a misunderstood requirement is slower than twenty lines of markdown. | ## Format ```markdown ## Goal <1-2 sentences: the user-visible outcome, not the implementation.> ## Non-goals <What this change deliberately does NOT do. The scope fence — anything here appearing in the diff is scope creep.> ## Acceptance criteria <Testable statements. Each one either passes or fails — no "works well". - [ ] <observable behavior, ideally with concrete input → output> - [ ] <error/edge case behavior>> ## Open questions <Anything blocking or ambiguous. If a question changes the approach, resolve it before coding; otherwise note the assumption and