work-brainstormlisted

# Structured Brainstorming ## Goal Transform a raw idea into an approved design BEFORE specifying or implementing. Ideation phase between "I have a vague idea" and "here are the user stories". ``` Vague idea → BRAINSTORM → Validated design → /work:work-specify → /work:work-plan → /dev:dev-tdd ``` ## Iron Rule IMPORTANT: Do NOT invoke an implementation skill, write code, scaffold a project, or take any implementation action until the design has been presented AND approved by the user. ## Process ### 1. Explore the context Before proposing anything: - Read the relevant project files (architecture, existing code, CLAUDE.md) - Check recent changes (`git log --oneline -10`) - Identify existing technical constraints - Understand the "why" behind the idea ### 2. Clarify through questioning Ask clarification questions **one at a time** (not a block of 10 questions). | Question type | Example | |------------------|---------| | **Goal** | "What problem does this solve for the user?" | | **Scope** | "Should this work with X or is it independent?" | | **Constraints** | "Are there time, budget, or tech limits?" | | **Users** | "Who will use this? In what context?" | | **Success** | "How will we know it works well?" | Stop questioning when there is enough context to propose alternatives. ### 3. Propose 2-3 approaches For each approach, present: ```markdown ### Approach A: [Descriptive name] **Principle**: [1-2 sentences] **Pros**: - [Pro 1] - [Pro 2] **Cons**: - [Con 1]