brainstorming-ideas

Turn ideas into designs through collaborative dialogue. Use when user wants to brainstorm, design features, explore approaches, or think through implementation before coding.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "brainstorming-ideas" with this command: npx skills add alexei-led/claude-code-config/alexei-led-claude-code-config-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:

HeaderQuestionOptions
Idea typeWhat would you like to brainstorm?1. New feature - Add new functionality 2. Modification - Change existing behavior 3. Integration - Connect with external system 4. Exploration - Not sure yet, let's discover

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)

Question TypeWhen to AskExample AskUserQuestion
WHOAlways first"Who will use this?" → Options: Existing users, New segment, Internal, API consumers
WHYAfter WHO"What problem does this solve?" → Options based on detected pain points
WHATAfter WHY is clear"What's the core capability?" → Open or options based on research
WHEREFor integrations/modifications"Where should this live?" → Options based on codebase exploration
HOWAfter approach research"How should we implement?" → Present 2-3 technical approaches

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:

HeaderQuestionOptions
AssumptionsAny of these assumptions wrong or risky?1. All correct - Proceed as-is 2. Some wrong - I'll clarify 3. Not sure - Let's validate the risky ones during research

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:

HeaderQuestionOptions
Next stepHow should we proceed?1. Explore codebase - Check existing patterns and tech stack 2. Research solutions - Look up how others solve this 3. Both - Explore then research 4. Skip to approaches - I know what I want

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 "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:

HeaderQuestionOptions
ApproachWhich approach fits best?1. [Recommended] - Description + key trade-off 2. [Alternative] - Description + key trade-off 3. Minimal - YAGNI version

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:

HeaderQuestionOptions
ValidateDoes this [section] look right?1. Yes, continue - Move to next section 2. Needs changes - I'll explain 3. Go back - Revisit earlier decisions

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:

HeaderQuestionOptions
Next stepsReady to proceed with implementation?1. Create worktree - Isolated workspace via using-git-worktrees 2. Create plan - Detailed implementation steps 3. Done for now - Just save the design

Methodology Reference

This skill incorporates proven brainstorming techniques:

TechniqueHow It's Used
Starbursting (5WH)Structured questions in Phase 2
Design ThinkingEmpathize (context) → Define (WHY) → Ideate → Prototype (design sections)
SCAMPERFor modifications: Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse
Reverse Brainstorming"How could this fail?" during validation
Mind MappingArchitecture section visualizes relationships

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.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

testing-e2e

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

refactoring-code

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

writing-typescript

No summary provided by upstream source.

Repository SourceNeeds Review