Brainstorming Ideas Into Designs

Overview

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 in small sections (200-300 words), checking after each section whether it looks right so far.

Announce at start: "I'm using the brainstorming skill to refine this idea into a design."

Progress Tracking

Create TodoWrite todos for each phase:

• Understanding: Clarify the problem space
• Exploring: Investigate alternative approaches
• Presenting: Document proposed design
• Handoff: Transition to implementation

Mark each phase as in_progress when starting, completed when done. This makes progress visible and prevents skipping phases.

Using AskUserQuestion

Use the AskUserQuestion tool for structured decision points:

• Scope and constraint gathering
• Approach selection (after presenting options)
• Design section validation
• Documentation and implementation handoff

Keep free-form conversation for:

• Context-specific clarifications
• Deep-dive questions unique to this idea
• Exploring edge cases and nuances

Principle: Structured questions for decisions, conversational for discovery.

The Process

Phase 1: Understanding the Idea

Step 1: Check project context

• Read relevant files, docs, recent commits
• Understand what exists before proposing what to build

Step 2: Gather initial constraints

Use AskUserQuestion to understand scope:

Question: "What is the scope of this feature?"
Header: "Scope"
Options:
- MVP / Proof of concept: Minimal viable implementation to validate the idea
- Production-ready: Full implementation with error handling, tests, and docs
- Enhancement: Adding to existing feature rather than building new

Step 3: Identify target users (if unclear)

Use AskUserQuestion when user type matters:

Question: "Who is the primary user of this feature?"
Header: "User"
Options:
- End users: External users of the application
- Developers: Engineers working with the codebase
- Both: Needs to serve multiple user types

Step 4: Gather constraints

Use AskUserQuestion with multiSelect for constraints:

Question: "What constraints should I consider?"
Header: "Constraints"
multiSelect: true
Options:
- Performance-critical: Speed and efficiency are primary concerns
- Backwards compatible: Must not break existing functionality
- Security-sensitive: Requires security review and hardening
- External dependencies: Integrates with third-party services

Step 5: Context-specific questions

Continue with free-form questions one at a time:

• Purpose: What problem does this solve?
• Success criteria: How will we know it works?
• Any unique constraints or requirements

Phase 2: Exploring Approaches

Step 1: Identify 2-3 approaches

After understanding the idea, propose 2-3 different approaches:

• Describe each briefly with trade-offs
• Lead with your recommendation and explain why
• Keep descriptions concise (2-3 sentences each)

Step 2: Get approach selection

Use the AskUserQuestion tool (do NOT output as plain text):

Question: "Which approach would you prefer?" Header: "Approach" Options:

• [Approach A name] (recommended): [Brief description of why this is recommended]
• [Approach B name]: [Brief description and trade-off]
• [Approach C name]: [Brief description and trade-off] multiSelect: false

Generate option labels and descriptions dynamically based on the approaches identified.

Phase 3: Presenting the Design

Step 1: Present design in sections

Once approach is selected, present the design:

• Break into sections of 200-300 words
• Cover: architecture, components, data flow, error handling, testing
• One section at a time

Step 2: Validate each section

After each section, use AskUserQuestion:

Question: "Does this section of the design look right?"
Header: "Feedback"
Options:
- Looks good: This section is accurate, proceed to next
- Minor tweaks: Small changes needed, I will specify
- Needs rethinking: This approach has issues, let's discuss

If "Minor tweaks" or "Needs rethinking" selected, pause for their input.

Step 3: Handle feedback

• Looks good: Proceed to next section
• Minor tweaks: Wait for their specification, apply changes, re-validate section
• Needs rethinking: Discuss issues, potentially return to Phase 2

Phase 4: After the Design

Step 1: Documentation decision

Use the AskUserQuestion tool (do NOT output as plain text):

Question: "How should I proceed with documentation?" Header: "Docs" Options:

• Save and commit: Write design doc and commit to git
• Save only: Write design doc without committing
• Skip docs: Proceed without saving design document multiSelect: false

Step 2: Save design (if chosen)

• Write to docs/plans/YYYY-MM-DD-<topic>-design.md
• Use elements-of-style:writing-clearly-and-concisely skill if available
• Commit if "Save and commit" was selected

Step 3: Implementation handoff

Use the AskUserQuestion tool (do NOT output as plain text):

Question: "Ready to proceed with implementation?" Header: "Next step" Options:

• Set up worktree: Create isolated workspace and write implementation plan
• Just the plan: Write implementation plan in current workspace
• Stop here: I will handle implementation separately multiSelect: false

Step 4: Execute choice

• Set up worktree: Use workflow:git-worktrees, then workflow:writing-plans
• Just the plan: Use workflow:writing-plans directly
• Stop here: Report completion, offer to continue later

Key Principles

• Structured for decisions, conversational for discovery - AskUserQuestion for clear choices, free-form for exploration
• One question at a time - Don't overwhelm with multiple questions
• YAGNI ruthlessly - Remove unnecessary features from all designs
• Explore alternatives - Always propose 2-3 approaches before settling
• Incremental validation - Present design in sections, validate each
• Be flexible - Go back and clarify when something doesn't make sense

When to Skip AskUserQuestion

Use free-form text instead when:

• The question is highly context-specific
• Options would be artificial or unclear
• You need open-ended exploration
• The user has already indicated a preference conversationally

The "Other" option in AskUserQuestion always allows custom input, but some questions are better asked conversationally.

Integration

REQUIRED SUB-SKILLS (when continuing to implementation):

• workflow:git-worktrees - If "Set up worktree" selected
• workflow:writing-plans - For creating implementation plan

Pairs with:

• elements-of-style:writing-clearly-and-concisely - For design documentation