| name | clarification-protocol |
| description | Generate targeted clarifying questions (2-3 max) that challenge vague requirements and extract missing context. Use after request-analyzer identifies clarification needs, before routing to specialist agents. Helps cto-orchestrator avoid delegating unclear requirements. |
Clarification Protocol
Generates focused, challenging questions to extract missing context and clarify vague requirements before routing to specialist agents.
When to Use
- After request-analyzer identifies vague terms or missing context
- When requirements are ambiguous and could lead to wrong solutions
- Before delegating to cto-architect or strategic-cto-mentor
- When buzzwords need to be translated into specific requirements
Core Principles
1. Maximum 2-3 Questions Per Round
Users lose patience with long questionnaires. Prioritize ruthlessly:
- Ask only what's blocking progress
- Combine related questions
- Defer nice-to-have information
2. Challenge Mode, Not Interview Mode
Don't just ask—challenge assumptions:
- Bad: "What scale do you need?"
- Good: "You mentioned 'scalable'—are we designing for 10K users or 10M? That changes the architecture significantly."
3. Provide Example Answers
Help users understand what you're looking for:
- Bad: "What's your timeline?"
- Good: "What's your timeline? For context, a robust MVP typically takes 8-12 weeks with a team of 4."
Question Generation Framework
Step 1: Prioritize Missing Information
Rank by impact on routing and design:
| Priority | Category | Examples |
|---|
| P0 | Blocking | Can't proceed without this (e.g., "What problem does AI solve here?") |
| P1 | High Impact | Significantly changes approach (e.g., "1K or 100K users?") |
| P2 | Medium Impact | Affects details but not direction (e.g., "Budget range?") |
| P3 | Nice to Have | Can be discovered later (e.g., "Preferred cloud provider?") |
Ask P0 first, then P1. Defer P2/P3.
Step 2: Select Question Type
| Type | When to Use | Template |
|---|
| Scope | Vague feature description | "When you say [X], do you mean [A] or [B]?" |
| Scale | Missing numbers | "What scale are we designing for? [X] users? [Y] requests/second?" |
| Timeline | Vague deadlines | "What's the actual deadline? Is there flexibility if scope changes?" |
| Constraint | Unknown limitations | "Are there constraints I should know about? Budget, team size, existing systems?" |
| Success | Unclear goals | "How will we know this succeeded? What metrics matter?" |
Step 3: Frame as Challenge
Transform neutral questions into challenging ones:
| Neutral (Weak) | Challenge (Strong) |
|---|
| "What do you mean by AI-powered?" | "'AI-powered' can mean many things—are you trying to classify data, generate content, or make predictions? What specific problem are you solving?" |
| "What's your budget?" | "Knowing budget helps me avoid over-engineering. Are we optimizing for < $5K/month or is $50K/month acceptable for the right solution?" |
| "How many users?" | "You mentioned 'scale'—I want to avoid designing for problems you don't have. How many users today, and what's realistic in 12 months?" |
Output Format
## Clarification Needed
Before I route this to the appropriate specialist, I need to understand a few things:
### Challenge 1: [Vague Term/Concept]
[Direct challenge statement]
**Question**: [Specific question]
**Why this matters**: [Impact on design/routing]
**Example answers**:
- Option A: [example] → leads to [approach]
- Option B: [example] → leads to [different approach]
### Challenge 2: [Missing Context]
[...]
---
Once you clarify these points, I'll route to [suggested agent] with a clear brief.
Question Templates by Category
See question-templates.md for comprehensive templates.
See challenge-patterns.md for examples of turning neutral questions into challenges.
Examples
Example 1: AI Feature Request
User Request: "We want to add AI capabilities to improve customer experience"
Clarification Output:
## Clarification Needed
Before I route this to cto-architect, I need to understand what "AI capabilities" means for your use case:
### Challenge 1: Vague AI Requirement
"AI capabilities" could mean anything from a chatbot to predictive analytics. I don't want to design the wrong solution.
**Question**: What specific customer problem are you trying to solve with AI?
**Why this matters**: A recommendation engine has completely different architecture than a support chatbot.
**Example answers**:
- "Customers can't find products" → Recommendation engine / search improvement
- "Support tickets are overwhelming" → AI-assisted ticket routing or chatbot
- "Churn is high" → Predictive analytics for at-risk customers
### Challenge 2: Missing Scale
**Question**: How many customers are we talking about? And how many interactions per day would this AI feature handle?
**Why this matters**: 1,000 daily interactions vs 1,000,000 changes whether we use a simple API call or need dedicated ML infrastructure.
---
Once you clarify these points, I'll route to cto-architect with a clear brief for the appropriate AI architecture.
Example 2: Scaling Concerns
User Request: "Our app needs to scale better"
Clarification Output:
## Clarification Needed
"Scale better" is a symptom—I need to understand the disease before prescribing treatment.
### Challenge 1: What's Actually Broken?
**Question**: What specific scaling issue are you experiencing? Slow page loads? Database timeouts? High infrastructure costs? All of the above?
**Why this matters**: Scaling a slow database is different from scaling a CPU-bound API.
**Example answers**:
- "Page loads take 5+ seconds at peak" → Likely caching/CDN solution
- "Database queries timing out" → Database scaling or query optimization
- "AWS bill doubled last month" → Cost optimization vs actual scaling
### Challenge 2: Current vs Target Scale
**Question**: What's your current traffic, and what do you need to support? Be specific: requests per second, concurrent users, data volume.
**Why this matters**: "Scale" at 10K users looks very different from "scale" at 10M users. I don't want to over-engineer.
---
Once I understand the specific bottleneck, I'll route to the appropriate specialist.
Anti-Patterns to Avoid
1. The Interrogation
Bad: Asking 10 questions at once
Good: Max 2-3 targeted questions
2. The Open-Ended Trap
Bad: "Tell me more about your requirements"
Good: "Is this for internal users (hundreds) or external customers (thousands+)?"
3. The Assumption Question
Bad: "What microservices architecture do you want?" (assumes microservices)
Good: "What's your current architecture, and what's driving the need to change?"
4. The Jargon Barrier
Bad: "What's your CAP theorem preference for the distributed system?"
Good: "If the system goes offline briefly, should it prioritize consistency (everyone sees the same data) or availability (the system stays up)?"
References
