Brainstorming

<domain_overview>

💡 BRAINSTORMING: DESIGN BEFORE CODE

Philosophy: Understanding comes before implementation. A well-designed solution is half-implemented. Never code without a clear design.

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. Help turn ideas into fully formed designs and specs through natural collaborative dialogue. Process:

1. Understand the current project context
2. Ask questions one at a time to refine the idea
3. Present the design in small sections (200-300 words)
4. Check after each section whether it looks right

📋 WHEN TO USE

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 </domain_overview> <process_workflow>

🔄 THE PROCESS

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-<topic>-design.md
2. Commit the design document to git
3. Ask: "Ready to set up for implementation?" </process_workflow> <methodology_protocols>