brainstorming

# Brainstorming Clarify **WHAT** to build before **HOW** to build it. ## Hard Gate **No implementation until the design is approved.** Brainstorming produces a design document, not code. Do not invoke implementation skills, write production code, or create files outside `docs/brainstorms/` until the user explicitly approves the design and moves to planning. ## Core Process ### Phase 0: Assess and Ground Before diving into questions, do two things: **Ground in the codebase (when applicable).** If the brainstorm relates to existing code, read the relevant modules, patterns, and constraints before generating options. This prevents suggesting approaches that conflict with the actual architecture. Skip for purely abstract brainstorms (tech choices, product direction) where no codebase context applies. **Right-size the artifact.** Match ceremony to problem size. If the brainstorm resolves in 3 messages, don't force a formal design doc -- a summary comment is enough. If it spans multiple sessions and touches architecture, write the full Phase 3 doc. No ceremony tax. **Assess whether brainstorming is needed.** Brainstorm when any of these fire: vague terms ("make it better", "add something like"), multiple reasonable interpretations, undiscussed trade-offs, user uncertainty, solution-framing instead of problem-framing ("build a dashboard"), or request spanning multiple independent subsystems (decompose first — see Scope Decomposition below). Otherwise, requirements are clear...