1---2name: brainstorming-503description: Design-first methodology. Explore user intent, requirements and design before implementation. Turn ideas into fully formed specs through collaborative dialogue. Use when this capability is needed.4---5<domain_overview>6# 💡 BRAINSTORMING: DESIGN BEFORE CODE7> **Philosophy:** Understanding comes before implementation. A well-designed solution is half-implemented. Never code without a clear design.89**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 context132. Ask questions one at a time to refine the idea143. Present the design in small sections (200-300 words)154. Check after each section whether it looks right16---17## 📋 WHEN TO USE18**MUST use before:**19- Creating new features20- Building new components21- Adding significant functionality22- Modifying core behavior23- Any task that takes more than 30 minutes24**Skip only for:**25- Simple bug fixes with obvious solutions26- Documentation updates27- Trivial configuration changes28</domain_overview>29<process_workflow>30## 🔄 THE PROCESS31### Phase 1: Understanding the Idea32**First, check current project state:**33- Review relevant files and docs34- Check recent commits35- Understand existing patterns36**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 Approaches48**Always propose 2-3 different approaches with trade-offs:**49```50I see three possible approaches:51**Option A: [Name]**52- Pros: Simple, fast to implement53- Cons: May not scale, harder to test54- Best for: Quick prototypes55**Option B: [Name]**56- Pros: Scalable, well-tested pattern57- Cons: More complex, longer implementation58- Best for: Production systems59**Option C: [Name]**60- Pros: Flexible, future-proof61- Cons: Over-engineered for current needs62- Best for: When requirements are uncertain63**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 Design68**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 sense72**Cover these areas:**73- Architecture: How components fit together74- Components: What pieces we need to build75- Data flow: How information moves through the system76- Error handling: What happens when things fail77- Testing: How we verify it works78### Phase 4: Documentation79**After design is validated:**801. Write the design to `docs/plans/YYYY-MM-DD-<topic>-design.md`812. Commit the design document to git823. Ask: "Ready to set up for implementation?"83</process_workflow>84<methodology_protocols>85## 🎤 QUESTION TECHNIQUES86### Multiple Choice (MANDATORY TOOL USE)87Always use the `AskUserQuestion` tool for structured feedback:88```json89{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": false100 }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### Clarifying108"You mentioned 'fast' - what response time would feel fast enough?"109---110## 🚫 ANTI-PATTERNS TO AVOID111| 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 TEMPLATE122```markdown123# [Feature Name] Design124**Date:** YYYY-MM-DD125**Author:** Grandmaster (with user collaboration)126**Status:** Draft | Approved | Implemented127## Problem Statement128What problem are we solving? Why does it matter?129## Goals130- Primary goal131- Secondary goals132- Non-goals (explicitly out of scope)133## Approach134### Architecture135How components fit together.136### Components1371. **Component A**138 - Purpose139 - Interface140 - Dependencies1412. **Component B**142 - Purpose143 - Interface144 - Dependencies145### Data Flow1461. User action triggers X1472. X calls Y with Z1483. Y returns result1494. Result displayed to user150### Error Handling151| Error | Handling | User Message |152|-------|----------|--------------|153| Network failure | Retry 3x | "Connection lost, retrying..." |154| Invalid input | Reject | "Please check your input" |155## Testing Strategy156- Unit tests for each component157- Integration test for happy path158- Edge case tests for error handling159## Open Questions160- [ ] Question 1161- [ ] Question 2162## Decision Log163| Date | Decision | Rationale |164|------|----------|-----------|165| YYYY-MM-DD | Chose Option B | Better scalability |166```167</design_artifacts>168<integration_protocols>169## 🔗 INTEGRATION WITH MAESTRO170### Triggering Brainstorming171User 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 Brainstorming1811. **If continuing to implementation:**182 - Use `@planning-mastery` to create detailed plan183 - Use `@git-worktrees` to create isolated workspace1842. **If pausing:**185 - Design document is saved186 - Can resume later with `/maestro plan [design-doc]`187---188## 🔗 RALPH WIGGUM INTEGRATION189When Ralph Wiggum is active with "Feature Mode":1901. **Before first iteration:** Run brainstorming phase1912. **Design document:** Required before implementation begins1923. **Scope lock:** Don't add features not in design1934. **Design changes:** Require explicit approval194</integration_protocols>195<audit_and_reference>196## 📋 KEY PRINCIPLES197| 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 SKILLS207- **@planning-mastery** - Create implementation plan from design208- **@git-worktrees** - Set up isolated workspace209- **@tdd-mastery** - Implement with tests first210- **@clean-code** - Quality standards for implementation211</audit_and_reference>212213---214> Converted and distributed by [TomeVault](https://tomevault.io/claim/xenitv1) — claim your Tome and manage your conversions.215<!-- tomevault:4.0:skill_md:2026-04-11 -->