brainstorminglisted

# Brainstorming Short, structured exploration. No code yet. ## When to use - "Let's build X" - "I want to add Y" - "How should we approach Z" Skip this skill for one-line fixes, typos, or mechanical chores. ## Before you spend questions If the request describes several independent subsystems — "a platform with chat, file storage, billing and analytics" — say so immediately. Refining the details of something that needs decomposing first wastes the questions and produces a spec nobody can execute. Each sub-project gets its own spec, plan and implementation cycle. Cover architecture, components, data flow, error handling and testing. The spec format below has no slot for error handling or testing, so those are the two that get forgotten and then get built badly — put them in `## Approach` explicitly. **Cut ruthlessly.** Remove anything from every candidate approach that the goals do not require. Over-building is far cheaper to prevent here than to catch in review, and the reviewer will reject anything it cannot trace to a Goal. **Cleanup inside the work is in scope; unrelated refactoring is not.** Where existing code you must touch has problems, include the targeted improvement in the design — the way a competent engineer improves code they are working in. Say so explicitly, because anything not traceable to a Goal reads as scope creep downstream. **The terminal state is `writing-plans`.** When the spec is approved, invoke that and nothing else. Do not slide from a des