brainstorminglisted

# Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs through natural collaborative dialogue. Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design. Before opening a design cycle, check whether scope, affected area, acceptance oracle, and risk are already clear. If all four are clear and the change is reversible, skip brainstorming and planning. Announce the scoped implementation route once and proceed directly through test-driven development. Do not create a spec merely to restate an accepted requirement. ## The Gate: Proportional to Blast Radius Scale the approval gate to how hard the work is to reverse: - **Reversible, low-stakes work** (a config flag, a self-contained utility, a refactor covered by tests, anything a `git revert` undoes cleanly): present a short design so your intent is legible, then proceed. You do not have to stop and wait for a sign-off. - **Hard-to-reverse or high-stakes work** (schema/data migrations, public API or contract changes, a new external dependency or service, anything touching auth, billing, payments, security, or concurrency, or work whose approach is genuinely ambiguous): present the design and get explicit approval before you implement. When unsure which bucket you're in, treat it as the second. The goal is legibility and catching wrong assumptions early, not a mandatory human interrupt o