Brainstorming Ideas Into Designs
Turn ideas into fully formed designs through natural collaborative dialogue.
Process: Understand context → Ask questions one at a time → Explore approaches → Present design incrementally → Validate each section.
Phase 1: Understanding
Check Project Context
Before asking questions:
- Review relevant files, docs, recent commits
- Understand existing patterns and constraints
- Note what's already built that relates
Ask Questions
Rules:
- One question per message
- Prefer multiple choice when possible
- Open-ended when exploration needed
- Break complex topics into multiple questions
Focus on:
- Purpose: What problem does this solve?
- Constraints: What must it work with?
- Success criteria: How do we know it's done?
Phase 2: Exploring Approaches
Once you understand the goal:
- Propose 2-3 different approaches
- Include trade-offs for each
- Lead with your recommendation and why
- Let user choose or refine
Example:
I see three approaches:
1. **Component-based** (recommended) - Fits your existing pattern,
easiest to test, but more files.
2. **Inline** - Fewer files, but harder to reuse and test.
3. **Hook-based** - Most flexible, but adds complexity you may not need.
I'd go with #1 because [reasoning]. Thoughts?
Phase 3: Presenting Design
Once approach is chosen:
- Present in sections (200-300 words each)
- After each section: "Does this look right so far?"
- Be ready to revise if something doesn't fit
Cover:
- Architecture / component structure
- Data flow
- Error handling
- Testing approach
- Edge cases
Phase 4: After Design
Document
Write validated design to:
docs/plans/YYYY-MM-DD-<topic>-design.md
Commit to git.
Implementation (if continuing)
Ask: "Ready to set up for implementation?"
Then:
- Use
dm-work:worktreesto create isolated workspace - Create beads for implementation tasks
- Use
dm-work:orchestratorpatterns for delegation
Key Principles
| Principle | Why |
|---|---|
| One question at a time | Don't overwhelm |
| Multiple choice preferred | Easier to answer |
| YAGNI ruthlessly | Remove unnecessary features |
| Explore alternatives | Always 2-3 approaches before settling |
| Incremental validation | Present design in sections |
| Be flexible | Go back when something doesn't fit |
Anti-Patterns
| Don't | Do Instead |
|---|---|
| Jump to implementation | Understand first, design second |
| Ask 5 questions at once | One question per message |
| Present monolithic design | Break into 200-300 word sections |
| Skip trade-off discussion | Always propose 2-3 approaches |
| Assume you understand | Validate understanding with user |
Quick Reference
1. Check project context (files, docs, commits)
2. Ask questions one at a time (prefer multiple choice)
3. Propose 2-3 approaches with trade-offs
4. Present design in sections, validate each
5. Write to docs/plans/YYYY-MM-DD-<topic>-design.md
6. If implementing: worktree → beads → orchestrate