brainstorming

What this skill does

# 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