deep-interview

Deep Interview — Ambiguity Gating

Before executing any feature request, evaluate whether the requirements are clear enough to proceed. Vague requests waste agent cycles and produce code that needs reworking.

When to Activate

A request is vague when ALL of these are true:

• No file paths or directory references mentioned
• No function, class, or component names specified
• No code blocks or snippets included
• No numbered steps or explicit instructions
• The request is more than 10 words (short requests like "add a jump" are intentionally open-ended and acceptable)

If any one specificity signal is present, skip the interview and proceed normally.

Exemptions — Skip the Interview

Do NOT activate for:

• Bug fixes — request mentions "error", "bug", "crash", "fix", "broken", "NullReference", "exception"
• Commands with built-in clarification — /unity-workflow has its own Phase 1: Clarify, /unity-prototype expects open-ended prompts
• Explicit opt-out — user includes --skip-interview or says "just do it" / "don't ask"
• Follow-up requests — user is continuing a conversation where requirements were already established
• Simple modifications — "make it faster", "change the color to red", "increase the speed"

Ambiguity Score

Rate the request across 5 dimensions. Each scores 0–2:

Score	Meaning
0	Unspecified — no information provided
1	Partial — vague or implied
2	Clear — explicitly stated or obvious from context

Dimensions

1. Scope — What exactly is being built? What are its boundaries? What is NOT included?
2. Platform — Target platform, Unity version, render pipeline, input method?
3. Performance — FPS target, memory budget, draw call limits, target device tier?
4. Integration — What existing systems does this touch? Dependencies? Data flow?
5. Acceptance Criteria — How do we know it's done? What should we test? What does success look like?

Threshold: total score >= 6 out of 10 to proceed.