deep-interview

name	deep-interview
description	Ambiguity gating — detects vague feature requests and forces structured requirements gathering with scoring across scope, platform, performance, integration, and acceptance criteria. Prevents wasted cycles on underspecified tasks.
alwaysApply	true

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.

Interview Protocol

When the score is below threshold:

1. Present the current scores — show the user which dimensions are weak
2. Ask targeted questions — max 3 questions per round, focused on the lowest-scoring dimensions
3. Re-score after each round — update scores based on answers
4. Proceed when threshold is met — or when the user explicitly opts out

Question style: be direct and specific, not generic. Instead of "What platform?", ask "Is this for mobile (touch input, limited GPU) or desktop (keyboard/mouse, full GPU budget)?"

Output: Requirements Document

When the threshold is met, produce a structured summary:

## Requirements Summary

**Feature:** [one-line description]

**Scope:** [what's included and what's explicitly excluded]
**Platform:** [target platform, input method, render pipeline]
**Performance:** [constraints, budgets, target devices]
**Integration:** [systems touched, dependencies, data flow]
**Acceptance Criteria:**
- [criterion 1]
- [criterion 2]
- [criterion 3]

Ask the user to confirm the summary before proceeding to implementation.

Scoring Examples

Vague (score 3/10): "Add multiplayer to my game"

• Scope: 1 (multiplayer is broad — co-op? competitive? matchmaking?)
• Platform: 0 (unspecified)
• Performance: 0 (unspecified)
• Integration: 1 (implies networking but no specifics)
• Acceptance: 1 (implied: "it works")

Clear enough (score 7/10): "Add 2-player local co-op split-screen for the existing PlayerController using the new Input System"

• Scope: 2 (2-player local co-op split-screen)
• Platform: 1 (implies desktop from split-screen, but not explicit)
• Performance: 1 (split-screen implies rendering budget concern)
• Integration: 2 (PlayerController, Input System explicitly named)
• Acceptance: 1 (implied: both players can play simultaneously)