/brainstorming

name: brainstorming
description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."

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>

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.

Classify the work first — right-size the ceremony

Not every request needs the full multi-approach, sectioned-design treatment. Classify the intent, then scale the dialogue to it. **The HARD-GATE is universal — complexity decides the length of the artifact, never whether approval happens. And in Hydraia a written spec is always produced (the spec-drive gate depends on it); the class decides how long that spec is, not whether it exists.**

• **Spike** (a feasibility question — "can we even do X?"): present the probe plan in 2–3 sentences → get approval → investigate cheaply → report the finding as a recommendation. If it turns into real work, re-enter as Bounded or Architectural.
• **Bounded** (a scoped change to existing code): explore the context → ask only the clarifying questions that matter → present a short in-chat design (a few sentences to a paragraph, usually one approach) → get approval → write a **minimal spec** (short, but real — the gate needs it) → continue. Skip the 2–3-approach survey and the section-by-section presentation; they are overkill here.
• **Architectural** (a new system, subsystem, or a change that reshapes boundaries): run the full flow below — explore, 2–3 approaches with trade-offs, sectioned design presentation with approval per section, full written spec, spec self-review, user spec review.

Rough mapping to Hydraia's autonomy tiers: Spike ≈ investigation only · Bounded ≈ Tier S/M · Architectural ≈ Tier L / greenfield.

**Mid-task path upgrade (do not let a small task silently balloon).** If a Bounded task turns out to hide real complexity — a new subsystem, a cross-cutting change, an irreversible migration, a decision the user would notice — STOP and upgrade it to Architectural immediately: widen the dialogue, propose approaches, and write the fuller spec. A Bounded task must never quietly become an architectural one under the radar. (A Spike that proves feasibility likewise re-enters as Bounded or Architectural — it never slides straight into building.)

Checklist

Create a task for each of these items and complete them in order. **For an Architectural intent, all steps apply. For Bounded, steps 4–5 collapse to one short in-chat design (skip the 2–3-approach survey and section-by-section approval) and step 6 writes a minimal spec. For a Spike, do step 1 + a 2–3-sentence probe plan, then report the finding.** The HARD-GATE (present → approve) and the written spec are never skipped.

1. **Explore project context** — check files, docs, recent commits 2. **Offer the visual companion just-in-time** — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below. 3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria 4. **Propose 2-3 approaches** — with trade-offs and your recommendation 5. **Present design** — in sections scaled to their complexity, get user approval after each section 6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit 7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below) 8. **User reviews written spec** — ask user to review the spec file before proceeding 9. **Transition to implementation** — invoke writing-plans skill to create implementation plan

Process Flow

digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

The Pr