Brainstorming Ideas Into Designs
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
The Process
Phase 1: Understanding the Idea
Check project context first:
- Read relevant files, docs, recent commits
- Understand existing patterns and conventions
- Identify constraints from the codebase
Ask questions one at a time:
- Only one question per message
- Prefer multiple choice questions when possible
- Open-ended questions are fine when choices aren't clear
- Focus on understanding: purpose, constraints, success criteria
Key questions to explore:
- What problem does this solve?
- Who are the users?
- What are the success criteria?
- What are the constraints?
- What already exists that this relates to?
Phase 2: Exploring Approaches
Propose 2-3 different approaches:
- Each approach should be meaningfully different
- Include tradeoffs for each
- Lead with your recommended option
- Explain why you recommend it
Present options conversationally:
I see three ways to approach this:
**Option 1: [Name]** (Recommended)
[Description]
- Pro: [advantage]
- Con: [disadvantage]
**Option 2: [Name]**
[Description]
- Pro: [advantage]
- Con: [disadvantage]
**Option 3: [Name]**
[Description]
- Pro: [advantage]
- Con: [disadvantage]
I recommend Option 1 because [reasoning].
Phase 3: Presenting the Design
Once you understand what to build:
- Break design into sections of 200-300 words
- Before presenting each section to the user, run section-level expert review
- Ask after each section: "Does this section look right?"
- Wait for confirmation before continuing
- Be ready to revise if something doesn't fit
Section-level expert review:
Before the user sees each design section, route it to relevant experts based on content keywords:
| Section Content Keywords |
Expert(s) Invoked |
| database, schema, migration, storage, persistence, query |
Data Systems Expert |
| page, form, button, display, UI, component, dashboard, click |
UX Expert + Accessibility Expert |
| endpoint, request, response, REST, API, HTTP |
REST API Guidelines skill + Security Expert |
| deploy, pipeline, build, release, CI/CD, container |
Continuous Delivery Expert + Cloud Expert |
| test, spec, scenario, assert, mock, stub, fixture |
Testing Expert |
| module, service, boundary, integration, composition, coupling |
Software Architecture Expert |
| user, PII, data collection, consent, retention, GDPR |
Privacy Expert |
| metric, SLO, monitor, alert, log, trace, observe |
SRE Expert |
| domain, entity, aggregate, bounded context, ubiquitous language |
Domain Design Expert |
| lead time, deployment frequency, feedback loop, batch size |
Engineering Effectiveness Expert |
| (always) |
Product Strategy Expert — reviews every section for product value |
For each section:
- Draft the section content
- Identify matching keywords to determine which experts to invoke
- Run the relevant expert review(s) on the section
- Incorporate expert feedback into the section
- Add a brief annotation noting which expert reviewed and what they suggested:
> Reviewed by Data Systems Expert: Suggested adding index strategy for the query pattern described.
> Reviewed by Product Strategy Expert: Confirmed this delivers clear user value.
- Present the improved section to the user
This adds latency to brainstorming but produces higher-quality designs. The end-of-plan Gherkin review (/review-features) still runs as a final pass, but the heavy lifting happens section-by-section here.
Sections to cover:
- Architecture overview
- Key components
- Data flow
- Error handling
- Testing approach
- Edge cases
Phase 4: After the Design
When invoked from the plan command (/tommymorgan:plan):
- Return the validated design to the calling command
- The plan command handles file creation and expert review
When invoked standalone:
- Write validated design to
<project>/plans/YYYY-MM-DD-<topic>.md
- Include all design decisions and rationale
- Commit the design document
Implementation (if continuing):
- Ask: "Ready to implement?"
- Use
/tommymorgan:work to execute the plan
Key Principles
One question at a time
Don't overwhelm with multiple questions. If a topic needs exploration, break it into sequential questions.
Multiple choice preferred
Easier to answer than open-ended. Use when you can enumerate reasonable options.
YAGNI ruthlessly
Remove unnecessary features from all designs. Build what's needed now, not what might be needed later.
Explore alternatives
Always propose 2-3 approaches before settling. The first idea is rarely the best.
Incremental validation
Present design in sections. Validate each before moving on. Catch misunderstandings early.
Be flexible
Go back and clarify when something doesn't make sense. The goal is the right design, not finishing fast.
Anti-Patterns to Avoid
- Asking multiple questions in one message
- Jumping to implementation before design is clear
- Presenting the entire design at once
- Assuming you understand without asking
- Adding features "just in case"
- Skipping the alternatives exploration
1---2name: brainstorming3description: Turn ideas into fully formed designs through collaborative dialogue4---56# Brainstorming Ideas Into Designs78Help turn ideas into fully formed designs and specs through natural collaborative dialogue.910## The Process1112### Phase 1: Understanding the Idea1314**Check project context first:**15- Read relevant files, docs, recent commits16- Understand existing patterns and conventions17- Identify constraints from the codebase1819**Ask questions one at a time:**20- Only one question per message21- Prefer multiple choice questions when possible22- Open-ended questions are fine when choices aren't clear23- Focus on understanding: purpose, constraints, success criteria2425**Key questions to explore:**26- What problem does this solve?27- Who are the users?28- What are the success criteria?29- What are the constraints?30- What already exists that this relates to?3132### Phase 2: Exploring Approaches3334**Propose 2-3 different approaches:**35- Each approach should be meaningfully different36- Include tradeoffs for each37- Lead with your recommended option38- Explain why you recommend it3940**Present options conversationally:**41```42I see three ways to approach this:4344**Option 1: [Name]** (Recommended)45[Description]46- Pro: [advantage]47- Con: [disadvantage]4849**Option 2: [Name]**50[Description]51- Pro: [advantage]52- Con: [disadvantage]5354**Option 3: [Name]**55[Description]56- Pro: [advantage]57- Con: [disadvantage]5859I recommend Option 1 because [reasoning].60```6162### Phase 3: Presenting the Design6364**Once you understand what to build:**65- Break design into sections of 200-300 words66- Before presenting each section to the user, run section-level expert review67- Ask after each section: "Does this section look right?"68- Wait for confirmation before continuing69- Be ready to revise if something doesn't fit7071**Section-level expert review:**7273Before the user sees each design section, route it to relevant experts based on content keywords:7475| Section Content Keywords | Expert(s) Invoked |76|---|---|77| database, schema, migration, storage, persistence, query | Data Systems Expert |78| page, form, button, display, UI, component, dashboard, click | UX Expert + Accessibility Expert |79| endpoint, request, response, REST, API, HTTP | REST API Guidelines skill + Security Expert |80| deploy, pipeline, build, release, CI/CD, container | Continuous Delivery Expert + Cloud Expert |81| test, spec, scenario, assert, mock, stub, fixture | Testing Expert |82| module, service, boundary, integration, composition, coupling | Software Architecture Expert |83| user, PII, data collection, consent, retention, GDPR | Privacy Expert |84| metric, SLO, monitor, alert, log, trace, observe | SRE Expert |85| domain, entity, aggregate, bounded context, ubiquitous language | Domain Design Expert |86| lead time, deployment frequency, feedback loop, batch size | Engineering Effectiveness Expert |87| *(always)* | Product Strategy Expert — reviews every section for product value |8889For each section:901. Draft the section content912. Identify matching keywords to determine which experts to invoke923. Run the relevant expert review(s) on the section934. Incorporate expert feedback into the section945. Add a brief annotation noting which expert reviewed and what they suggested:95 ```96 > Reviewed by Data Systems Expert: Suggested adding index strategy for the query pattern described.97 > Reviewed by Product Strategy Expert: Confirmed this delivers clear user value.98 ```996. Present the improved section to the user100101This adds latency to brainstorming but produces higher-quality designs. The end-of-plan Gherkin review (`/review-features`) still runs as a final pass, but the heavy lifting happens section-by-section here.102103**Sections to cover:**104- Architecture overview105- Key components106- Data flow107- Error handling108- Testing approach109- Edge cases110111### Phase 4: After the Design112113**When invoked from the plan command** (`/tommymorgan:plan`):114- Return the validated design to the calling command115- The plan command handles file creation and expert review116117**When invoked standalone:**118- Write validated design to `<project>/plans/YYYY-MM-DD-<topic>.md`119- Include all design decisions and rationale120- Commit the design document121122**Implementation (if continuing):**123- Ask: "Ready to implement?"124- Use `/tommymorgan:work` to execute the plan125126## Key Principles127128**One question at a time**129Don't overwhelm with multiple questions. If a topic needs exploration, break it into sequential questions.130131**Multiple choice preferred**132Easier to answer than open-ended. Use when you can enumerate reasonable options.133134**YAGNI ruthlessly**135Remove unnecessary features from all designs. Build what's needed now, not what might be needed later.136137**Explore alternatives**138Always propose 2-3 approaches before settling. The first idea is rarely the best.139140**Incremental validation**141Present design in sections. Validate each before moving on. Catch misunderstandings early.142143**Be flexible**144Go back and clarify when something doesn't make sense. The goal is the right design, not finishing fast.145146## Anti-Patterns to Avoid147148- Asking multiple questions in one message149- Jumping to implementation before design is clear150- Presenting the entire design at once151- Assuming you understand without asking152- Adding features "just in case"153- Skipping the alternatives exploration