brainstorm

/​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