vidhi-brainstormlisted

# Brainstorm Turn an idea into a design through collaborative dialogue. <HARD-GATE> Do NOT write code, scaffold projects, invoke implementation skills, or take any implementation action during brainstorming. The output of this skill is a shared understanding — not code, not a spec file. </HARD-GATE> ## "This is too simple to need a design" No it isn't. A config change, a single utility, a one-endpoint API — all go through this process. Simple projects are where unexamined assumptions waste the most work. The design can be short (a few sentences), but you present it and get approval. ## Process ### 1. Explore context Before asking a single question, understand what exists: - Read relevant code, docs, recent commits - Check for `CONTEXT.md` — if it exists, use its vocabulary throughout - Check for ADRs in `docs/adr/` — respect existing decisions ### 2. Scope check Assess before diving into details: if the request describes multiple independent subsystems, flag it immediately. Don't spend questions refining details of something that needs decomposition first. If the project is too large for a single design, help decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project. ### 3. Clarifying questions Ask questions one at a time. Wait for the answer before the next question. - Prefer multiple choice when the options are knowable. Open-ended when they aren't. - One question per