1---2name: brainstorming3description: Design-first methodology. Explore user intent, requirements and design before implementation. Turn ideas into fully formed specs through collaborative dialogue.4---5<domain_overview>
6# 💡 BRAINSTORMING: DESIGN BEFORE CODE
7> **Philosophy:** Understanding comes before implementation. A well-designed solution is half-implemented. Never code without a clear design.
8
9**HALLUCINATION FIREWALL MANDATE (CRITICAL):** Never propose software components or libraries without verification. AI-generated designs frequently fail by hallucinating non-existent packages or misinterpreting their capabilities. Every recommended 3rd-party library MUST be validated using `npm info` or equivalent before the plan is finalized. Furthermore, you MUST provide at least one 'Counter-Architecture' (Steel-man argument) that challenges your primary recommendation to prevent homogenized or biased designs.
10Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
11**Process:**
121. Understand the current project context
132. Ask questions one at a time to refine the idea
143. Present the design in small sections (200-300 words)
154. Check after each section whether it looks right
16---
17## 📋 WHEN TO USE
18**MUST use before:**
19- Creating new features
20- Building new components
21- Adding significant functionality
22- Modifying core behavior
23- Any task that takes more than 30 minutes
24**Skip only for:**
25- Simple bug fixes with obvious solutions
26- Documentation updates
27- Trivial configuration changes
28</domain_overview>
29<process_workflow>
30## 🔄 THE PROCESS
31### Phase 1: Understanding the Idea
32**First, check current project state:**
33- Review relevant files and docs
34- Check recent commits
35- Understand existing patterns
36**Then ask questions one at a time:**
37- **MANDATORY:** Use the `AskUserQuestion` tool for ALL questions.
38- Prefer multiple choice options within the tool whenever possible.
39- Open-ended questions should also use `AskUserQuestion` (users can use the 'Other' option).
40- **Only one question per tool call.**
41- If topic needs more exploration, break into multiple sequential tool calls.
42**Focus on understanding:**
43- Purpose: What problem does this solve?
44- Constraints: What limitations exist?
45- Success criteria: How do we know it works?
46- Edge cases: What could go wrong?
47### Phase 2: Exploring Approaches
48**Always propose 2-3 different approaches with trade-offs:**
49```
50I see three possible approaches:
51**Option A: [Name]**
52- Pros: Simple, fast to implement
53- Cons: May not scale, harder to test
54- Best for: Quick prototypes
55**Option B: [Name]**
56- Pros: Scalable, well-tested pattern
57- Cons: More complex, longer implementation
58- Best for: Production systems
59**Option C: [Name]**
60- Pros: Flexible, future-proof
61- Cons: Over-engineered for current needs
62- Best for: When requirements are uncertain
63**My recommendation:** Option B because [reasoning]
64Which approach resonates with your goals?
65```
66**Lead with your recommended option and explain why.**
67### Phase 3: Presenting the Design
68**Once you understand what you're building, present the design:**
691. **Break it into sections of 200-300 words**
702. **Ask after each section:** "Does this look right so far?"
713. **Be ready to go back and clarify** if something doesn't make sense
72**Cover these areas:**
73- Architecture: How components fit together
74- Components: What pieces we need to build
75- Data flow: How information moves through the system
76- Error handling: What happens when things fail
77- Testing: How we verify it works
78### Phase 4: Documentation
79**After design is validated:**
801. Write the design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
812. Commit the design document to git
823. Ask: "Ready to set up for implementation?"
83</process_workflow>
84<methodology_protocols>
85## 🎤 QUESTION TECHNIQUES
86### Multiple Choice (MANDATORY TOOL USE)
87Always use the `AskUserQuestion` tool for structured feedback:
88```json
89{
90 "questions": [
91 {
92 "header": "Auth Method",
93 "question": "How should users authenticate?",
94 "options": [
95 {"label": "JWT Tokens", "description": "Stateless, scalable"},
96 {"label": "Server Sessions", "description": "Simple, secure"},
97 {"label": "OAuth Only", "description": "Delegate to providers"}
98 ],
99 "multiSelect": false
100 }
101 ]
102}
103```
104### Open-Ended (Using Tool)
105Even for open-ended questions, use the tool. The CLI will provide an "Other" option for custom text input.
106"What's the most important user story for this feature?"
107### Clarifying
108"You mentioned 'fast' - what response time would feel fast enough?"
109---
110## 🚫 ANTI-PATTERNS TO AVOID
111| Anti-Pattern | Better Approach |
112|--------------|-----------------|
113| Multiple questions at once | One question per message |
114| Jumping to implementation | Complete design first |
115| Assuming requirements | Ask to confirm |
116| Presenting 1000-word designs | 200-300 word sections |
117| Ignoring trade-offs | Always present alternatives |
118| Skipping edge cases | Explore failure modes |
119</methodology_protocols>
120<design_artifacts>
121## 📝 DESIGN DOCUMENT TEMPLATE
122```markdown
123# [Feature Name] Design
124**Date:** YYYY-MM-DD
125**Author:** Grandmaster (with user collaboration)
126**Status:** Draft | Approved | Implemented
127## Problem Statement
128What problem are we solving? Why does it matter?
129## Goals
130- Primary goal
131- Secondary goals
132- Non-goals (explicitly out of scope)
133## Approach
134### Architecture
135How components fit together.
136### Components
1371. **Component A**
138 - Purpose
139 - Interface
140 - Dependencies
1412. **Component B**
142 - Purpose
143 - Interface
144 - Dependencies
145### Data Flow
1461. User action triggers X
1472. X calls Y with Z
1483. Y returns result
1494. Result displayed to user
150### Error Handling
151| Error | Handling | User Message |
152|-------|----------|--------------|
153| Network failure | Retry 3x | "Connection lost, retrying..." |
154| Invalid input | Reject | "Please check your input" |
155## Testing Strategy
156- Unit tests for each component
157- Integration test for happy path
158- Edge case tests for error handling
159## Open Questions
160- [ ] Question 1
161- [ ] Question 2
162## Decision Log
163| Date | Decision | Rationale |
164|------|----------|-----------|
165| YYYY-MM-DD | Chose Option B | Better scalability |
166```
167</design_artifacts>
168<integration_protocols>
169## 🔗 INTEGRATION WITH MAESTRO
170### Triggering Brainstorming
171User can invoke explicitly:
172```
173/maestro design [feature description]
174```
175Or system detects complex task and suggests:
176```
177This looks like a significant feature. Would you like to
178brainstorm the design first, or proceed directly?
179```
180### After Brainstorming
1811. **If continuing to implementation:**
182 - Use `@planning-mastery` to create detailed plan
183 - Use `@git-worktrees` to create isolated workspace
1842. **If pausing:**
185 - Design document is saved
186 - Can resume later with `/maestro plan [design-doc]`
187---
188## 🔗 RALPH WIGGUM INTEGRATION
189When Ralph Wiggum is active with "Feature Mode":
1901. **Before first iteration:** Run brainstorming phase
1912. **Design document:** Required before implementation begins
1923. **Scope lock:** Don't add features not in design
1934. **Design changes:** Require explicit approval
194</integration_protocols>
195<audit_and_reference>
196## 📋 KEY PRINCIPLES
197| Principle | Description |
198|-----------|-------------|
199| **One question at a time** | Don't overwhelm with multiple questions |
200| **Multiple choice preferred** | Easier to answer than open-ended |
201| **YAGNI ruthlessly** | Remove unnecessary features from designs |
202| **Explore alternatives** | Always propose 2-3 approaches |
203| **Incremental validation** | Present design in sections, validate each |
204| **Be flexible** | Go back and clarify when needed |
205---
206## 🔗 RELATED SKILLS
207- **@planning-mastery** - Create implementation plan from design
208- **@git-worktrees** - Set up isolated workspace
209- **@tdd-mastery** - Implement with tests first
210- **@clean-code** - Quality standards for implementation
211</audit_and_reference>
xenitv1