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
- 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
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
| 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 |
tuyenht