diegosouzapw /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
/featurewhen 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