brainstorminglisted

# Brainstorming ## Core Principle Brainstorming produces **decision quality**, not document volume. It grounds in what already exists before asking the user anything, explores only genuine alternatives, and ends in a decision with a routed next step. Skip it whenever the request is clear and routine. ## When to Use / NOT - **Use when:** vague product/feature direction, multiple plausible approaches where the choice is load-bearing, "what if we…" with real ambiguity, a new project whose purpose is not yet clear. - **NOT when:** clear concrete requests (implement directly), bug fixes with a known root cause, mechanical refactors, one-liners. Adding a retry to an API call is not a brainstorm. "Prototype this" → `prototype`, not a design conversation. ## Workflow ### 1. GROUND, inspect the available truth first - **Existing repository:** read local instructions, the relevant implementation, nearest patterns, existing tests, the architecture seam involved. Ask the repository before asking the user, never ask a question the code can already answer. - **Greenfield:** ground in the user's problem, audience, constraints, and existing external requirements. Do not fabricate existing architecture. ### 2. FRAME, capture only the load-bearing frame ``` Outcome / User / Problem / Success / Constraints / Unknowns ``` This is a thinking frame, not a PRD, do not write it to disk by default. If it never becomes load-bearing, the conversation is the artifact. ### 3. EXPLORE, only rea