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 and get user approval. <HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE> ### Explicit bounded pre-authorization An unambiguous instruction such as “do not ask; decide and apply” can supply the approval above in advance. This exception applies only after you inspect the project, present a compact design, state your assumptions, and keep the work within the user's named, reversible scope. Do not stop merely to ask the user to repeat approval they already gave. Advance approval never covers external publication, a release, destructive work, secrets, payments, messaging, or account or security changes. It also does not override repository rules. Ask for fresh explicit approval at any of those boundaries, and fail closed when the user's authority or scope is ambiguous. ## 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 a