用途：当目标模糊、欠明确或存在多种解释时，在规划（omh-ralplan）或实现前，通过对话澄清需求。用户可说“deep interview”“requirements”“what should we build”等触发。若目标已清晰、已有确认规格、用户明确跳过或任务为简单单文件改动，则不应使用。
主要能力：按阶段运行。Phase 0 检查已有状态，列出活跃访谈实例，可恢复、重开或放弃；同时检查 .omh/research/*-report.md 中 status: confirmed 的研究报告，由用户决定是否纳入。Phase 1 开场，询问项目描述与绿地/棕地，生成访谈 ID（如 di-20260407-x7k），创建状态文件。Phase 2 最多 5 轮（可扩展至 10），每轮选择一个维度提问，绿地权重为 Goal 0.40 > Constraints 0.30 = Success Criteria 0.30，棕地增加 Existing Context 0.15；每轮只问一个具体问题，可追问 1-2 次，更新覆盖度并展示。Phase 3 生成规格，写入 .omh/specs/{project-name}-spec.md，frontmatter 含 status: draft、coverage、rounds_completed。Phase 4 用户确认后改为 status: confirmed，下游技能仅认 confirmed 规格。Phase 5 记录结构化事件到 .omh/logs/interview-{id}.log。
使用方式：需要与用户对话并写入 .omh/ 目录。状态通过 omh_state 管理，如 omh_state(action="list_instances", mode="interview")、omh_state(action="read", mode="interview", instance_id="{id}")、omh_state(action="write", mode="interview", instance_id="{id}", data={...})。若 omh_state 不可用，可手动 glob .omh/state/interview--*.json。
适用场景：非平凡工作前的需求澄清、目标有多种解释、omh-ralplan 判定目标过于模糊、用户不确定想要什么。若涉及不熟悉领域，建议先运行 omh-deep-research 再继续访谈。
限制：用户始终控制退出，不因覆盖度分数自动终止；状态只存每轮约 200 字摘要，不存完整对话，恢复时会有信息损失；棕地与否由用户告知而非自动检测；同一项目同一时间只应有一个活跃访谈；草稿规格不能作为下游输入，必须用户明确确认。