spec-brainstorm

# Spec Brainstorm Conversational design workshop that produces a focused, reviewed spec. One question at a time. Multiple approaches explored. Design approved in sections. Ruthless scope control. No implementation until design is approved. ## Artifact ``` docs/specs/YYYY-MM-DD-<feature>/ └── design.md ← This skill's output ``` Requirements are inline — no separate requirements.json needed. --- ## Lessons These principles apply to every spec, every time. ### "Too simple for a design" is an anti-pattern Every project goes through this process. No exceptions. The five-minute conversation often reveals assumptions that would cost hours in implementation. If it's truly trivial, the spec will be short — but it still gets written. ### Design for isolation and clarity Break the system into units with one clear purpose each. Well-defined interfaces between them. Each unit independently understandable and independently testable. If you can't explain a unit's job in one sentence, it's doing too much. ### Working in existing codebases Explore the current structure first. Follow existing patterns. Targeted improvements only. No unrelated refactoring. Understand why things are the way they are before proposing changes. ### Decomposition If the request describes multiple independent subsystems, flag it immediately. Decompose into sub-projects before diving into details. Each sub-project gets its own spec and its own plan. A spec that tries to cover three subsystems helps no...