---
name: deep-interview
description: 在自主执行前进行带有数学化歧义门控的苏格拉底式深度访谈
argument-hint: "[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"
pipeline: [deep-interview, omc-plan, autopilot]
next-skill: omc-plan
next-skill-args: --consensus --direct
handoff: .omc/specs/deep-interview-{slug}.md
level: 3
---

<Purpose>
Deep Interview 实现了受 Ouroboros 启发的苏格拉底式提问，并带有数学化歧义评分。它通过提出能暴露隐藏假设的定向问题、在加权维度上衡量清晰度，并在歧义降到可配置阈值以下之前拒绝继续推进（默认：20%），将模糊想法替换为极其清晰的规格说明。其输出会进入一个 3 阶段流水线：**deep-interview → ralplan（共识细化）→ autopilot（执行）**，确保每个阶段都有最高程度的清晰度。
</Purpose>

<Use_When>
- 用户只有一个模糊的想法，并且希望在执行前进行充分的需求收集
- 用户说了 "deep interview"、"interview me"、"ask me everything"、"don't assume"、"make sure you understand"
- 用户说了 "ouroboros"、"socratic"、"I have a vague idea"、"not sure exactly what I want"
- 用户希望避免自主执行后出现“这不是我本来的意思”的结果
- 任务复杂到如果直接开始写代码，会把大量精力浪费在范围探索上
- 用户希望在承诺执行之前，先获得经过数学化验证的清晰度
</Use_When>

<Do_Not_Use_When>
- 用户已经给出详细且具体的请求，包含文件路径、函数名或验收标准，此时应直接执行
- 用户想探索选项或头脑风暴，此时改用 `omc-plan` skill
- 用户只想要一个快速修复或单一改动，此时委派给 executor 或 ralph
- 用户说 "just do it" 或 "skip the questions"，应尊重其意图
- 用户已经有 PRD 或计划文件，此时使用 ralph 或 autopilot 配合该计划
</Do_Not_Use_When>

<Why_This_Exists>
AI 可以构建任何东西。难点在于知道应该构建什么。OMC 的 autopilot Phase 0 会通过 analyst + architect 将想法扩展成规格，但这种单次扩展方式在面对真正模糊的输入时效果不佳。它会问“你想要什么？”，而不是“你默认了什么假设？”。Deep Interview 应用苏格拉底式方法，迭代暴露这些假设，并通过数学化门控判断是否准备就绪，确保 AI 在花费执行周期之前已经获得真正的清晰理解。

它受到 [Ouroboros project](https://github.com/Q00/ouroboros) 的启发，该项目证明了：在 AI 辅助开发中，规格质量是首要瓶颈。
</Why_This_Exists>

<Execution_Policy>
- 每次只问 ONE 个问题，绝不要把多个问题打包在一起
- 每个问题都要瞄准当前最 WEAKEST 的清晰度维度
- 每一轮都要明确说明为何瞄准最弱维度：指出最弱维度、说明它的分数/缺口，并解释为什么下一个问题要围绕它展开
- 在向用户提问代码库事实之前，先通过 `explore` agent 收集代码库事实
- 对于 brownfield 确认类问题，引用触发该问题的仓库证据（文件路径、符号或模式），而不是要求用户自己重新发现
- 每次收到回答后都要重新评分歧义程度，并透明展示分数
- 在歧义 ≤ 阈值（默认 0.2）之前，不得进入执行
- 如果歧义仍然很高，可以允许提前退出，但必须给出明确警告
- 持久化访谈状态，以便在会话中断后恢复
- 在特定轮次阈值激活 challenge agents，以切换提问视角
</Execution_Policy>

<Autoresearch_Mode>
当参数包含 `--autoresearch` 时，Deep Interview 会成为 `omc autoresearch` 的零学习成本启动通道。

- 如果还没有可用的 mission brief，先从这个问题开始：**"What should autoresearch improve or prove for this repo?"**
- 当 mission 明确后，收集 evaluator command。如果用户留空，仅在仓库证据非常充分时才可推断；否则继续访谈，直到 evaluator 足够明确、可以安全启动
- 保持“每轮只问一个问题”的常规规则，但除了普通的歧义阈值外，还要把 **mission clarity** 和 **evaluator clarity** 视为硬性就绪门槛
- 一旦准备就绪，**不要** 桥接到 `omc-plan`、`autopilot`、`ralph` 或 `team`。而是直接运行：
  - `omc autoresearch --mission "<mission>" --eval "<evaluator>" [--keep-policy <policy>] [--slug <slug>]`
- 这种直接交接预期会脱离当前流程并进入真正的 autoresearch runtime tmux session。成功交接后，宣布已启动的 session，并结束当前访谈通道
</Autoresearch_Mode>

<Steps>

## Phase 1: 初始化

1. 从 `{{ARGUMENTS}}` 中**解析用户的想法**
2. **检测 brownfield 还是 greenfield**：
   - 运行 `explore` agent（haiku）：检查 cwd 是否有现有源码、package 文件或 git 历史
   - 如果存在源码文件，且用户的想法是要修改/扩展某些已有内容：判定为 **brownfield**
   - 否则：判定为 **greenfield**
3. **对于 brownfield**：运行 `explore` agent 映射相关代码库区域，并存为 `codebase_context`
4. 通过 `state_write(mode="deep-interview")` **初始化状态**：

```json
{
  "active": true,
  "current_phase": "deep-interview",
  "state": {
    "interview_id": "<uuid>",
    "type": "greenfield|brownfield",
    "initial_idea": "<user input>",
    "rounds": [],
    "current_ambiguity": 1.0,
    "threshold": 0.2,
    "codebase_context": null,
    "challenge_modes_used": [],
    "ontology_snapshots": []
  }
}
```

5. 向用户**宣布开始访谈**：

> 开始深度访谈。我会通过定向提问，在真正开始构建之前彻底理解你的想法。每次你回答后，我都会展示清晰度分数。当歧义降到 20% 以下时，我们就进入执行阶段。
>
> **你的想法：** "{initial_idea}"
> **项目类型：** {greenfield|brownfield}
> **当前歧义：** 100%（我们还没有开始）

## Phase 2: 访谈循环

重复以下流程，直到 `ambiguity ≤ threshold`，或者用户提前退出：

### Step 2a: 生成下一个问题

构建问题生成提示词时要包含：
- 用户的原始想法
- 之前所有的问答轮次（对话历史）
- 当前各维度的清晰度分数（哪个最弱？）
- Challenge agent mode（如果已激活，见 Phase 3）
- Brownfield 的代码库上下文（如适用）

**问题瞄准策略：**
- 识别清晰度分数最低的维度
- 生成一个专门提升该维度的问题
- 在问题之前用一句话说明：为什么这个维度当前是降低歧义的瓶颈
- 问题应暴露 ASSUMPTIONS，而不是收集功能清单
- 如果范围在概念层面仍然模糊（实体不断变化、用户描述的是症状、或核心名词不稳定），切换为 ontology 风格问题，先询问这个事物本质上究竟是什么，再回到功能/细节问题

**各维度对应的问题风格：**
| Dimension | Question Style | Example |
|-----------|---------------|---------|
| Goal Clarity | “具体会发生什么？” | “当你说 'manage tasks' 时，用户首先会执行什么具体操作？” |
| Constraint Clarity | “边界是什么？” | “这需要离线可用吗，还是默认有网络连接？” |
| Success Criteria | “我们怎么知道它成功了？” | “如果我把成品展示给你，什么会让你说‘对，就是这个’？” |
| Context Clarity (brownfield) | “它如何融入现有系统？” | “我在 `src/auth/` 中发现了 JWT auth middleware（模式：passport + JWT）。这个功能应该沿着这条路径扩展，还是有意偏离它？” |
| Scope-fuzzy / ontology stress | “这里的核心事物到底是什么？” | “在前几轮里你提到了 Tasks、Projects 和 Workspaces。哪个才是核心实体，哪些只是辅助视图或容器？” |

### Step 2b: 提出问题

使用 `AskUserQuestion` 提出生成的问题。结合当前歧义上下文，清晰地展示：

```
Round {n} | Targeting: {weakest_dimension} | Why now: {one_sentence_targeting_rationale} | Ambiguity: {score}%

{question}
```

选项应包含与上下文相关的候选答案，以及自由输入。

### Step 2c: 对歧义评分

收到用户回答后，对所有维度的清晰度进行评分。

**评分提示词**（使用 opus model，temperature 0.1 以保证一致性）：

```
Given the following interview transcript for a {greenfield|brownfield} project, score clarity on each dimension from 0.0 to 1.0:

Original idea: {idea}

Transcript:
{all rounds Q&A}

Score each dimension:
1. Goal Clarity (0.0-1.0): Is the primary objective unambiguous? Can you state it in one sentence without qualifiers? Can you name the key entities (nouns) and their relationships (verbs) without ambiguity?
2. Constraint Clarity (0.0-1.0): Are the boundaries, limitations, and non-goals clear?
3. Success Criteria Clarity (0.0-1.0): Could you write a test that verifies success? Are acceptance criteria concrete?
{4. Context Clarity (0.0-1.0): [brownfield only] Do we understand the existing system well enough to modify it safely? Do the identified entities map cleanly to existing codebase structures?}

For each dimension provide:
- score: float (0.0-1.0)
- justification: one sentence explaining the score
- gap: what's still unclear (if score < 0.9)

Also identify:
- weakest_dimension: the single lowest-confidence dimension this round
- weakest_dimension_rationale: one sentence explaining why it is the highest-leverage target for the next question

5. Ontology Extraction: Identify all key entities (nouns) discussed in the transcript.

{If round > 1, inject: "Previous round's entities: {prior_entities_json from state.ontology_snapshots[-1]}. REUSE these entity names where the concept is the same. Only introduce new names for genuinely new concepts."}

For each entity provide:
- name: string (the entity name, e.g., "User", "Order", "PaymentMethod")
- type: string (e.g., "core domain", "supporting", "external system")
- fields: string[] (key attributes mentioned)
- relationships: string[] (e.g., "User has many Orders")

Respond as JSON. Include an additional "ontology" key containing the entities array alongside the dimension scores.
```

**计算歧义：**

Greenfield：`ambiguity = 1 - (goal × 0.40 + constraints × 0.30 + criteria × 0.30)`
Brownfield：`ambiguity = 1 - (goal × 0.35 + constraints × 0.25 + criteria × 0.25 + context × 0.15)`

**计算 ontology 稳定性：**

**第 1 轮特殊情况：** 第一轮跳过稳定性比较。所有实体都视为“新实体”。将 stability_ratio 设为 N/A。如果某一轮产生了零个实体，也将 stability_ratio 设为 N/A（避免除以零）。

对于第 2 轮及之后的轮次，与前一轮的实体列表比较：
- `stable_entities`：两轮中都存在且名称相同的实体
- `changed_entities`：名称不同，但 `type` 相同且字段重叠超过 50% 的实体（视为重命名，而不是新增+删除）
- `new_entities`：本轮中未按名称或模糊匹配到任何前一轮实体的新实体
- `removed_entities`：前一轮中未匹配到当前任何实体的实体
- `stability_ratio`：`(stable + changed) / total_entities`（范围 0.0 到 1.0，其中 1.0 = 完全收敛）

这个公式会将重命名实体（changed）计入稳定性。重命名表示概念仍然存在，即使名称变化了，这代表收敛而不是不稳定。两个名称不同，但 `type` 相同且字段重叠超过 50% 的实体，应归类为 "changed"（重命名），而不是一个删除一个新增。

**展示你的推导过程：** 在报告稳定性数字之前，简要列出哪些实体被匹配了（按名称或模糊匹配），哪些是新增/删除。这样用户可以检查匹配是否合理。

将 ontology 快照（entities + stability_ratio + matching_reasoning）存入 `state.ontology_snapshots[]`。

### Step 2d: 报告进展

评分后，向用户展示其进展：

```
Round {n} complete.

| Dimension | Score | Weight | Weighted | Gap |
|-----------|-------|--------|----------|-----|
| Goal | {s} | {w} | {s*w} | {gap or "Clear"} |
| Constraints | {s} | {w} | {s*w} | {gap or "Clear"} |
| Success Criteria | {s} | {w} | {s*w} | {gap or "Clear"} |
| Context (brownfield) | {s} | {w} | {s*w} | {gap or "Clear"} |
| **Ambiguity** | | | **{score}%** | |

**Ontology:** {entity_count} entities | Stability: {stability_ratio} | New: {new} | Changed: {changed} | Stable: {stable}

**Next target:** {weakest_dimension} — {weakest_dimension_rationale}

{score <= threshold ? "达到清晰度阈值！可以继续进入执行。" : "下一轮将聚焦于：{weakest_dimension}"}
```

### Step 2e: 更新状态

通过 `state_write` 用新的一轮和评分结果更新访谈状态。

### Step 2f: 检查软限制

- **第 3 轮及之后**：如果用户说 "enough"、"let's go"、"build it"，允许提前退出
- **第 10 轮**：显示软警告："We're at 10 rounds. Current ambiguity: {score}%. Continue or proceed with current clarity?"
- **第 20 轮**：硬上限："Maximum interview rounds reached. Proceeding with current clarity level ({score}%)."

## Phase 3: Challenge Agents

在特定轮次阈值上，切换提问视角：

### 第 4 轮及之后：Contrarian Mode
向问题生成提示词中注入：
> You are now in CONTRARIAN mode. Your next question should challenge the user's core assumption. Ask "What if the opposite were true?" or "What if this constraint doesn't actually exist?" The goal is to test whether the user's framing is correct or just habitual.

### 第 6 轮及之后：Simplifier Mode
向问题生成提示词中注入：
> You are now in SIMPLIFIER mode. Your next question should probe whether complexity can be removed. Ask "What's the simplest version that would still be valuable?" or "Which of these constraints are actually necessary vs. assumed?" The goal is to find the minimal viable specification.

### 第 8 轮及之后：Ontologist Mode（如果歧义仍然 > 0.3）
向问题生成提示词中注入：
> You are now in ONTOLOGIST mode. The ambiguity is still high after 8 rounds, suggesting we may be addressing symptoms rather than the core problem. The tracked entities so far are: {current_entities_summary from latest ontology snapshot}. Ask "What IS this, really?" or "Looking at these entities, which one is the CORE concept and which are just supporting?" The goal is to find the essence by examining the ontology.

每种 challenge mode 只使用 ONCE 一次，之后恢复正常的苏格拉底式提问。要在状态中记录哪些 mode 已经被使用。

## Phase 4: 固化规格

当歧义 ≤ 阈值（或达到硬上限 / 提前退出）时：

1. 使用 opus model 和完整访谈记录**生成规格说明**
2. **写入文件**：`.omc/specs/deep-interview-{slug}.md`

规格结构：

```markdown
# Deep Interview Spec: {title}

## Metadata
- Interview ID: {uuid}
- Rounds: {count}
- Final Ambiguity Score: {score}%
- Type: greenfield | brownfield
- Generated: {timestamp}
- Threshold: {threshold}
- Status: {PASSED | BELOW_THRESHOLD_EARLY_EXIT}

## Clarity Breakdown
| Dimension | Score | Weight | Weighted |
|-----------|-------|--------|----------|
| Goal Clarity | {s} | {w} | {s*w} |
| Constraint Clarity | {s} | {w} | {s*w} |
| Success Criteria | {s} | {w} | {s*w} |
| Context Clarity | {s} | {w} | {s*w} |
| **Total Clarity** | | | **{total}** |
| **Ambiguity** | | | **{1-total}** |

## Goal
{从访谈中提炼出的极其清晰的目标陈述}

## Constraints
- {constraint 1}
- {constraint 2}
- ...

## Non-Goals
- {明确排除的范围 1}
- {明确排除的范围 2}

## Acceptance Criteria
- [ ] {可测试的标准 1}
- [ ] {可测试的标准 2}
- [ ] {可测试的标准 3}
- ...

## Assumptions Exposed & Resolved
| Assumption | Challenge | Resolution |
|------------|-----------|------------|
| {assumption} | {如何被质疑} | {最终决定} |

## Technical Context
{brownfield: 来自 explore agent 的相关代码库发现}
{greenfield: 技术选型与约束}

## Ontology (Key Entities)
{从 FINAL round 的 ontology extraction 填充，而不是只用 crystallization 时临时生成的结果}

| Entity | Type | Fields | Relationships |
|--------|------|--------|---------------|
| {entity.name} | {entity.type} | {entity.fields} | {entity.relationships} |

## Ontology Convergence
{使用 state 中 ontology_snapshots 的数据展示实体如何在访谈轮次中逐步稳定}

| Round | Entity Count | New | Changed | Stable | Stability Ratio |
|-------|-------------|-----|---------|--------|----------------|
| 1 | {n} | {n} | - | - | - |
| 2 | {n} | {new} | {changed} | {stable} | {ratio}% |
| ... | ... | ... | ... | ... | ... |
| {final} | {n} | {new} | {changed} | {stable} | {ratio}% |

## Interview Transcript
<details>
<summary>Full Q&A ({n} rounds)</summary>

### Round 1
**Q:** {question}
**A:** {answer}
**Ambiguity:** {score}% (Goal: {g}, Constraints: {c}, Criteria: {cr})

...
</details>
```

## Phase 5: 执行桥接

**Autoresearch override：** 如果启用了 `--autoresearch`，则跳过下方标准执行选项。唯一有效的桥接方式，是前文所述直接交接到 `omc autoresearch --mission ... --eval ...`。

规格写入后，通过 `AskUserQuestion` 提供执行选项：

**Question:** "Your spec is ready (ambiguity: {score}%). How would you like to proceed?"

**Options:**

1. **Ralplan → Autopilot（推荐）**
   - Description: "3-stage pipeline: consensus-refine this spec with Planner/Architect/Critic, then execute with full autopilot. Maximum quality."
   - Action: 以规格文件路径作为上下文，调用带 `--consensus --direct` 标志的 `Skill("oh-my-claudecode:omc-plan")`。`--direct` 标志会跳过 omc-plan skill 的访谈阶段（因为 deep interview 已经收集好需求），而 `--consensus` 会触发 Planner/Architect/Critic 循环。当达成共识并在 `.omc/plans/` 中产出计划后，再将该共识计划作为 Phase 0+1 输出，调用 `Skill("oh-my-claudecode:autopilot")`。这样 autopilot 会跳过 Expansion 和 Planning，直接从 Phase 2（Execution）开始。
   - Pipeline: `deep-interview spec → omc-plan --consensus --direct → autopilot execution`

2. **使用 autopilot 执行（跳过 ralplan）**
   - Description: "Full autonomous pipeline — planning, parallel implementation, QA, validation. Faster but without consensus refinement."
   - Action: 以规格文件路径作为上下文调用 `Skill("oh-my-claudecode:autopilot")`。该规格会替代 autopilot 的 Phase 0，因此 autopilot 从 Phase 1（Planning）开始。

3. **使用 ralph 执行**
   - Description: "Persistence loop with architect verification — keeps working until all acceptance criteria pass"
   - Action: 将规格文件路径作为任务定义，调用 `Skill("oh-my-claudecode:ralph")`。

4. **使用 team 执行**
   - Description: "N coordinated parallel agents — fastest execution for large specs"
   - Action: 将规格文件路径作为共享计划，调用 `Skill("oh-my-claudecode:team")`。

5. **继续细化**
   - Description: "Continue interviewing to improve clarity (current: {score}%)"
   - Action: 返回到 Phase 2 访谈循环。

**IMPORTANT:** 当用户选择执行方式后，**必须** 通过 `Skill()` 调用所选 skill。不要直接实现。deep-interview agent 是需求澄清 agent，不是执行 agent。

### 3 阶段流水线（推荐路径）

```
Stage 1: Deep Interview          Stage 2: Ralplan                Stage 3: Autopilot
┌─────────────────────┐    ┌───────────────────────────┐    ┌──────────────────────┐
│ Socratic Q&A        │    │ Planner creates plan      │    │ Phase 2: Execution   │
│ Ambiguity scoring   │───>│ Architect reviews         │───>│ Phase 3: QA cycling  │
│ Challenge agents    │    │ Critic validates          │    │ Phase 4: Validation  │
│ Spec crystallization│    │ Loop until consensus      │    │ Phase 5: Cleanup     │
│ Gate: ≤20% ambiguity│    │ ADR + RALPLAN-DR summary  │    │                      │
└─────────────────────┘    └───────────────────────────┘    └──────────────────────┘
Output: spec.md            Output: consensus-plan.md        Output: working code
```

**为什么是 3 个阶段？** 每个阶段都提供不同的质量门：
1. **Deep Interview** 以*清晰度*为门控：用户是否清楚自己想要什么？
2. **Ralplan** 以*可行性*为门控：方案在架构上是否可靠？
3. **Autopilot** 以*正确性*为门控：代码是否工作且通过评审？

可以跳过任一阶段，但会降低质量保证：
- 跳过 Stage 1 → autopilot 可能会构建错误的东西（需求模糊）
- 跳过 Stage 2 → autopilot 可能制定出糟糕的计划（没有 Architect/Critic 的挑战）
- 跳过 Stage 3 → 没有执行结果（只有一份细化后的计划）

</Steps>

<Tool_Usage>
- 对每一个访谈问题使用 `AskUserQuestion`，它会提供带上下文选项的可点击 UI
- 对 brownfield 代码库探索使用 `Task(subagent_type="oh-my-claudecode:explore", model="haiku")`（必须先运行，再问用户代码库相关问题）
- 对歧义评分使用 opus model（temperature 0.1），一致性非常关键
- 使用 `state_write` / `state_read` 持久化访谈状态
- 使用 `Write` 工具将最终规格保存到 `.omc/specs/`
- 使用 `Skill()` 桥接到执行模式，绝不要直接实现
- Challenge agent modes 是提示词注入，不是单独生成新的 agent
</Tool_Usage>

<Examples>
<Good>
瞄准最弱维度：
```
Scores: Goal=0.9, Constraints=0.4, Criteria=0.7
Next question targets Constraints (lowest at 0.4):
"You mentioned this should 'work on mobile'. Does that mean a native app,
a responsive web app, or a PWA? And are there specific devices or OS versions
you need to support?"
```
Why good: 识别了最弱维度，解释了它为何是当前瓶颈，提出了一个针对性的具体问题来改进它，而且没有把多个话题打包在一起。
</Good>

<Good>
先收集代码库事实再提问：
```
[spawns explore agent: "find authentication implementation"]
[receives: "Auth is in src/auth/ using JWT with passport.js"]

Question: "I found JWT authentication with passport.js in `src/auth/` (pattern match from explore).
For this new feature, should we extend the existing auth middleware or create
a separate authentication flow?"
```
Why good: 先探索，再引用触发问题的仓库证据，然后提出有根据的确认问题。绝不会问用户代码已经明确告诉你的内容。
</Good>

<Good>
Contrarian mode 激活：
```
Round 5 | Contrarian Mode | Ambiguity: 42%

You've said this needs to support 10,000 concurrent users. What if it only
needed to handle 100? Would the architecture change fundamentally, or is
the 10K number an assumption rather than a measured requirement?
```
Why good: 质疑了一个具体假设（规模需求），而这个假设可能极大简化解决方案。
</Good>

<Good>
带警告的提前退出：
```
User: "That's enough, just build it"
System: "Current ambiguity is 35% (threshold: 20%). Areas still unclear:
  - Success Criteria: 0.5 (How do we verify the search ranking algorithm works correctly?)
  - Constraints: 0.6 (No performance targets defined yet)

Proceeding may require rework. Continue anyway?"
  [Yes, proceed] [Ask 2-3 more questions] [Cancel]
```
Why good: 尊重用户想停止的意愿，但透明地展示风险。
</Good>

<Good>
追踪 ontology 收敛：
```
Round 3 entities: User, Task, Project (stability: N/A → 67%)
Round 4 entities: User, Task, Project, Tag (stability: 75% — 3 stable, 1 new)
Round 5 entities: User, Task, Project, Tag (stability: 100% — all 4 stable)

"Ontology has converged — the same 4 entities appeared in 2 consecutive rounds
with no changes. The domain model is stable."
```
Why good: 展示了实体在多轮中的跟踪和可见的收敛过程。随着领域模型逐渐稳定，stability ratio 会提高，从数学上证明访谈正在收敛到稳定理解。
</Good>

<Good>
适用于范围模糊任务的 ontology 风格问题：
```
Round 6 | Targeting: Goal Clarity | Why now: the core entity is still unstable across rounds, so feature questions would compound ambiguity | Ambiguity: 38%

"Across the last rounds you've described this as a workflow, an inbox, and a planner. Which one is the core thing this product IS, and which ones are supporting metaphors or views?"
```
Why good: 使用 ontology 风格提问先稳定核心名词，再深入到功能细节；当范围是模糊而不仅仅是不完整时，这是正确做法。
</Good>

<Bad>
把多个问题打包在一起：
```
"What's the target audience? And what tech stack? And how should auth work?
Also, what's the deployment target?"
```
Why bad: 一次问了四个问题，会导致回答浅表，也会让评分不准确。
</Bad>

<Bad>
询问代码库中已经存在的事实：
```
"What database does your project use?"
```
Why bad: 本应先生成 explore agent 去查找这个答案。绝不要询问用户代码已经告诉你的内容。
</Bad>

<Bad>
在高歧义下仍然推进：
```
"Ambiguity is at 45% but we've done 5 rounds, so let's start building."
```
Why bad: 45% 的歧义意味着近一半需求仍然不清楚。数学门控机制的存在，正是为了防止这种情况。
</Bad>
</Examples>

<Escalation_And_Stop_Conditions>
- **20 轮硬上限**：带着当前已有的清晰度继续推进，并注明风险
- **10 轮软警告**：让用户选择继续还是直接推进
- **提前退出（第 3 轮及之后）**：如果歧义 > threshold，可以在警告后允许退出
- **用户说 "stop"、"cancel"、"abort"**：立即停止，并保存状态以便恢复
- **歧义停滞**（3 轮内分数变化在 +-0.05 以内）：激活 Ontologist mode 重新框定问题
- **所有维度都达到 0.9+**：即使未达到最小轮次，也可直接进入规格生成
- **代码库探索失败**：按 greenfield 继续，并注明这一限制
</Escalation_And_Stop_Conditions>

<Final_Checklist>
- [ ] 访谈已完成（歧义 ≤ threshold，或用户选择提前退出）
- [ ] 每一轮后都显示了歧义分数
- [ ] 每一轮都明确指出最弱维度，以及它为什么是下一个目标
- [ ] 在正确阈值激活了 challenge agents（第 4、6、8 轮）
- [ ] 已将规格文件写入 `.omc/specs/deep-interview-{slug}.md`
- [ ] 规格中包含：goal、constraints、acceptance criteria、clarity breakdown、transcript
- [ ] 已通过 AskUserQuestion 展示执行桥接选项
- [ ] 所选执行模式通过 Skill() 调用（绝不能直接实现）
- [ ] 如果选择 3 阶段流水线：已调用 omc-plan --consensus --direct，然后再用共识计划调用 autopilot
- [ ] 执行交接后已清理状态
- [ ] 在向用户提问之前，brownfield 确认类问题会先引用仓库证据（file/path/pattern）
- [ ] 对范围模糊的任务，可以触发 ontology 风格提问，以在展开功能细节前稳定核心实体
- [ ] 每轮歧义报告都包含 Ontology 行，其中有实体数量和 stability ratio
- [ ] 规格中包含 Ontology（Key Entities）表和 Ontology Convergence 章节
</Final_Checklist>

<Advanced>
## Configuration

`.claude/settings.json` 中的可选设置：

```json
{
  "omc": {
    "deepInterview": {
      "ambiguityThreshold": 0.2,
      "maxRounds": 20,
      "softWarningRounds": 10,
      "minRoundsBeforeExit": 3,
      "enableChallengeAgents": true,
      "autoExecuteOnComplete": false,
      "defaultExecutionMode": "autopilot",
      "scoringModel": "opus"
    }
  }
}
```

## Resume

如果被中断，再次运行 `/deep-interview`。该 skill 会从 `.omc/state/deep-interview-state.json` 读取状态，并从上一次完成的轮次继续。

## 与 Autopilot 的集成

当 autopilot 收到模糊输入（没有文件路径、函数名或具体锚点）时，它可以重定向到 deep-interview：

```
User: "autopilot build me a thing"
Autopilot: "Your request is quite open-ended. Would you like to run a deep interview first to clarify requirements?"
  [Yes, interview first] [No, expand directly]
```

如果用户选择访谈，autopilot 会调用 `/deep-interview`。当访谈完成，且用户选择 "Execute with autopilot" 时，该规格会成为 Phase 0 输出，而 autopilot 从 Phase 1（Planning）继续。

## 3 阶段流水线：deep-interview → ralplan → autopilot

推荐的执行路径会串联三个质量门：

```
/deep-interview "vague idea"
  → Socratic Q&A until ambiguity ≤ 20%
  → Spec written to .omc/specs/deep-interview-{slug}.md
  → User selects "Ralplan → Autopilot"
  → /omc-plan --consensus --direct (spec as input, skip interview)
    → Planner creates implementation plan from spec
    → Architect reviews for architectural soundness
    → Critic validates quality and testability
    → Loop until consensus (max 5 iterations)
    → Consensus plan written to .omc/plans/
  → /autopilot (plan as input, skip Phase 0+1)
    → Phase 2: Parallel execution via Ralph + Ultrawork
    → Phase 3: QA cycling until tests pass
    → Phase 4: Multi-perspective validation
    → Phase 5: Cleanup
```

**omc-plan skill 接收该规格时会带 `--consensus --direct` 标志**，因为 deep interview 已经完成了需求收集。`--direct` 标志（由 omc-plan skill 支持，ralplan 是它的别名）会跳过访谈阶段，直接进入 Planner → Architect → Critic 的共识流程。共识计划包含：
- RALPLAN-DR 摘要（Principles、Decision Drivers、Options）
- ADR（Decision、Drivers、Alternatives、Why chosen、Consequences）
- 可测试的验收标准（继承自 deep-interview spec）
- 带文件引用的实现步骤

**Autopilot 接收 ralplan 生成的共识计划**，并跳过 Phase 0（Expansion）和 Phase 1（Planning），因为 ralplan 已经产出了一份经过 Critic 审核的计划。Autopilot 直接从 Phase 2（Execution）开始。

## 与 Ralplan Gate 的集成

ralplan 的执行前门控已经会把模糊提示词重定向到规划流程。对于那些甚至模糊到 ralplan 也难以处理的提示词，deep interview 可以作为一个替代性的重定向目标：

```
Vague prompt → ralplan gate → deep-interview (if extremely vague) → ralplan (with clear spec) → autopilot
```

## Brownfield vs Greenfield 权重

| Dimension | Greenfield | Brownfield |
|-----------|-----------|------------|
| Goal Clarity | 40% | 35% |
| Constraint Clarity | 30% | 25% |
| Success Criteria | 30% | 25% |
| Context Clarity | N/A | 15% |

Brownfield 会增加 Context Clarity，因为要安全修改现有代码，必须理解被修改的系统。

## Challenge Agent Modes

| Mode | Activates | Purpose | Prompt Injection |
|------|-----------|---------|-----------------|
| Contrarian | Round 4+ | 质疑假设 | "What if the opposite were true?" |
| Simplifier | Round 6+ | 移除复杂性 | "What's the simplest version?" |
| Ontologist | Round 8+ (if ambiguity > 0.3) | 找到本质 | "What IS this, really?" |

每种 mode 都只使用一次，之后恢复正常的苏格拉底式提问。模式会在状态中被跟踪，以防重复。

## Ambiguity Score Interpretation

| Score Range | Meaning | Action |
|-------------|---------|--------|
| 0.0 - 0.1 | 极其清晰 | 立即推进 |
| 0.1 - 0.2 | 足够清晰 | 推进（默认阈值） |
| 0.2 - 0.4 | 仍有一些缺口 | 继续访谈 |
| 0.4 - 0.6 | 缺口明显 | 聚焦最弱维度 |
| 0.6 - 0.8 | 非常不清晰 | 可能需要重新框定（Ontologist） |
| 0.8 - 1.0 | 几乎什么都不知道 | 处于早期阶段，继续进行 |
</Advanced>

Task: {{ARGUMENTS}}