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)