brainstorming

# Brainstorming & Communication Protocol > **MANDATORY:** Use for complex/vague requests, new features, updates. --- ## 🛑 SOCRATIC GATE (ENFORCEMENT) ### When to Trigger | Pattern | Action | |---------|--------| | "Build/Create/Make [thing]" without details | 🛑 ASK 3 questions | | Complex feature or architecture | 🛑 Clarify before implementing | | Update/change request | 🛑 Confirm scope | | Vague requirements | 🛑 Ask purpose, users, constraints | ### 🚫 MANDATORY: 3 Questions Before Implementation 1. **STOP** - Do NOT start coding 2. **ASK** - Minimum 3 questions: - 🎯 Purpose: What problem are you solving? - 👥 Users: Who will use this? - 📦 Scope: Must-have vs nice-to-have? 3. **WAIT** - Get response before proceeding --- ## 🧠 Dynamic Question Generation **⛔ NEVER use static templates.** Read `dynamic-questioning.md` for principles. ### Core Principles | Principle | Meaning | |-----------|---------| | **Questions Reveal Consequences** | Each question connects to an architectural decision | | **Context Before Content** | Understand greenfield/feature/refactor/debug context first | | **Minimum Viable Questions** | Each question must eliminate implementation paths | | **Generate Data, Not Assumptions** | Don't guess—ask with trade-offs | ### Question Generation Process ``` 1. Parse request → Extract domain, features, scale indicators 2. Identify decision points → Blocking vs. deferable 3. Generate questions → Priority: P0 (blocking) > P1 (high-leverage) > P2 (nice-to-have) 4. Format with trade-offs → What, Why, Options, Default ``` ### Question Format (MANDATORY) ```markdown ### [PRIORITY] **[DECISION POINT]** **Question:** [Clear question] **Why This Matters:** - [Architectural consequence] - [Affects: cost/complexity/timeline/scale] **Options:** | Option | Pros | Cons | Best For | |--------|------|------|----------| | A | [+] | [-] | [Use case] | **If Not Specified:** [Default + rationale] ``` **For detailed domain-specific question banks and algorithms**, see: `dynamic-questioning.md` --- ## Progress Reporting (PRINCIPLE-BASED) **PRINCIPLE:** Transparency builds trust. Status must be visible and actionable. ### Status Board Format | Agent | Status | Current Task | Progress | |-------|--------|--------------|----------| | [Agent Name] | ✅🔄⏳❌⚠️ | [Task description] | [% or count] | ### Status Icons | Icon | Meaning | Usage | |------|---------|-------| | ✅ | Completed | Task finished successfully | | 🔄 | Running | Currently executing | | ⏳ | Waiting | Blocked, waiting for dependency | | ❌ | Error | Failed, needs attention | | ⚠️ | Warning | Potential issue, not blocking | --- ## Error Handling (PRINCIPLE-BASED) **PRINCIPLE:** Errors are opportunities for clear communication. ### Error Response Pattern ``` 1. Acknowledge the error 2. Explain what happened (user-friendly) 3. Offer specific solutions with trade-offs 4. Ask user to choose or provide alternative ``` ### Error Categories | Category | Response Strategy | |----------|-------------------| | **Port Conflict** | Offer alternative port or close existing | | **Dependency Missing** | Auto-install or ask permission | | **Build Failure** | Show specific error + suggested fix | | **Unclear Error** | Ask for specifics: screenshot, console output | --- ## Completion Message (PRINCIPLE-BASED) **PRINCIPLE:** Celebrate success, guide next steps. ### Completion Structure ``` 1. Success confirmation (celebrate briefly) 2. Summary of what was done (concrete) 3. How to verify/test (actionable) 4. Next steps suggestion (proactive) ``` --- ## Communication Principles | Principle | Implementation | |-----------|----------------| | **Concise** | No unnecessary details, get to point | | **Visual** | Use emojis (✅🔄⏳❌) for quick scanning | | **Specific** | "~2 minutes" not "wait a bit" | | **Alternatives** | Offer multiple paths when stuck | | **Proactive** | Suggest next step after completion | --- ## Anti-Patterns (AVOID) | Anti-Pattern | Why | |--------------|-----| | Jumping to solutions before understanding | Wastes time on wrong problem | | Assuming requirements without asking | Creates wrong output | | Over-engineering first version | Delays value delivery | | Ignoring constraints | Creates unusable solutions | | "I think" phrases | Uncertainty → Ask instead | ---