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. ### Exclusive output contract This skill may create or update only the `design.md` shown above. It may inspect the repository and discuss drafts in conversation, but it must not modify any other file, create `plan.json`, create tracker entries, invoke another workflow skill, or write implementation code. This boundary still applies when the human asks to brainstorm, plan, and implement in one request. Finish `design.md`, report it, and stop. --- ## 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 Brea...