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:
code
I see three approaches: 1. **Data-oriented** (recommended) - Fits your existing pattern, easiest to test, but more dicts/dataclasses. 2. **Protocol-based** - More structured, but adds complexity. 3. **Functional composition** - Most flexible, but harder to trace. 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 / module structure
- •Data flow
- •Error handling
- •Testing approach
- •Edge cases
Phase 4: After Design
Document
Write validated design to:
code
docs/design/YYYY-MM-DD-<topic>-design.md
Commit to git.
Implementation (if continuing)
Ask: "Ready to set up for implementation?"
Then:
- •Use worktrees skill to create isolated workspace
- •Create beads for implementation tasks
- •Use orchestrator patterns 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
code
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/design/YYYY-MM-DD-<topic>-design.md 6. If implementing: worktree -> beads -> orchestrate