---
name: brainstorm-first
description: Mandatory design-before-implementation gate. Explores user intent, requirements, and design before any code is written. Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Prevents jumping straight into code without a design.
triggers:
  - build a feature
  - create a component
  - add functionality
  - let's build
  - implement this
  - new feature
---

# Brainstorm First

Turn ideas into fully formed designs through collaborative dialogue BEFORE any implementation begins.

## The Hard Gate

```
DO NOT write any code, scaffold any project, or take any implementation action
until a design has been presented and the user has approved it.
```

This applies to EVERY project regardless of perceived simplicity. "Simple" projects are where unexamined assumptions cause the most wasted work.

## When to Use

Trigger before any creative or implementation work:
- New features or components
- Significant modifications to existing behavior
- Architecture decisions
- UI/UX changes
- API design
- Any work where the user's intent needs clarification

## The Process

### Step 1: Explore Context

Before asking questions, understand the current state:
- Check existing files, docs, recent changes
- Understand the project structure
- Note existing patterns and conventions
- Identify constraints (tech stack, dependencies, deployment)

### Step 2: Ask Clarifying Questions

Ask ONE question at a time (not a wall of questions). Focus on:
- What problem does this solve?
- Who is the user/audience?
- What does success look like?
- What are the constraints (time, tech, scope)?
- What should this NOT do? (anti-goals)
- Are there examples of what they want it to feel like?

Keep asking until you can confidently describe what needs to be built. Usually 3-5 questions suffice.

### Step 3: Propose Approaches

Present 2-3 approaches with trade-offs and a recommendation:

```
APPROACH A: [Name]
- How it works: [Brief description]
- Pros: [Key advantages]
- Cons: [Key disadvantages]
- Best when: [Conditions where this is ideal]

APPROACH B: [Name]
- How it works: [Brief description]
- Pros: [Key advantages]
- Cons: [Key disadvantages]
- Best when: [Conditions where this is ideal]

RECOMMENDATION: [Which one and why]
```

### Step 4: Present Design

Once an approach is chosen, present the design in sections scaled to complexity:

**For simple projects** (1-2 paragraphs):
- What it does
- How it works
- Key decisions made

**For complex projects** (full design doc):
- Problem statement
- Proposed solution
- Architecture/structure
- Key interfaces/APIs
- Edge cases and error handling
- What is explicitly out of scope

### Step 5: Get Approval

Ask the user to confirm the design before proceeding. Accept one of:
- "Looks good" / approval → proceed to implementation
- Feedback → revise the design
- "Start over" → return to Step 2

### Step 6: Transition to Implementation

Once approved, proceed with implementation. Reference the design throughout to ensure alignment.

## Anti-Pattern Detection

If you catch yourself about to:
- Write code without a design → STOP
- Skip questions because "it's obvious" → STOP
- Implement the first idea without alternatives → STOP
- Start building before the user confirms → STOP

These are all violations of the brainstorm-first gate.

## Scaling the Process

| Project Complexity | Design Depth |
|---|---|
| Config change, typo fix | Skip this skill entirely |
| Simple utility, small feature | 2-3 questions, brief design (1 paragraph) |
| Medium feature, new component | 4-5 questions, 2-3 approaches, design doc |
| Large feature, architecture change | Full exploration, detailed design, explicit scope |

## Output

The brainstorm phase produces:
1. Clear problem statement
2. Chosen approach with rationale
3. Design document (complexity-appropriate)
4. User approval to proceed
5. Transition to implementation with clear scope