brainstorminglisted

# Brainstorming Turn rough requests into an approved design before implementation. ## Hard Gate Do not write code, edit files, or invoke implementation skills until design approval is explicit. One carve-out: writes under `docs/research/` and `.superpowers/research/` made by the prior-art research step, and commits of those same paths made by that step, are part of design work, not implementation. ## Anti-Pattern: "This Is Too Simple To Need A Design" Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval. ## Checklist 1. Inspect project context (relevant files, docs, recent commits). 2. Assess scope: if the project touches 4+ independent subsystems or would require 20+ implementation tasks, decompose into sub-projects. Design each sub-project as a separate spec. Present the decomposition to the user for approval before designing individual specs. 3. Ask all clarifying questions together in a single turn. Use multiple-choice format where possible to reduce round trips. 4. Enumerate the candidate technologies for any decision matching the trigger predicate (see Research Gate below for the predicate's exact wording). 5. **Research gate.** Run this step only if the predicate matches, and the platform is not on degradation rung 3 (