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.

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

You MUST create a task for each of these items and complete them in order:

1. Explore project context — check files, docs, recent commits
2. Offer visual companion (if topic will involve visual questions) — this is its own message, not combined with a clarifying question. See the Visual Companion section below.
3. Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
4. Research phase — gather outside context (default-on; skip only with explicit justification). See "Research phase" section below.
5. Propose 2-3 approaches — with trade-offs and your recommendation
6. Present design — in sections scaled to their complexity, get user approval after each section
7. Write design doc — save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and commit
8. Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
9. User reviews written spec — ask user to review the spec file before proceeding
10. Transition to implementation — invoke superjawn:writing-plans skill to create implementation plan

Research phase

After clarifying questions, before proposing approaches, gather outside context. This is default-on: skip only with explicit, justified statement.

1. Pick research kinds

From the menu — trends + discourse, patterns, pitfalls, authoritative verification, user-context.

For brainstorming, the defaults are: web (trends + discourse) and codebase (prior art). Add others if the topic warrants — e.g. authoritative verification when an external API is in scope, or user-context when prior decisions in memory are relevant.

2. Dispatch

Subagent by default:

• Explore for codebase / prior-art questions ("does this repo already have something like X?", "what's the convention for Y here?")
• general-purpose for web / discourse / verification ("what's the current best practice for Z?", "what pitfalls do people hit with W?")
• Run multiple in parallel when the kinds are independent

Inline only for light-touch research (single grep, memory check).

3. Record findings

Write 3–5 tight bullets into the spec doc under a new ## Research notes section. Include load-bearing links/refs and anything considered-but-ruled-out so future-you knows it was checked.

4. Skip protocol

If skipping, write one line into the spec doc: Skipped research because <reason>. <Verifiable pointer if applicable>.

Valid reasons:

• Trivial scope (typo, comment edit, single-line config)
• Fresh prior research — same topic in current session OR within last 7 days with verifiable spec/plan pointer. If the pointer doesn't resolve, the skip is invalid. (Beyond 7 days, repeat the research even if you remember the prior findings — the landscape drifts.)
• User explicit — must quote the phrase that authorized the skip.
• Repeat of identical task — must include a pointer to the prior successful run.

Invalid reasons: "I think I know", "seems straightforward", "moving fast", "user wants this done quickly", "already familiar with this codebase". If those are tempting, do the research.

Process Flow

digraph brainstorming {
    "Explore project context" [shape=box];
    "Visual questions ahead?" [shape=diamond];
    "Offer Visual Companion\n(own message, no other content)" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Research phase" [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 superjawn:writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Visual questions ahead?";
    "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Research phase";
    "Research phase" -> "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 superjawn:writing-plans skill" [label="approved"];
}

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

The Process

Understanding the idea:

• Check out the current project state first (files, docs, recent commits)
• Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
• If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
• For appropriately-scoped projects, ask questions one at a time to refine the idea
• Prefer multiple choice questions when possible, but open-ended is fine too
• Only one question per message - if a topic needs more exploration, break it into multiple questions
• Focus on understanding: purpose, constraints, success criteria

Exploring approaches:

• Propose 2-3 different approaches with trade-offs
• Present options conversationally with your recommendation and reasoning
• Lead with your recommended option and explain why

Presenting the design:

• Once you believe you understand what you're building, present the design
• Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
• Ask after each section whether it looks right so far
• Cover: architecture, components, data flow, error handling, testing
• Be ready to go back and clarify if something doesn't make sense

Design for isolation and clarity:

• Break the system into smaller un