brainstorming

MUST use before:

• Creating new features
• Building new components
• Adding significant functionality
• Modifying core behavior
• Any task that takes more than 30 minutes

Skip only for:

• Simple bug fixes with obvious solutions
• Documentation updates
• Trivial configuration changes

Phase 1: Understanding the Idea

First, check current project state:

• Review relevant files and docs
• Check recent commits
• Understand existing patterns

Then ask questions one at a time:

• MANDATORY: Use the AskUserQuestion tool for ALL questions.
• Prefer multiple choice options within the tool whenever possible.
• Open-ended questions should also use AskUserQuestion (users can use the 'Other' option).
• Only one question per tool call.
• If topic needs more exploration, break into multiple sequential tool calls.

Focus on understanding:

• Purpose: What problem does this solve?
• Constraints: What limitations exist?
• Success criteria: How do we know it works?
• Edge cases: What could go wrong?

Phase 2: Exploring Approaches

Always propose 2-3 different approaches with trade-offs:

```

I see three possible approaches:

Option A: [Name]

• Pros: Simple, fast to implement
• Cons: May not scale, harder to test
• Best for: Quick prototypes

Option B: [Name]

• Pros: Scalable, well-tested pattern
• Cons: More complex, longer implementation
• Best for: Production systems

Option C: [Name]

• Pros: Flexible, future-proof
• Cons: Over-engineered for current needs
• Best for: When requirements are uncertain

My recommendation: Option B because [reasoning]

Which approach resonates with your goals?

```

Lead with your recommended option and explain why.

Phase 3: Presenting the Design

Once you understand what you're building, present the design:

1. Break it into sections of 200-300 words
2. Ask after each section: "Does this look right so far?"
3. Be ready to go back and clarify if something doesn't make sense

Cover these areas:

• Architecture: How components fit together
• Components: What pieces we need to build
• Data flow: How information moves through the system
• Error handling: What happens when things fail
• Testing: How we verify it works

Phase 4: Documentation

After design is validated:

1. Write the design to docs/plans/YYYY-MM-DD--design.md
2. Commit the design document to git
3. Ask: "Ready to set up for implementation?"

Multiple Choice (MANDATORY TOOL USE)

Always use the AskUserQuestion tool for structured feedback:

```json

{

"questions": [

{

"header": "Auth Method",

"question": "How should users authenticate?",

"options": [

{"label": "JWT Tokens", "description": "Stateless, scalable"},

{"label": "Server Sessions", "description": "Simple, secure"},

{"label": "OAuth Only", "description": "Delegate to providers"}

],

"multiSelect": false

}

]

}

```

Open-Ended (Using Tool)

Even for open-ended questions, use the tool. The CLI will provide an "Other" option for custom text input.

"What's the most important user story for this feature?"

Clarifying

"You mentioned 'fast' - what response time would feel fast enough?"

---

| Anti-Pattern | Better Approach |

|--------------|-----------------|

| Multiple questions at once | One question per message |

| Jumping to implementation | Complete design first |

| Assuming requirements | Ask to confirm |

| Presenting 1000-word designs | 200-300 word sections |

| Ignoring trade-offs | Always present alternatives |

| Skipping edge cases | Explore failure modes |

```markdown

# [Feature Name] Design

Date: YYYY-MM-DD

Author: Grandmaster (with user collaboration)

Status: Draft | Approved | Implemented

What problem are we solving? Why does it matter?

• Primary goal
• Secondary goals
• Non-goals (explicitly out of scope)

Architecture

How components fit together.

Components

1. Component A

- Purpose

- Interface

- Dependencies

1. Component B

- Purpose

- Interface

- Dependencies

Data Flow

1. User action triggers X
2. X calls Y with Z
3. Y returns result
4. Result displayed to user

Error Handling

| Error | Handling | User Message |

|-------|----------|--------------|

| Network failure | Retry 3x | "Connection lost, retrying..." |

| Invalid input | Reject | "Please check your input" |

• Unit tests for each component
• Integration test for happy path
• Edge case tests for error handling

• [ ] Question 1
• [ ] Question 2

| Date | Decision | Rationale |

|------|----------|-----------|

| YYYY-MM-DD | Chose Option B | Better scalability |

```

Triggering Brainstorming

User can invoke explicitly:

```

/maestro design [feature description]

```

Or system detects complex task and suggests:

```

This looks like a significant feature. Would you like to

brainstorm the design first, or proceed directly?

```

After Brainstorming

1. If continuing to implementation:

- Use @planning-mastery to create detailed plan

- Use @git-worktrees to create isolated workspace

1. If pausing:

- Design document is saved

- Can resume later with /maestro plan [design-doc]

---

When Ralph Wiggum is active with "Feature Mode":

1. Before first iteration: Run brainstorming phase
2. Design document: Required before implementation begins
3. Scope lock: Don't add features not in design
4. Design changes: Require explicit approval

| Principle | Description |

|-----------|-------------|

| One question at a time | Don't overwhelm with multiple questions |

| Multiple choice preferred | Easier to answer than open-ended |

| YAGNI ruthlessly | Remove unnecessary features from designs |

| Explore alternatives | Always propose 2-3 approaches |

| Incremental validation | Present design in sections, validate each |

| Be flexible | Go back and clarify when needed |

---

• @planning-mastery - Create implementation plan from design
• @git-worktrees - Set up isolated workspace
• @tdd-mastery - Implement with tests first
• @clean-code - Quality standards for implementation