brainstormlisted

# Brainstorm ## What this skill is — and isn't | Skill | Question it answers | Output | |---|---|---| | `vd:research` | "Which of these known options should I pick?" | Comparison report with citations | | **`vd:brainstorm`** | **"How should I approach this — what are the options?"** | **Decision brief with 3+ invented/curated approaches** | | `vd:plan` | "Given the chosen approach, what are the steps?" | Phased implementation plan | Brainstorm is **solution-space exploration**. You may end up recommending a known pattern, but the job is to surface paths the user hasn't considered, then converge. ## Hard rules 1. **No code, no scaffolding, no file edits to source.** Only the brief gets written. If the user pushes for implementation, point them at `vd:plan` or `vd:cook`. 2. **Minimum 3 genuinely divergent options.** If all your options share the same architectural assumption (e.g. all are "different ORMs"), you haven't diverged — invent one that violates the shared assumption (e.g. "no ORM, raw SQL"). 3. **Steel-man before strawman.** For each option write the *strongest* case first. If you can't argue for it convincingly, you don't understand it yet. 4. **Brutal honesty.** Name dealbreakers, hidden costs, ops burden, lock-in, hiring market, debugging pain. No marketing language. No symmetric "it's all tradeoffs" hedging — pick one. 5. **Decomposition first, depth second.** If the request spans 3+ independent subsystems, stop and decompose before any deep-dive. ## Modes