Brainstorming & Communication Protocol

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

🛑 SOCRATIC GATE (ENFORCEMENT)

When to Trigger

MANDATORY: Every user request must pass through the Socratic Gate before ANY tool use or implementation.

Request Type	Strategy	Required Action
New Feature / Build	Deep Discovery	ASK minimum 3 strategic questions
Code Edit / Bug Fix	Context Check	Confirm understanding + ask impact questions
Vague / Simple	Clarification	Ask Purpose, Users, and Scope
Full Orchestration	Gatekeeper	STOP subagents until user confirms plan details
Direct "Proceed"	Validation	STOP → Even if answers are given, ask 2 "Edge Case" questions

Protocol:

•Never Assume: If even 1% is unclear, ASK.
•Handle Spec-heavy Requests: When user gives a list (Answers 1, 2, 3...), do NOT skip the gate. Instead, ask about Trade-offs or Edge Cases before starting.
•Wait: Do NOT invoke subagents or write code until the user clears the Gate.

🚫 MANDATORY: 3 Questions Before Implementation

•STOP - Do NOT start coding
•
ASK - Minimum 3 questions:
- •🎯 Purpose: What problem are you solving?
- •👥 Users: Who will use this?
- •📦 Scope: Must-have vs nice-to-have?
•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

code

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

code

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

code

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