Name: brainstorm
Author: asabocinski

Prompt file imported from asabocinski/bravo-edd (.codex/prompts/brainstorm.md). Copyright stays with the author.

Brainstorm Command

Collaborative exploration before requirements capture (Phase 0)

Usage

/brainstorm <idea-or-request>
/brainstorm "Build a real-time notification system"
/brainstorm notes/rough-idea.txt

Examples

# From a direct idea
/brainstorm "I want to automate data quality checks"

# From a file with notes
/brainstorm docs/meeting-notes.md

# From a problem statement
/brainstorm "Our team spends too much time on manual data entry"

Overview

This is Phase 0 of the 5-phase AgentSpec workflow:

Phase 0: /brainstorm → .codex/sdd/features/BRAINSTORM_{FEATURE}.md (THIS COMMAND)
Phase 1: /define     → .codex/sdd/features/DEFINE_{FEATURE}.md
Phase 2: /design     → .codex/sdd/features/DESIGN_{FEATURE}.md
Phase 3: /build      → Code + .codex/sdd/reports/BUILD_REPORT_{FEATURE}.md
Phase 4: /ship       → .codex/sdd/archive/{FEATURE}/SHIPPED_{DATE}.md

The /brainstorm command explores ideas through dialogue before capturing formal requirements.

What This Command Does

Explore - Understand project context and existing patterns
Question - Ask one question at a time to clarify intent
Collect - Gather sample files, ground truth, or reference data for LLM grounding
Propose - Present 2-3 approaches with trade-offs
Simplify - Apply YAGNI to remove unnecessary features
Validate - Incrementally confirm understanding
Document - Generate BRAINSTORM document for /define

Process

Step 1: Gather Context

Read(CLAUDE.md)
Read(.codex/sdd/templates/BRAINSTORM_TEMPLATE.md)
Explore project structure, recent commits, existing patterns

Step 2: Discovery Questions

Ask questions ONE AT A TIME:

Question Type	When to Use
Multiple Choice	When options are clear (preferred)
Open-Ended	When exploring unknown territory
Clarifying	When answer was vague

Minimum: 3 questions before proposing approaches

Step 3: Sample Collection (LLM Grounding)

Ask about available samples to improve AI/LLM accuracy:

"Do you have any samples that could help ground the solution?
(a) Sample input files
(b) Expected output examples
(c) Ground truth / verified data
(d) None available"

If samples exist, analyze and document them in the BRAINSTORM output.

Step 4: Explore Approaches

Present 2-3 distinct approaches:

### Approach A: {Name} ⭐ Recommended
**Why:** {Reasoning}
**Pros:** {Benefits}
**Cons:** {Trade-offs}

### Approach B: {Name}
**Why not recommended:** {Reasoning}

Step 5: Apply YAGNI

For each feature, ask:

Do we need this for MVP?
Does this solve the core problem?

Remove features that don't pass. Document what was removed and why.

Step 6: Validate Incrementally

Present design in sections (200-300 words each):

Section → Check with user → Adjust if needed → Next section

Minimum: 2 validation checkpoints

Step 7: Generate Document

Write(.codex/sdd/features/BRAINSTORM_{FEATURE}.md)

Output

Artifact	Location
Brainstorm Document	`.codex/sdd/features/BRAINSTORM_{FEATURE}.md`

Next Step: /define .codex/sdd/features/BRAINSTORM_{FEATURE}.md

Quality Gate

Before marking complete:

[ ] Minimum 3 discovery questions asked
[ ] Sample collection question asked
[ ] At least 2 approaches explored
[ ] YAGNI applied (features removed)
[ ] Minimum 2 validations completed
[ ] User confirmed selected approach
[ ] Draft requirements included

Interaction Style

One Question at a Time

GOOD:
"What's the primary use case?
(a) Internal reporting
(b) Customer-facing
(c) Both"

BAD:
"What's the use case? Who are the users? What's the timeline?"

Lead with Recommendation

GOOD:
"I recommend Approach A because [reasoning].
Here are the alternatives to consider..."

BAD:
"Here are three approaches. Which one do you want?"

Be Ready to Go Back

GOOD:
"That's different from what I understood. Let me revise..."

BAD:
"Moving on to the next section..."

When to Use /brainstorm vs /define

Scenario	Use
Vague idea, need to explore	`/brainstorm`
Clear requirements, ready to capture	`/define` directly
Existing BRAINSTORM document	`/define <brainstorm-file>`
Meeting notes with clear asks	`/define` directly
"I want to build something but not sure what"	`/brainstorm`

Tips

Take your time - Exploration is about understanding, not speed
Ask why - "Why do you need this?" reveals true requirements
Challenge scope - Most features aren't needed for MVP
Trust the user - They know their domain, you know patterns
Document removed features - They might come back later

Handling Different Inputs

Input Type	Approach
Vague idea	Start with "Tell me more about..."
Specific request	Validate understanding, then explore approaches
Problem statement	Focus on pain points, then solutions
Feature request	Question the need, explore alternatives
Comparison request	Explore trade-offs, make recommendation

References

Agent: .codex/skills/brainstorm-agent.md
Template: .codex/sdd/templates/BRAINSTORM_TEMPLATE.md
Contracts: .codex/sdd/architecture/WORKFLOW_CONTRACTS.yaml
Next Phase: .codex/prompts/define.md

Install brainstorm and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Brainstorm Command > Collaborative exploration before requirements capture (Phase 0) ## Usage ```bash /brainstorm <idea-or-request> /brainstorm "Build a real-time notification system" /brainstorm notes/rough-idea.txt ``` ## Examples ```bash # From a direct idea /brainstorm "I want to automate data quality checks" # From a file with notes /brainstorm docs/meeting-notes.md # From a problem statement /brainstorm "Our team spends too much time on manual data entry" ``` --- ## Overview This is **Phase 0** of the 5-phase AgentSpec workflow: ```text Phase 0: /brainstorm → .codex/sdd/features/BRAINSTORM_{FEATURE}.md (THIS COMMAND) Phase 1: /define → .codex/sdd/features/DEFINE_{FEATURE}.md Phase 2: /design → .codex/sdd/features/DESIGN_{FEATURE}.md Phase 3: /build → Code + .codex/sdd/reports/BUILD_REPORT_{FEATURE}.md Phase 4: /ship → .codex/sdd/archive/{FEATURE}/SHIPPED_{DATE}.md ``` The `/brainstorm` command explores ideas through dialogue before capturing formal requirements. --- ## What This Command Does 1. **Explore** - Understand project context and existing patterns 2. **Question** - Ask one question at a time to clarify intent 3. **Collect** - Gather sample files, ground truth, or reference data for LLM grounding 4. **Propose** - Present 2-3 approaches with trade-offs 5. **Simplify** - Apply YAGNI to remove unnecessary features 6. **Validate** - Incrementally confirm understanding 7. **Document** - Generate BRAINSTORM document for /define --- ## Process ### Step 1: Gather Context ```markdown Read(CLAUDE.md) Read(.codex/sdd/templates/BRAINSTORM_TEMPLATE.md) Explore project structure, recent commits, existing patterns ``` ### Step 2: Discovery Questions Ask questions ONE AT A TIME: | Question Type | When to Use | |---------------|-------------| | Multiple Choice | When options are clear (preferred) | | Open-Ended | When exploring unknown territory | | Clarifying | When answer was vague | **Minimum:** 3 questions before proposing approaches ### Step 3: Sample Collection (LLM Grounding) Ask about available samples to improve AI/LLM accuracy: ```markdown "Do you have any samples that could help ground the solution? (a) Sample input files (b) Expected output examples (c) Ground truth / verified data (d) None available" ``` If samples exist, analyze and document them in the BRAINSTORM output. ### Step 4: Explore Approaches Present 2-3 distinct approaches: ```markdown ### Approach A: {Name} ⭐ Recommended **Why:** {Reasoning} **Pros:** {Benefits} **Cons:** {Trade-offs} ### Approach B: {Name} **Why not recommended:** {Reasoning} ``` ### Step 5: Apply YAGNI For each feature, ask: - Do we need this for MVP? - Does this solve the core problem? Remove features that don't pass. Document what was removed and why. ### Step 6: Validate Incrementally Present design in sections (200-300 words each): ```text Section → Check with user → Adjust if needed → Next section ``` **Minimum:** 2 validation checkpoints ### Step 7: Generate Document ```markdown Write(.codex/sdd/features/BRAINSTORM_{FEATURE}.md) ``` --- ## Output | Artifact | Location | |----------|----------| | **Brainstorm Document** | `.codex/sdd/features/BRAINSTORM_{FEATURE}.md` | **Next Step:** `/define .codex/sdd/features/BRAINSTORM_{FEATURE}.md` --- ## Quality Gate Before marking complete: ```text [ ] Minimum 3 discovery questions asked [ ] Sample collection question asked [ ] At least 2 approaches explored [ ] YAGNI applied (features removed) [ ] Minimum 2 validations completed [ ] User confirmed selected approach [ ] Draft requirements included ``` --- ## Interaction Style ### One Question at a Time ```markdown GOOD: "What's the primary use case? (a) Internal reporting (b) Customer-facing (c) Both" BAD: "What's the use case? Who are the users? What's the timeline?" ``` ### Lead with Recommendation ```markdown GOOD: "I recommend Approach A because [reasoning]. Here are the alternatives to consider..." BAD: "Here are three approaches. Which one do you want?" ``` ### Be Ready to Go Back ```markdown GOOD: "That's different from what I understood. Let me revise..." BAD: "Moving on to the next section..." ``` --- ## When to Use /brainstorm vs /define | Scenario | Use | |----------|-----| | Vague idea, need to explore | `/brainstorm` | | Clear requirements, ready to capture | `/define` directly | | Existing BRAINSTORM document | `/define <brainstorm-file>` | | Meeting notes with clear asks | `/define` directly | | "I want to build something but not sure what" | `/brainstorm` | --- ## Tips 1. **Take your time** - Exploration is about understanding, not speed 2. **Ask why** - "Why do you need this?" reveals true requirements 3. **Challenge scope** - Most features aren't needed for MVP 4. **Trust the user** - They know their domain, you know patterns 5. **Document removed features** - They might come back later --- ## Handling Different Inputs | Input Type | Approach | |------------|----------| | Vague idea | Start with "Tell me more about..." | | Specific request | Validate understanding, then explore approaches | | Problem statement | Focus on pain points, then solutions | | Feature request | Question the need, explore alternatives | | Comparison request | Explore trade-offs, make recommendation | --- ## References - Agent: `.codex/skills/brainstorm-agent.md` - Template: `.codex/sdd/templates/BRAINSTORM_TEMPLATE.md` - Contracts: `.codex/sdd/architecture/WORKFLOW_CONTRACTS.yaml` - Next Phase: `.codex/prompts/define.md`

{ "prompt": "# Brainstorm Command\n\n> Collaborative exploration before requirements capture (Phase 0)\n\n## Usage\n\n```bash\n/brainstorm <idea-or-request>\n/brainstorm \"Build a real-time notification system\"\n/brainstorm notes/rough-idea.txt\n```\n\n## Examples\n\n```bash\n# From a direct idea\n/brainstorm \"I want to automate data quality checks\"\n\n# From a file with notes\n/brainstorm docs/meeting-notes.md\n\n# From a problem statement\n/brainstorm \"Our team spends too much time on manual data entry\"\n```\n\n---\n\n## Overview\n\nThis is **Phase 0** of the 5-phase AgentSpec workflow:\n\n```text\nPhase 0: /brainstorm → .codex/sdd/features/BRAINSTORM_{FEATURE}.md (THIS COMMAND)\nPhase 1: /define → .codex/sdd/features/DEFINE_{FEATURE}.md\nPhase 2: /design → .codex/sdd/features/DESIGN_{FEATURE}.md\nPhase 3: /build → Code + .codex/sdd/reports/BUILD_REPORT_{FEATURE}.md\nPhase 4: /ship → .codex/sdd/archive/{FEATURE}/SHIPPED_{DATE}.md\n```\n\nThe `/brainstorm` command explores ideas through dialogue before capturing formal requirements.\n\n---\n\n## What This Command Does\n\n1. **Explore** - Understand project context and existing patterns\n2. **Question** - Ask one question at a time to clarify intent\n3. **Collect** - Gather sample files, ground truth, or reference data for LLM grounding\n4. **Propose** - Present 2-3 approaches with trade-offs\n5. **Simplify** - Apply YAGNI to remove unnecessary features\n6. **Validate** - Incrementally confirm understanding\n7. **Document** - Generate BRAINSTORM document for /define\n\n---\n\n## Process\n\n### Step 1: Gather Context\n\n```markdown\nRead(CLAUDE.md)\nRead(.codex/sdd/templates/BRAINSTORM_TEMPLATE.md)\nExplore project structure, recent commits, existing patterns\n```\n\n### Step 2: Discovery Questions\n\nAsk questions ONE AT A TIME:\n\n| Question Type | When to Use |\n|---------------|-------------|\n| Multiple Choice | When options are clear (preferred) |\n| Open-Ended | When exploring unknown territory |\n| Clarifying | When answer was vague |\n\n**Minimum:** 3 questions before proposing approaches\n\n### Step 3: Sample Collection (LLM Grounding)\n\nAsk about available samples to improve AI/LLM accuracy:\n\n```markdown\n\"Do you have any samples that could help ground the solution?\n(a) Sample input files\n(b) Expected output examples\n(c) Ground truth / verified data\n(d) None available\"\n```\n\nIf samples exist, analyze and document them in the BRAINSTORM output.\n\n### Step 4: Explore Approaches\n\nPresent 2-3 distinct approaches:\n\n```markdown\n### Approach A: {Name} ⭐ Recommended\n**Why:** {Reasoning}\n**Pros:** {Benefits}\n**Cons:** {Trade-offs}\n\n### Approach B: {Name}\n**Why not recommended:** {Reasoning}\n```\n\n### Step 5: Apply YAGNI\n\nFor each feature, ask:\n- Do we need this for MVP?\n- Does this solve the core problem?\n\nRemove features that don't pass. Document what was removed and why.\n\n### Step 6: Validate Incrementally\n\nPresent design in sections (200-300 words each):\n\n```text\nSection → Check with user → Adjust if needed → Next section\n```\n\n**Minimum:** 2 validation checkpoints\n\n### Step 7: Generate Document\n\n```markdown\nWrite(.codex/sdd/features/BRAINSTORM_{FEATURE}.md)\n```\n\n---\n\n## Output\n\n| Artifact | Location |\n|----------|----------|\n| **Brainstorm Document** | `.codex/sdd/features/BRAINSTORM_{FEATURE}.md` |\n\n**Next Step:** `/define .codex/sdd/features/BRAINSTORM_{FEATURE}.md`\n\n---\n\n## Quality Gate\n\nBefore marking complete:\n\n```text\n[ ] Minimum 3 discovery questions asked\n[ ] Sample collection question asked\n[ ] At least 2 approaches explored\n[ ] YAGNI applied (features removed)\n[ ] Minimum 2 validations completed\n[ ] User confirmed selected approach\n[ ] Draft requirements included\n```\n\n---\n\n## Interaction Style\n\n### One Question at a Time\n\n```markdown\nGOOD:\n\"What's the primary use case?\n(a) Internal reporting\n(b) Customer-facing\n(c) Both\"\n\nBAD:\n\"What's the use case? Who are the users? What's the timeline?\"\n```\n\n### Lead with Recommendation\n\n```markdown\nGOOD:\n\"I recommend Approach A because [reasoning].\nHere are the alternatives to consider...\"\n\nBAD:\n\"Here are three approaches. Which one do you want?\"\n```\n\n### Be Ready to Go Back\n\n```markdown\nGOOD:\n\"That's different from what I understood. Let me revise...\"\n\nBAD:\n\"Moving on to the next section...\"\n```\n\n---\n\n## When to Use /brainstorm vs /define\n\n| Scenario | Use |\n|----------|-----|\n| Vague idea, need to explore | `/brainstorm` |\n| Clear requirements, ready to capture | `/define` directly |\n| Existing BRAINSTORM document | `/define <brainstorm-file>` |\n| Meeting notes with clear asks | `/define` directly |\n| \"I want to build something but not sure what\" | `/brainstorm` |\n\n---\n\n## Tips\n\n1. **Take your time** - Exploration is about understanding, not speed\n2. **Ask why** - \"Why do you need this?\" reveals true requirements\n3. **Challenge scope** - Most features aren't needed for MVP\n4. **Trust the user** - They know their domain, you know patterns\n5. **Document removed features** - They might come back later\n\n---\n\n## Handling Different Inputs\n\n| Input Type | Approach |\n|------------|----------|\n| Vague idea | Start with \"Tell me more about...\" |\n| Specific request | Validate understanding, then explore approaches |\n| Problem statement | Focus on pain points, then solutions |\n| Feature request | Question the need, explore alternatives |\n| Comparison request | Explore trade-offs, make recommendation |\n\n---\n\n## References\n\n- Agent: `.codex/skills/brainstorm-agent.md`\n- Template: `.codex/sdd/templates/BRAINSTORM_TEMPLATE.md`\n- Contracts: `.codex/sdd/architecture/WORKFLOW_CONTRACTS.yaml`\n- Next Phase: `.codex/prompts/define.md`", "variables": [], "notes": "Explore ideas through collaborative dialogue before requirements capture (Phase 0)", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/asabocinski/bravo-edd", "path": ".codex/prompts/brainstorm.md", "ref": "ae4c539580470e782ac67d2dc4a4eabe9fc68336", "url": "https://github.com/asabocinski/bravo-edd/blob/ae4c539580470e782ac67d2dc4a4eabe9fc68336/.codex/prompts/brainstorm.md", "key": "asabocinski/bravo-edd/.codex/prompts/brainstorm.md" } } }

brainstorm

About