brainstorming

name	brainstorming
class	workflow
description	Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use `/ia-brainstorm`.

Brainstorming

Clarify WHAT to build before HOW to build it.

Hard Gate

No implementation until the design is approved. Brainstorming produces a design document, not code. Do not invoke implementation skills, write production code, or create files outside docs/brainstorms/ until the user explicitly approves the design and moves to planning.

Core Process

Phase 0: Assess and Ground

Before diving into questions, do two things:

Ground in the codebase (when applicable). If the brainstorm relates to existing code, read the relevant modules, patterns, and constraints before generating options. This prevents suggesting approaches that conflict with the actual architecture. Skip for purely abstract brainstorms (tech choices, product direction) where no codebase context applies.

Right-size the artifact. Match ceremony to problem size. If the brainstorm resolves in 3 messages, don't force a formal design doc -- a summary comment is enough. If it spans multiple sessions and touches architecture, write the full Phase 3 doc. No ceremony tax.

Assess whether brainstorming is needed:

Signals that requirements are clear:

• User provided specific acceptance criteria
• User referenced existing patterns to follow
• User described exact behavior expected
• Scope is constrained and well-defined

Signals that brainstorming is needed:

• User used vague terms ("make it better", "add something like")
• Multiple reasonable interpretations exist
• Trade-offs haven't been discussed
• User seems unsure about the approach
• User described a solution ("build a dashboard") instead of a problem
• Request spans multiple independent subsystems -- decompose first (see Scope Decomposition below)

If requirements are clear, suggest: "Your requirements seem clear. Consider proceeding directly to planning or implementation."

Scope Decomposition Gate

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 decomposition first.

1. Identify the independent pieces and how they relate
2. Determine build order (dependencies, shared infrastructure first)
3. Brainstorm the first sub-project through the normal Phase 1-3 flow
4. Each sub-project gets its own spec -> plan -> implementation cycle

Phase 1: Understand the Idea

User context calibration (before diving into the idea):

Read signals from the user's first message to calibrate communication register:

• Vocabulary: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?
• Framing: Are they describing a solution ("build a dashboard") or a problem ("I can't see what's happening")?
• References: Are they pointing to code, files, and patterns, or to analogies and comparisons ("something like Notion")?

Adjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration -- just do it. If signals are ambiguous, default to the vocabulary the user is already using.

Explore project context first: Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality.

Ask questions one at a time by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.

Info-dump gate (when user offers rich context up-front): if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead, respond with 5-10 numbered clarifying questions the user can answer in shorthand (1: yes, 2: channel #ops, 3: no because backwards compat). Pick questions that remove ambiguity, not questions that show you read the dump. Exit this batched mode when the user's answers show they can be asked about edge cases without basics being explained back to them.

Example — after the user dumps a spec:

Before I propose approaches, 8 quick clarifications:

1. Auth — SSO (which provider?) or username/password?
2. Data retention — forever, or N-day rolling window?
3. Multi-tenant or single-tenant?
4. Sync or async for the webhook delivery?
5. Real users or service accounts allowed?
6. Target latency on the read path — P50? P99?
7. Which of the three integrations is P0?
8. "Fast enough" in the spec — what's the actual number?

Answer whichever you know; leave blanks for the rest.

Question Techniques:

1. Prefer multiple choice when natural options exist

   • Good: "Should the notification be: (a) email only, (b) in-app only, or (c) both?"
   • Avoid: "How should users be notified?"

2. Start broad, then narrow

   • First: What is the core purpose?
   • Then: Who are the users?
   • Finally: What constraints exist?

3. Validate assumptions explicitly

   • "I'm assuming users will be logged in. Is that correct?"

4. Ask about success criteria early

   • "How will you know this feature is working well?"

Key Topics to Explore:

Topic	Example Questions
Purpose	What problem does this solve? What's the motivation?
Users	Who uses this? What's their context?
Constraints	Any technical limitations? Timeline? Dependencies?
Success	How will you measure success? What's the happy path?
Edge Cases	What shouldn't happen? Any error states to consider?
Existing Patterns	Are there similar features in the codebase to follow?
Non-goals	What is explicitly NOT in scope?

See deep-interview.md for deep interview techniques.

Exit Condition: Continue until the idea is clear OR user says "proceed". Before moving to Phase 2, summarize understanding in 3-5 bullets and confirm with the user.

Phase 2: Explore Approaches

After understanding the idea, propose 2-3 concrete approaches.

Structure for Each Approach:

### Approach A: [Name]

[2-3 sentence description]

**Pros:**
- [Benefit 1]
- [Benefit 2]

**Cons:**
- [Drawback 1]
- [Drawback 2]

**Best when:** [Circumstances where this approach shines]

Guidelines:

• Lead with a recommendation and explain why
• Be honest about trade-offs
• Consider YAGNI--simpler is usually better
• Reference codebase patterns when relevant
• If no approach is accepted after 2 rounds, ask the user to describe their preferred direction directly

Ideation lenses (use 2-3 to stress-test approaches when the design space is wide):

• Inversion: What if we solved the opposite problem?
• Constraint removal: What would we build if [biggest constraint] didn't exist?
• Audience shift: What if the primary user were [different persona]?
• Combination: Can two weak approaches combine into a strong one?
• Simplification: What's the version that ships in a day?
• 10x version: What if this needed to handle 10x the scale?
• Expert lens: How would [domain expert] approach this?

"Not Doing" list: Include an explicit list of what the chosen approach will NOT do. Focus is about saying no to good ideas. Make the trade-offs visible so they're a deliberate choice, not an oversight.

Assumptions with validation: For each key assumption in the chosen approach, state how to test it. Not just "we assume X" but "we assume X -- we'll know by [validation method]."

Phase 2.5: Pre-Write Scope Synthesis

Surface the scope interpretation so the user can correct it before Phase 3 writes the design doc. The synthesis is a chat-time scope checkpoint distinct from Phase 3b's post-draft self-review — 2.5 catches scope misalignment before the doc is written; 3b catches drafting issues after.

Present three labeled buckets plus a 1-3 line prose gloss:

Three buckets:

• Stated — what the user said directly (original prompt, dialogue answers, approach selection). Each bullet has an explicit user-language anchor.
• Inferred — gaps filled with assumptions. Scope boundaries the user never named, success criteria extrapolated from intent, technical assumptions the brief interview didn't probe. Most actionable bucket — bets the user can reject.
• Out of scope — deliberately excluded items. Adjacent refactors, nice-to-haves, future-work items. Surfacing exclusions lets the user spot anything they wanted included.

Granularity rule: each bullet must be affirmable or rejectable on product/scope grounds without reading code or implementation details. File names, exact JSON shapes, schema fields, error wording are Phase 3 doc-body content — not synthesis content. If a bullet requires architectural evaluation to judge, re-cut it at scope level.

Prose gloss (required for all but truly-trivial cases): lead with a 1-3 line plain-language summary of what's being proposed for the doc. Forward-looking, not retrospective. The user may agree with each bullet but disagree with the framing — prose surfaces that gist. Skip only when the synthesis is ≤2 Stated bullets that just echo the prompt.

Anti-patterns:

• Synthesis written as a proposal pitch ("Recommendation:", "Behavior when X:", file paths, JSON shapes) — that content belongs in Phase 3, not here. Position-independent: the rule applies regardless of where the plan-body content appears, including nested inside a bucket bullet's commentary or sub-bullets. A structurally-legal placement (inside a bucket) does not legitimize plan-body content.
• Buckets padded to look thorough when one bucket would suffice.
• Floating questions outside the three buckets. Every scope-shaping question must land in Stated, Inferred, or Out by synthesis time. If new ambiguities surface during synthesis composition, batch them in one round (per the Phase 1 info-dump pattern) and resolve them before presenting — never present a synthesis with adjacent unanswered questions.

Re-present after revision; write only on confirm. If the user revises any bullet (even trivially), integrate the change, re-present the revised synthesis, and wait for explicit confirmation before Phase 3. A revision is not a confirmation.

Headless mode (invoked via /ia-lfg or any disable-model-invocation context): compose the synthesis but skip the confirmation step. Route Inferred bets to a ## Assumptions section in the Phase 3 doc — explicitly labeled as un-validated bets — instead of into Key Decisions. Stated routes to Requirements; Out-of-scope routes to Non-Goals as usual.

Skip Phase 2.5 entirely on the trivial fast path (Phase 0 detected requirements were already clear and the flow went straight to a short summary).

Phase 3: Capture the Design

Summarize key decisions in a structured format. For each major component, verify isolation and clarity: it must answer "what does it do, how do you use it, what does it depend on?" and be independently understandable and testable. If working in an existing codebase, note which existing patterns to follow and where targeted improvements fit naturally.

Design Doc: Save to docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md. Required sections: What We're Building, Why This Approach, Key Decisions (with rationale), Open Questions, Next Steps. Collapse the Q&A interview log in a <details> block. Include YAML frontmatter with date and topic. Commit to git -- design decisions are project history.

Phase 3b: Spec Self-Review

Before presenting the design doc, run this checklist against the draft. Any failure means return to Phase 2 or Phase 3, not Phase 4.

• Placeholder scan: no "TBD", "figure out later", "appropriate error handling", bracketed gaps, or tasks without concrete criteria
• Internal consistency: names, types, and verbs referenced in one section match every other section (no createOrder() in one place and placeOrder() in another)
• Scope containment: every decision traces back to a stated goal. If a decision doesn't, cut it or surface it as an explicit scope expansion with rationale
• Ambiguity sweep: read each Key Decision and ask "could a reasonable implementer interpret this two ways?" If yes, tighten the wording before handoff
• Assumption validation: every assumption has a stated validation method (not just "we assume X" but "we assume X — we'll confirm by Y")
• Non-goals list present: the explicit "Not Doing" list exists and is specific, not boilerplate

Silent pass is a valid outcome. If the draft is clean, say so and move to Phase 4.

Phase 4: Review and Handoff

Present the design doc to the user for approval. The user explicitly confirming the design is the gate to proceed. When invoked via /ia-brainstorm, the command handles spec review dispatch and next-step orchestration.

Headless mode (invoked via /ia-lfg or any disable-model-invocation context): skip the user approval step at Phase 4 — same carve-out as Phase 2.5. The doc-write completes; the artifact is the audit surface for downstream review (/ia-plan, PR review, the ia-document-review skill), not chat confirmation.

Anti-Patterns to Avoid

Anti-Pattern	Better Approach
Asking 5 questions at once	Ask one at a time across dimensions; cluster 2-3 within a dimension
Jumping to implementation details	Stay focused on WHAT, not HOW
Proposing overly complex solutions	Start simple, add complexity only if needed
Ignoring existing codebase patterns	Research what exists first
Making assumptions without validating	State assumptions explicitly and confirm
Creating lengthy design documents	Keep it concise--details go in the plan

Success Criteria

• Design doc saved to docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
• User explicitly approves the spec before handoff to planning
• All open questions resolved or explicitly deferred with rationale

Integration

Brainstorming answers WHAT to build. Planning answers HOW. When brainstorm output exists, /ia-plan detects it and skips idea refinement.

• Next step: /ia-plan (always)
• Threat modeling: when the brainstorm involves auth, payments, external API surfaces, or multi-tenant data, suggest a ia-security-sentinel threat model before moving to planning. Catching trust boundary issues at the design stage prevents costly rework.
• Predecessor: user request or ambiguous feature description