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 |
