| name | brainstorming |
| description | Use for ideation, requirements clarification, and architectural design. Adapts to task complexity (Trivial/Medium/Complex). |
| tier | 2 |
| version | 2.1 |
| status | active |
| changelog | Upgraded to Universal Gold Standard v2.1 (2026) - Added 3-Tier Assessment, Tool Agnosticism, and Safety Guardrails. |
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.
Phase 2: Explore & Visualize (The "How")
1. Smart Questions
- Ask ONE critical question at a time.
- Template: "To match your existing patterns for [X], do you prefer [Option A] or [Option B]?"
2. Visual Thinking
- Constraint: For MEDIUM/COMPLEX tasks, you MUST visualize the flow.
- Primary: Mermaid (Flowcharts/Sequence) only if confident the user's UI supports it.
- Fallback: ASCII Art or Bullet Lists if the environment is restricted (e.g., standard terminal).
3. The "Design Doc" Rule
- Trivial: No doc needed. Chat confirmation is enough.
- Medium/Complex: You MUST produce a Design Document (e.g.,
docs/design/feature-name.md).
- No File Access?: Output the full Markdown in chat and ask user to save it.
Phase 3: Converge & Verify (The "Gate")
1. Adversarial CoT Checklist (The "Final Gate")
Before asking for approval, explicitly check these in your internal thought process:
2. Handover Templates
- Presentation: "I have analyzed the options. Here is the proposed design for [Feature]: [Link to Doc / Summary]. Trade-offs considered: [A vs B]."
- Checkpoint: "Please confirm this approach matches your expectation before I proceed to implementation."
- Rejection: "Understood. You prefer [B]. I will pivot the design to focus on [B]. New plan..."
Rationalization Table (Anti-Patterns)
| Agent Excuse | Reality / Correct Action |
|---|
| "It's faster to just code it." | WRONG. Reworking bugs is slower. Validate first. |
| "I skipped options because it's trivial." | OK, but state: "This is trivial, I propose X. Proceed?" |
| "The user ignored my question." | RISKY. Don't guess. Ask again: "To avoid breaking X, I need to know Y." |
| "I can't see the file." | STOP. Ask for it. Do not hallucinate file contents. |
| "This seems standard." | VERIFY. Is it standard for this project? Check package.json. |
Edge Cases
- User provides full design: Summarize understanding, verify 1-2 assumptions, then Fast Track.
- Non-Code Idea: Switch to "Strategy" mode. Output a "Strategy Doc" instead of "Technical Spec".
- Legacy Code: If context is massive, ask user: "Which specific files should I anchor my design on?"
