@prpm-converter/cursorrules-brainstorming

# Brainstorming - Cursor Rules

---

## Overview

This cursor rule is based on the Claude Code "Brainstorming" skill, adapted for use in Cursor IDE.

## Core Methodology

When working on code, follow this brainstorming methodology:

1. [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
2. [ ] Phase 2: Exploration (2-3 approaches proposed and evaluated)
3. [ ] Phase 3: Design Presentation (design validated in sections)
4. [ ] Phase 4: Design Documentation (design written to docs/plans/)
5. [ ] Phase 5: Worktree Setup (if implementing)
6. [ ] Phase 6: Planning Handoff (if implementing)
7. Check current project state in working directory
8. Ask ONE question at a time to refine the idea
9. **Use AskUserQuestion tool** when you have multiple choice options
10. Gather: Purpose, constraints, success criteria
11. *Example using AskUserQuestion:**
12. "Session storage" (clears on tab close, more secure)
13. "Local storage" (persists across sessions, more convenient)
14. "Cookies" (works with SSR, compatible with older approach)
15. Propose 2-3 different approaches
16. For each: Core architecture, trade-offs, complexity assessment
17. **Use AskUserQuestion tool** to present approaches as structured choices
18. Ask your human partner which approach resonates
19. *Example using AskUserQuestion:**
20. "Event-driven with message queue" (scalable, complex setup, eventual consistency)
21. "Direct API calls with retry logic" (simple, synchronous, easier to debug)
22. "Hybrid with background jobs" (balanced, moderate complexity, best of both)
23. Present in 200-300 word sections
24. Cover: Architecture, components, data flow, error handling, testing
25. Ask after each section: "Does this look right so far?" (open-ended)
26. Use open-ended questions here to allow freeform feedback
27. **File location:** `docs/plans/YYYY-MM-DD-<topic>-design.md` (use actual date and descriptive topic)
28. **RECOMMENDED SUB-SKILL:** Use elements-of-style:writing-clearly-and-concisely (if available) for documentation quality
29. **Content:** Capture the design as discussed and validated in Phase 3, organized into the sections that emerged from the conversation
30. Commit the design document to git before proceeding
31. Announce: "I'm using the using-git-worktrees skill to set up an isolated workspace."
32. **REQUIRED SUB-SKILL:** Use superpowers:using-git-worktrees
33. Follow that skill's process for directory selection, safety verification, and setup
34. Return here when worktree ready
35. Announce: "I'm using the writing-plans skill to create the implementation plan."
36. **REQUIRED SUB-SKILL:** Use superpowers:writing-plans
37. Create detailed plan in the worktree
38. *Use AskUserQuestion for:**
39. Phase 1: Clarifying questions with 2-4 clear options
40. Phase 2: Architectural approach selection (2-3 alternatives)
41. Any decision with distinct, mutually exclusive choices
42. When options have clear trade-offs to explain
43. *Benefits:**
44. Structured presentation of options with descriptions
45. Clear trade-off visibility for partner
46. Forces explicit choice (prevents vague "maybe both" responses)
47. *Use open-ended questions for:**
48. Phase 3: Design validation ("Does this look right so far?")
49. When you need detailed feedback or explanation
50. When partner should describe their own requirements
51. When structured options would limit creative input
52. *Example decision flow:**
53. "What authentication method?" → Use AskUserQuestion (2-4 options)
54. "Does this design handle your use case?" → Open-ended (validation)
55. *You can and should go backward when:**
56. Partner reveals new constraint during Phase 2 or 3 → Return to Phase 1
57. Validation shows fundamental gap in requirements → Return to Phase 1
58. Partner questions approach during Phase 3 → Return to Phase 2
59. Something doesn't make sense → Go back and clarify
60. *Don't force forward linearly** when going backward would give better results.

## Principles

- Apply best practices from the skill content below

## Implementation Guidelines

- Reference the detailed skill content for specific guidance



## Integration with Other Rules

This rule works best when combined with:
- Code quality and style guidelines
- Testing best practices
- Project-specific conventions

You can reference other .cursorrules files by organizing them in your project:
```
.cursorrules/
  ├── base/
  │   ├── brainstorming.cursorrules (this file)
  │   └── code-quality.cursorrules
  └── project-specific.cursorrules
```

## Original Skill Content

The following is the complete content from the Claude Code skill for reference:

---

---
name: brainstorming
description: Use when creating or developing anything, before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
---

# Brainstorming Ideas Into Designs

## Overview

Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.

**Core principle:** Ask questions to understand, explore alternatives, present design incrementally for validation.

**Announce at start:** "I'm using the brainstorming skill to refine your idea into a design."

## Quick Reference

| Phase | Key Activities | Tool Usage | Output |
|-------|---------------|------------|--------|
| **1. Understanding** | Ask questions (one at a time) | AskUserQuestion for choices | Purpose, constraints, criteria |
| **2. Exploration** | Propose 2-3 approaches | AskUserQuestion for approach selection | Architecture options with trade-offs |
| **3. Design Presentation** | Present in 200-300 word sections | Open-ended questions | Complete design with validation |
| **4. Design Documentation** | Write design document | writing-clearly-and-concisely skill | Design doc in docs/plans/ |
| **5. Worktree Setup** | Set up isolated workspace | using-git-worktrees skill | Ready development environment |
| **6. Planning Handoff** | Create implementation plan | writing-plans skill | Detailed task breakdown |

## The Process

Copy this checklist to track progress:

```
Brainstorming Progress:
- [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
- [ ] Phase 2: Exploration (2-3 approaches proposed and evaluated)
- [ ] Phase 3: Design Presentation (design validated in sections)
- [ ] Phase 4: Design Documentation (design written to docs/plans/)
- [ ] Phase 5: Worktree Setup (if implementing)
- [ ] Phase 6: Planning Handoff (if implementing)
```

### Phase 1: Understanding
- Check current project state in working directory
- Ask ONE question at a time to refine the idea
- **Use AskUserQuestion tool** when you have multiple choice options
- Gather: Purpose, constraints, success criteria

**Example using AskUserQuestion:**
```
Question: "Where should the authentication data be stored?"
Options:
  - "Session storage" (clears on tab close, more secure)
  - "Local storage" (persists across sessions, more convenient)
  - "Cookies" (works with SSR, compatible with older approach)
```

### Phase 2: Exploration
- Propose 2-3 different approaches
- For each: Core architecture, trade-offs, complexity assessment
- **Use AskUserQuestion tool** to present approaches as structured choices
- Ask your human partner which approach resonates

**Example using AskUserQuestion:**
```
Question: "Which architectural approach should we use?"
Options:
  - "Event-driven with message queue" (scalable, complex setup, eventual consistency)
  - "Direct API calls with retry logic" (simple, synchronous, easier to debug)
  - "Hybrid with background jobs" (balanced, moderate complexity, best of both)
```

### Phase 3: Design Presentation
- Present in 200-300 word sections
- Cover: Architecture, components, data flow, error handling, testing
- Ask after each section: "Does this look right so far?" (open-ended)
- Use open-ended questions here to allow freeform feedback

### Phase 4: Design Documentation
After design is validated, write it to a permanent document:
- **File location:** `docs/plans/YYYY-MM-DD-<topic>-design.md` (use actual date and descriptive topic)
- **RECOMMENDED SUB-SKILL:** Use elements-of-style:writing-clearly-and-concisely (if available) for documentation quality
- **Content:** Capture the design as discussed and validated in Phase 3, organized into the sections that emerged from the conversation
- Commit the design document to git before proceeding

### Phase 5: Worktree Setup (for implementation)
When design is approved and implementation will follow:
- Announce: "I'm using the using-git-worktrees skill to set up an isolated workspace."
- **REQUIRED SUB-SKILL:** Use superpowers:using-git-worktrees
- Follow that skill's process for directory selection, safety verification, and setup
- Return here when worktree ready

### Phase 6: Planning Handoff
Ask: "Ready to create the implementation plan?"

When your human partner confirms (any affirmative response):
- Announce: "I'm using the writing-plans skill to create the implementation plan."
- **REQUIRED SUB-SKILL:** Use superpowers:writing-plans
- Create detailed plan in the worktree

## Question Patterns

### When to Use AskUserQuestion Tool

**Use AskUserQuestion for:**
- Phase 1: Clarifying questions with 2-4 clear options
- Phase 2: Architectural approach selection (2-3 alternatives)
- Any decision with distinct, mutually exclusive choices
- When options have clear trade-offs to explain

**Benefits:**
- Structured presentation of options with descriptions
- Clear trade-off visibility for partner
- Forces explicit choice (prevents vague "maybe both" responses)

### When to Use Open-Ended Questions

**Use open-ended questions for:**
- Phase 3: Design validation ("Does this look right so far?")
- When you need detailed feedback or explanation
- When partner should describe their own requirements
- When structured options would limit creative input

**Example decision flow:**
- "What authentication method?" → Use AskUserQuestion (2-4 options)
- "Does this design handle your use case?" → Open-ended (validation)

## When to Revisit Earlier Phases

```dot
digraph revisit_phases {
    rankdir=LR;
    "New constraint revealed?" [shape=diamond];
    "Partner questions approach?" [shape=diamond];
    "Requirements unclear?" [shape=diamond];
    "Return to Phase 1" [shape=box, style=filled, fillcolor="#ffcccc"];
    "Return to Phase 2" [shape=box, style=filled, fillcolor="#ffffcc"];
    "Continue forward" [shape=box, style=filled, fillcolor="#ccffcc"];

    "New constraint revealed?" -> "Return to Phase 1" [label="yes"];
    "New constraint revealed?" -> "Partner questions approach?" [label="no"];
    "Partner questions approach?" -> "Return to Phase 2" [label="yes"];
    "Partner questions approach?" -> "Requirements unclear?" [label="no"];
    "Requirements unclear?" -> "Return to Phase 1" [label="yes"];
    "Requirements unclear?" -> "Continue forward" [label="no"];
}
```

**You can and should go backward when:**
- Partner reveals new constraint during Phase 2 or 3 → Return to Phase 1
- Validation shows fundamental gap in requirements → Return to Phase 1
- Partner questions approach during Phase 3 → Return to Phase 2
- Something doesn't make sense → Go back and clarify

**Don't force forward linearly** when going backward would give better results.

## Key Principles

| Principle | Application |
|-----------|-------------|
| **One question at a time** | Phase 1: Single question per message, use AskUserQuestion for choices |
| **Structured choices** | Use AskUserQuestion tool for 2-4 options with trade-offs |
| **YAGNI ruthlessly** | Remove unnecessary features from all designs |
| **Explore alternatives** | Always propose 2-3 approaches before settling |
| **Incremental validation** | Present design in sections, validate each |
| **Flexible progression** | Go backward when needed - flexibility > rigidity |
| **Announce usage** | State skill usage at start of session |


---

## Usage Notes

- Apply these principles consistently throughout development
- Adapt the methodology to fit your specific project context
- Combine with project-specific rules for best results
- Use this as a reference for the brainstorming approach

---
*Converted from Claude Code Skill: brainstorming*
*Source: brainstorming skill*