brainstorming

# Universal Brainstorming Protocol **Purpose**: Bridge the gap between user intent ("Make it pop") and technical specification ("CSS Box Shadow"). **Core Rule**: Do NOT write code until you have a confirmed design (except for Trivial tasks). ## Phase 1: Assess & Understand **1. Complexity Assessment (MANDATORY)** At the start, classify the task to determine your mode: | Level | Criteria | Protocol | Reference | | :--- | :--- | :--- | :--- | | **TRIVIAL** | Clear requirements, standard pattern, single component (e.g., "Fix typo", "Add log"). | **Fast Path**: Skip deep research. Confirm plan in chat. Go. | `examples/demo_trivial.md` | | **MEDIUM** | Standard task but open details (e.g., "Add button", "Refactor function"). | **Standard**: 1-2 clarifying questions, 2 options, brief confirmation. | `examples/demo_medium.md` | | **COMPLEX** | High uncertainty, architectural impact, multiple components (e.g., "New System"). | **Deep Dive**: Research -> Mermaid -> Trade-offs -> Design Doc -> Sign-off. | `examples/demo_complex.md` | **2. Context Gathering (Tool Agnostic)** * **Search**: Use your environment's search capability (e.g., `grep`, `search_code`) to understand existing patterns. * *Guardrail*: **IF NO SEARCH TOOLS EXIST**, do NOT guess. Explicitly ask the user: *"I cannot scan the repo. Could you share `package.json` and relevant files?"* * **Reading**: Preferentially read `task.md`, `README.md`, or `.cursorrules` to align with project standards. --- ## Phas...