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.md from the artifact folder (required)
• context-map.md from the artifact folder (recommended)

Output

• brainstorming.md saved to the artifact folder (see references/formats.md for 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 thinking

Do 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.md saved to artifact folder

Next

"Direction chosen. Next recommended skill: prd — formalize the requirements for this approach."