Brainstorming
Explore 2-3 approaches to achieve a defined goal, evaluate trade-offs, and pick a direction with the user.
When to Use
- A goal is defined but the approach is not decided
- Multiple valid solutions exist and trade-offs need evaluation
- The user wants to see options before committing
- The problem can be solved in fundamentally different ways
- You need to stress-test assumptions before investing in a PRD
When NOT to use: The approach is already decided and confirmed, or a brainstorming.md with a chosen direction already exists.
Input
goal-definition.mdfrom the artifact folder (required)context-map.mdfrom the artifact folder (recommended)
Output
brainstorming.mdsaved to the artifact folder (seereferences/formats.mdfor template)
The Process
Step 1: Load Context
Read goal-definition.md and context-map.md from the artifact folder. If goal-definition.md is missing, tell the user to run goal-definition first.
Also check for project documentation listed in references/context-sources.md (docs/TechStack.md, docs/ProjectStructure.md). If available, use them to ground feasibility assessments.
Recap the problem statement and success criteria from the goal definition to confirm alignment.
Step 2: Scan for Prior Art
If a context-map.md exists, scan the codebase for:
- Existing patterns that could be extended or reused
- Similar features already implemented (how were they done?)
- Constraints that eliminate certain approaches
- Libraries already in the stack that could help
Ground your approaches in what actually exists. Don't propose approaches that ignore the codebase.
Step 3: Generate 2-3 Approaches
For each approach, provide:
- Name — a short descriptive label
- Description — 2-3 sentences explaining the approach
- Pros — concrete advantages
- Cons — concrete disadvantages
- Feasibility — High / Medium / Low, considering the existing codebase
- User Value — High / Medium / Low
- Risk — High / Medium / Low
Apply ideation lenses selectively — pick the ones that fit the problem:
- Simplification: "What's the version that's 10x simpler?"
- Inversion: "What if we approached this from the opposite direction?"
- Constraint removal: "What if we removed the hardest constraint?"
- Audience shift: "What if this were for a different user?"
- Combination: "What if we combined two existing approaches?"
Do NOT generate more than 3 approaches. Quality over quantity.
Step 4: Present Comparison
Present a side-by-side comparison table:
| Criterion | Approach 1 | Approach 2 | Approach 3 |
|---|---|---|---|
| User Value | |||
| Feasibility | |||
| Differentiation | |||
| Risk |
Lead with your recommendation and explain why:
"I recommend Approach 2 because [rationale]. It trades off [X] for [Y], which aligns with the success criteria because [reason]."
Step 5: Get User Decision
Ask the user which direction to take. One question, clear options:
Which approach should we proceed with?
A. Approach 1: [name]
B. Approach 2: [name] (recommended)
C. Approach 3: [name]
D. Hybrid or different direction — describe what you're thinkingDo NOT proceed until the user picks a direction.
Step 6: Document Chosen Direction
After the user decides, write brainstorming.md to the artifact folder using the template from references/formats.md. Include all approaches explored, the comparison, the chosen direction with rationale, and assumptions to validate.
Announce the saved path:
"Brainstorming saved to [path]/brainstorming.md."Common Rationalizations
| Rationalization | Reality |
|---|---|
| "The right approach is obvious" | Obvious approaches have hidden trade-offs. Exploring alternatives takes 10 minutes and often reveals a better path. |
| "We don't have time to explore options" | Picking the wrong approach wastes far more time than evaluating 2-3 options upfront. |
| "I'll just build the simplest thing" | Simplest is often right, but you should articulate WHY it's right, not just default to it. |
| "The user already told me how to build it" | Users describe solutions. Your job is to evaluate whether it's the best solution for their goal. |
| "More options means better analysis" | 2-3 well-evaluated approaches beat 10 shallow ones. Don't dilute attention. |
Red Flags
- Jumping straight to one approach without considering alternatives
- Approaches that ignore the existing codebase or tech stack
- No recommendation — presenting options without an opinion
- All approaches look the same (variations, not genuine alternatives)
- Proceeding without user selecting a direction
- Writing code or creating implementation files during brainstorming
Verification
Before handing off, confirm:
- Goal definition and context map loaded
- 2-3 genuinely different approaches explored
- Each approach has pros, cons, feasibility, value, and risk
- Comparison table included
- Recommendation given with rationale
- User has selected a direction
brainstorming.mdsaved to artifact folder
Next
"Direction chosen. Next recommended skill: prd — formalize the requirements for this approach."