spec-brainstorm

# Spec Brainstorm Conversational design workshop for substantial work 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. Run this skill only after `atelier-orchestrator` selects a Spec-backed Plan or the human explicitly requests a spec. Bounded work should go directly to `spec-plan` for an Inline Plan. Do not reclassify the planning mode here. ## 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. ### Specs must earn their cost Persisted specs are for work whose discovery, architecture, dependencies, or coordination needs justify a durable artifact. Do not pull bounded work into this workflow merely because it touches multiple files or takes time. That work belongs in an Inline Plan. ### 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 chang...