brainstorming-ideas（集思广益）

Brainstorming Ideas Into Designs

Transform vague ideas into fully-formed designs through structured collaborative dialogue.

Use TodoWrite to track these 7 phases:

1. Understand the idea (dialogue first, no agents)
2. Explore requirements (Starbursting questions)
3. Checkpoint - offer exploration/research options
4. Research similar solutions (if requested)
5. Present approaches with recommendation
6. Validate design incrementally
7. Document and next steps

Core Principles

• Dialogue first - Ask the user before spawning any agents
• One question at a time - Never batch multiple questions
• Multiple choice preferred - Easier to answer than open-ended
• "Other" always available - Free text input for custom responses
• YAGNI ruthlessly - Challenge every feature's necessity
• Incremental validation - Present design in 200-300 word sections
• Agents on request - Only explore/research when user chooses it

Phase 1: Understand the Idea

Start with dialogue, not agents. Ask the user directly.

1a. Initial Question

Use AskUserQuestion:

1b. Follow-up (based on response)

Ask clarifying questions using AskUserQuestion. Keep it conversational:

• "Can you describe this in a sentence or two?" (free text via "Other")
• "What triggered this idea?" with context-appropriate options
• "Is there an existing feature this builds on?"

Phase 2: Explore Requirements (Starbursting)

Ask questions one at a time using AskUserQuestion. Adapt based on idea type.

Question Framework (5WH)

Adaptive Questioning

• Skip questions when answers are obvious from context
• If user seems certain, move faster to approaches
• If user seems uncertain, explore deeper with sub-questions
• Use "Other" option to allow custom responses

2b. Surface Assumptions

Before moving on, explicitly list the assumptions embedded in the idea so far:

Based on our discussion, here are the assumptions I'm seeing:

1. [Assumption about users] — e.g., "Users want X in real-time"
2. [Assumption about tech] — e.g., "Our current DB can handle this load"
3. [Assumption about scope] — e.g., "This doesn't need to work offline"

Use AskUserQuestion:

If "Some wrong": ask which ones and adjust requirements. If "Not sure": flag risky assumptions for verification in Phase 4.

Phase 3: Checkpoint - Gather More Context?

After understanding requirements, ask before spawning any agents:

If user chooses "Explore codebase":

Task(
  subagent_type="Explore",
  prompt="Quick scan: project structure, tech stack, patterns relevant to [user's idea]",
  run_in_background=false
)

Then summarize findings and ask: "Based on this, should we also research external solutions?"

If user chooses "Check project history":

If claude-mem tools are available:

search({ query: "[topic keywords]", limit: 10 })
timeline({ query: "[topic keywords]", depth_before: 5, depth_after: 5 })

Summarize past decisions, known issues, and relevant context. Then ask if they want to also explore or research.

If user chooses "Research solutions":

Proceed to Phase 4.

If user chooses "Skip to approaches":

Jump directly to Phase 5 (Present Approaches).

Phase 4: Research Similar Solutions (If Requested)

Only run when user explicitly chose research in Phase 3.

4a. Perplexity Query

mcp__perplexity-ask__perplexity_ask({
  messages: [{
    role: "user",
    content: "How do leading [industry] products implement [feature type]? Include architectural patterns, UX approaches, and trade-offs. Focus on [tech stack] implementations."
  }]
})

4b. Follow Citations

After Perplexity response, WebFetch top 2-3 relevant sources:

WebFetch(url="<citation-url>", prompt="Extract implementation details, code patterns, and lessons learned for [feature]")

4c. Synthesize Findings

Present research summary before asking approach preference:

## Research Findings

**Common patterns:**

- [Pattern 1]: Used by X, Y. Trade-off: ...
- [Pattern 2]: Used by Z. Trade-off: ...

**Recommended for our context:** [Pattern] because [reasons]

Phase 5: Present Approaches

Use AskUserQuestion with 2-4 options:

Approach Template

For each option, briefly cover:

• What: Core implementation
• Trade-offs: Complexity vs flexibility, Now vs later
• Fits when: Scenario where this shines

Phase 6: Validate Design Incrementally

Present design in sections (~200-300 words each). After each section, use AskUserQuestion:

Design Sections

1. Architecture Overview - Components, responsibilities, relationships
2. Data Flow - How information moves through the system
3. API/Interface - External contracts and user interactions
4. Error Handling - Failure modes and recovery strategies
5. Testing Strategy - How to verify it works

YAGNI Checkpoints

At each section, actively challenge:

• "Do we need this now, or is it speculative?"
• "What's the simplest version that solves the problem?"
• "Can we defer this complexity?"

Phase 7: Document and Next Steps

7a. Write Design Document

Write(
  file_path="docs/plans/YYYY-MM-DD-<topic>-design.md",
  content="# [Feature] Design\n\n## Problem\n...\n## Solution\n...\n## Architecture\n..."
)

7b. Commit Design

git add docs/plans/*.md && git commit -m "docs: add [feature] design document"

7c. Implementation Handoff

Use AskUserQuestion:

Methodology Reference

This skill incorporates proven brainstorming techniques:

Examples

/brainstorming-ideas                    # Start open-ended brainstorm
/brainstorming-ideas user notifications # Brainstorm notification feature
/brainstorming-ideas auth flow          # Brainstorm authentication changes

Execute this collaborative brainstorming workflow now.