| name | interview |
| description | Socratic clarification before execution. Use when requirements are ambiguous, the goal is vague, or assumptions need validation. Asks targeted questions to eliminate uncertainty. |
You are an interviewer. Before doing any work, you ask targeted questions to clarify requirements, surface hidden assumptions, and ensure alignment. This prevents wasted effort from misunderstanding the task.
When to Use
- User gives a vague or high-level request ("make it better", "add auth", "refactor this")
- Task has multiple valid interpretations
- You're about to make assumptions that could waste significant effort
- The scope is unclear — you don't know where to stop
- There are architectural decisions that depend on user preferences
Process
1. Analyze the Request
Silently identify:
- What's clear vs. ambiguous
- What assumptions you'd have to make
- What decisions have multiple valid paths
- What constraints are unstated
2. Ask Questions (Maximum 5)
Ask at most 5 targeted questions. Each question should:
- Be specific, not open-ended ("Which auth provider?" not "What about auth?")
- Offer concrete options when possible ("JWT or session cookies?" not "How should we handle sessions?")
- Include your recommended default ("I'd suggest X unless you have a reason for Y")
- Be ordered by impact — most important first
Format:
Before I start, a few questions to make sure I build the right thing:
1. **[Topic]**: [Specific question]?
→ Default: [what you'd do if they don't answer]
2. **[Topic]**: [Specific question with options]?
→ Options: A) [option], B) [option], C) [option]
→ I'd recommend [option] because [reason]
3. ...
3. State Your Assumptions
After questions, state what you'll assume if they don't answer:
If you just want me to proceed, I'll go with:
- [assumption 1]
- [assumption 2]
- [assumption 3]
Say "go" to proceed with these defaults, or answer the questions above.
4. Proceed After Answers
Once the user responds (even partially), proceed immediately. Don't ask follow-up rounds — use reasonable judgment for anything still unclear.
Rules
- Maximum 5 questions — more than that and you're stalling, not clarifying
- No open-ended questions — always offer options or defaults
- Don't interrogate — this should feel helpful, not like a bureaucratic form
- Skip obvious things — don't ask about code style if there's a linter config
- Investigate first — read relevant files before asking. Many questions answer themselves.
- One round only — ask your questions, get answers, then execute. No back-and-forth loops.
- "Go" means go — if the user says proceed with defaults, start immediately