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. **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:

code

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:worktrees to create isolated workspace
•Create beads for implementation tasks
•Use dm-work: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/plans/YYYY-MM-DD-<topic>-design.md
6. If implementing: worktree → beads → orchestrate