/brainstorm

Explore requirements before implementation. Separates WHAT from HOW to ensure the right problem is being solved before any code is written.

Usage

/brainstorm <topic>

Arguments

• •topic: The feature, problem, or idea to explore (e.g., "user notifications", "improve search performance")

Constraints

STRICT RULES — these are non-negotiable:

• •NO code generation
• •NO implementation details
• •NO technology choices
• •NO architecture decisions
• •Focus ONLY on requirements: what the user needs, not how to build it

Instructions

When this skill is invoked:

Agent Behavior

Autonomy:

• •Drive the conversation with probing questions
• •Synthesize answers into a focused requirements document
• •Hand off cleanly to /feature when ready

Discipline:

• •Ask ONE question at a time (max 5 questions total)
• •Keep questions specific and grounded
• •Stop exploring when requirements are clear enough to act on
• •Aim for 200-300 word output document (not a novel)

Process

Phase 0: Assess Need

Before starting, quickly determine if brainstorming is needed:

Skip brainstorming if:

• •User already has a detailed PRD
• •Requirements are crystal clear from the request
• •It's a straightforward CRUD feature with no ambiguity

If skipping: Say "Requirements are clear — ready for /feature {topic}" and stop.

Phase 1: Discovery (Max 5 Questions)

Ask probing questions to understand the real need. Pick from these angles based on what's unclear:

Core Need:

• •What problem does this solve for the user?
• •What happens today without this feature?
• •Who uses this and in what context?

Scope & Boundaries:

• •What's the simplest version that delivers value?
• •What's explicitly out of scope?
• •Are there existing features this overlaps with?

User Experience:

• •What does the user see/do when this works correctly?
• •What should happen when things go wrong?
• •Are there accessibility or performance expectations?

Edge Cases:

• •What are the boundary conditions?
• •What happens with no data? Maximum data?
• •Are there concurrent usage concerns?

Success Criteria:

• •How will we know this feature is working correctly?
• •What metrics matter?
• •What would make this feature a failure?

Rules:

• •Ask ONE question at a time
• •Wait for the answer before asking the next
• •Adapt follow-up questions based on answers
• •Stop early if requirements become clear (don't force all 5)

Phase 2: Synthesize Requirements

After gathering answers, produce a focused requirements document:

## Requirements: {Topic}

### Must Have
- {Core requirement 1}
- {Core requirement 2}
- {Core requirement 3}

### Should Have
- {Important but not blocking}
- {Nice-to-have that adds clear value}

### Out of Scope
- {Explicitly excluded}
- {Future consideration, not now}

### Success Criteria
- {Measurable criterion 1}
- {Measurable criterion 2}

### Open Questions
- {Anything still unresolved}

Guidelines:

• •200-300 words maximum
• •Use MoSCoW categories (Must/Should/Out of Scope)
• •Be specific — "fast" is not a requirement, "responds in < 200ms" is
• •Include success criteria that can be tested

Phase 3: Hand Off

Present the requirements document and offer next steps:

Requirements ready for: {topic}

Next steps:
1. `/feature {topic}` — Start full implementation lifecycle
2. `/feature {topic} --prd-only` — Create detailed PRD first
3. Refine — Ask me to adjust any requirements above

Example

$ /brainstorm user notifications

Let me explore what you need before we start building.

What problem does this solve? Are users currently missing important
events, or is this about engagement/retention?

> Users miss important status changes on their orders

Got it — order status notifications. How should users receive these?
(e.g., in-app only, email, push, SMS?)

> In-app and email for now, push notifications later

What order status changes matter? All of them, or specific transitions?

> Shipped, delivered, and delayed — those are the ones customers ask about

---

## Requirements: User Notifications

### Must Have
- Notify users when order status changes to: shipped, delivered, delayed
- In-app notification center (unread count, mark as read)
- Email notifications for each status change
- User can view notification history

### Should Have
- User preferences to disable specific notification types
- Email templates with order details and tracking link

### Out of Scope
- Push notifications (future phase)
- SMS notifications
- Real-time WebSocket delivery (polling is acceptable for v1)

### Success Criteria
- Users receive in-app notification within 30 seconds of status change
- Email delivered within 5 minutes of status change
- Notification center loads in < 500ms

### Open Questions
- Should delayed notifications include estimated new delivery date?

---

Next steps:
1. `/feature user-notifications` — Start implementation
2. `/feature user-notifications --prd-only` — Create detailed PRD first
3. Refine — Adjust requirements above