Brainstorming & Communication Protocol

MANDATORY: Use for complex/vague requests, new features, updates.

🛑 SOCRATIC GATE (ENFORCEMENT)

When to Trigger

🧠 Memory Check (2026.5.13 — Before Questioning)

Before asking questions, check if past context exists:

0. CHECK MEMORY — Does .agents/memory/MEMORY.md exist?
   → YES: Read index. Apply relevant past decisions silently.
          Skip questions already answered in memory.
   → NO: Proceed with standard Socratic Gate.

🚫 MANDATORY: 3 Questions Before Implementation

1. STOP - Do NOT start coding
2. CHECK - Read .agents/memory/ for past context on this topic
3. ASK - Minimum 3 questions (skip any already answered via memory):

- 🎯 Purpose: What problem are you solving? - 👥 Users: Who will use this? - 📦 Scope: Must-have vs nice-to-have?

1. WAIT - Get response before proceeding
2. SAVE - After brainstorming, save key decisions: /remember [decision]

🧠 Dynamic Question Generation

⛔ NEVER use static templates. Read dynamic-questioning.md for principles.

Core Principles

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)

### [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

Status Icons

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

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

Anti-Patterns (AVOID)