interview

/ouroboros:interview

通过苏格拉底式访谈，将模糊请求转化为 Seed 所需的目标、约束和验收标准。

必需的技能能力

• ask_user：通过当前运行时的 ask_user 能力，向用户提出需要人为判断的问题。
• inspect_code：在提问用户之前，先从确切的本地文件中查找回答仓库内事实性问题所需的信息。
• call_mcp：使用 Ouroboros MCP 工具维护持久化访谈状态并生成 Seed。
• orchestrate_subagents：运行咨询通道和 Seed 就绪验收守护通道。
• run_lateral_review：在里程碑阶段和直接回答综合之前，调用横向思维子 Agent。
• web_research：仅在访谈确实依赖当前外部信息时，获取当前外部事实。
• refine_answer：确认对自由文本回答的结构化解读，再将其转交（精炼关卡）。
• maintain_ledger：在主会话中清晰呈现歧义、关卡和未解决的决策。
• run_closure_gate：即使 MCP 报告 Seed 已就绪，也要运行 Seed 就绪验收守护程序。
• restate_goal：重述目标，并在生成 Seed 之前要求用户明确批准（重述关卡）。

服务端在 required_client_gates 中将最后两个关卡命名为 seed_ready_acceptance_guard 和 restate_goal_approved。

用法

ooo interview [topic]
/ouroboros:interview [topic]

主题是技能参数；如果没有参数，则以用户自己的请求为主题。立即从主题开始；不要再次询问主题，也不要先解释 Ouroboros。如果你的上下文中带有 Ouroboros 更新通知，后台更新检查会在第一个问题之后提醒你一次 ooo update。

加载 MCP 工具（延迟加载架构防护）

Ouroboros 工具可能会延迟加载，而且某一轮加载的架构可能在下一轮卸载。每次调用 ouroboros_* 之前，都要立即使用当前运行时的工具发现能力加载对应工具：调用 ouroboros_interview 时使用 "+ouroboros interview"；调用 ouroboros_lateral_think 时使用 "+ouroboros lateral"。如果工具的架构尚未加载，调用会因 "Invalid tool parameters" 而失败。如果工具已经可以调用，发现操作不会有任何作用，预期返回空结果。仅在工具确实不存在时使用备用方案。

如果 ouroboros_interview 可以调用，请使用路径 A。仅在该工具确实不存在（没有 Ouroboros MCP 服务）时使用路径 B。

路径 A：MCP 模式

MCP 负责生成问题、维护状态并评估歧义；它无法读取代码、浏览网页或调用工具。你（主会话）要回答那些可通过代码或研究得出答案的问题，并且只将需要人为判断的事项交给用户：目标、验收标准、业务逻辑和偏好。你绝不替用户做决定；自动确认仅适用于事实。

1. 开始访谈。

   Tool: ouroboros_interview
   Arguments:
     initial_context: <user's topic or idea>
     cwd: <current working directory>
     confused_terms: <optional explicit terms the user does not understand>
     references: <optional [{reference_id, label, origin, url?, excerpt?}]>
   

   返回会话 ID 和第一个问题。confused_terms 和 references 是结构化的适配器上下文，不是需求。它们绝不能影响第一个问题；之后，术语表说明只涵盖明确表示困惑的术语，引用资料只用于对比问题。不要从词汇密度推断这些内容，也不要获取被引用的网址或文件。在之后的回答中，只有当用户引入了新的引用资料或询问某个术语的含义时，才将它们纳入；产品决策仍应保留在回答中。

2. 通过以下 PATHs 路由每个问题。先检查响应：

   • meta.status="parent_question_required" 或 meta.ask_user_directly=true：这是正常轮次，不是失败。遵循响应文本：亲自提出一个苏格拉底式问题，绝不提及 MCP、提供方故障或 reason_code，并将用户的回答与设为所提确切问题的 last_question 一并发送。
   • meta.question_advisory_request：运行下方的问题优先咨询扇出。
   • meta.lateral_review_required=true：运行下方的里程碑横向审查分派。
   • 错误和 meta.reason == "initial_context_too_large"：参见失败重试。

   问题优先咨询扇出：先展示访谈问题。咨询内容用于帮助人类作答；它绝不隐藏、替代或延迟问题，问题在各工作流运行期间始终保持可见。

   当存在 meta.question_advisory_subagents 时，你必须处理每个 payload：每个条目（title、agent、prompt、context）都是可直接启动的工作，其 prompt 必须保持不变。绝不要根据散文内容重构 prompt。遵循 meta.question_advisory_host_action：spawn_subagents 表示已声明并行支持；dispatch_subagents_if_supported 表示在可用时原生并行分派，否则按顺序处理；process_payloads_sequentially 要求按顺序处理。标记的 dispatch_mode（host_driven、dispatch_mode="host_decides"、sequential）含义相同。payload 是工作约定，而 host action 决定执行策略。若并行分派，则在一个扇出轮次中，通过当前运行时的 orchestrate_subagents 能力为每个 payload 启动一个子任务。等待所有结果返回后再综合。

   工作流：code_context（仓库内事实；复用 meta.code_investigation_request）、web_context（仅当当前外部事实会影响回答时使用）、data_context（进行测量；参见数据测量）、ambiguity_contrarian（隐藏假设、含糊术语、缺失决策、风险默认值）、answer_simplifier（2-3 个简单选项或一份简洁草案）、architecture_implications（所有权、接口、推出方式、系统形态）。综合成一份简短辅助内容：2-3 个回答选项、一份推荐草案，或一段简短的歧义说明。除非用户批准、修改或明确要求你自动确认安全答案，否则不要将咨询输出转发给 ouroboros_interview。

   提交扇出结果（重新进入）：当 meta 中带有 fanout_id（meta.question_advisory_fanout_id，或横向角色面板的 fanout_id）时，在所有子任务返回后调用 ouroboros_submit_fanout_results，并提供：

   • session_id：发起扇出时所用的会话；若发起方有此值而你未提供，则会被拒绝。
   • fanout_id：标记的 ID。
   • correlation_key：标记的 result_correlation_key（context.lane_id、context.persona 或 code_facts）；若扇出记录了此值而你未提供，则会被拒绝。
   • results：每个工作流各一个条目，格式为 { "key": <correlation value>, "content": <child output> }，或严格按 { "key": <lane>, "undispatched": true }（字面量 true，不含 content）。即使工作流已运行但没有发现任何内容，也要提交其输出。完全无法启动的工作流（无相应能力、子任务已终止、用户取消）标记为 undispatched。绝不要编造未运行工作流的输出。无效条目会一并返回，状态为 status="invalid_result_entry"，并包含 invalid_keys。 完整集合会返回一个有界的产物信封。使用其 contract_id 调用 ouroboros_fetch_artifact，然后从获取到的 body 中对应的综合内容继续；即使主机没有 shell，也必须进行此 MCP 获取。部分集合会返回 status="partial" 和 missing_required_keys：请用你掌握的所有 lane 重试，而不只是缺失的 lane，因为各次调用之间不会保留已提交的输出。顺序执行的主机会累积输出，并发送不断增长的集合。只有标记为 required: true 的 lane 才会阻止完成。从获取到的综合内容继续访谈。

   数据测量：data_context lane 会发现主机的数据工具，亲自进行测量，并返回其读取的汇总数据。在它运行之前，不会确认任何内容；它运行之后，也不会再执行任何操作；用户注册工具即表示同意调用该工具。当其输出包含测量结果时：

   • 将数字放在问题旁边，供用户判断，绝不能当作答案。用户通过常规的 [from-user] 路径回答；没有需要转发的 [from-data] 答案。
   • 按 lane 报告的内容传递汇总数据，并保留其 metric 及其所支持的决策。不要重新推导、换算或合并数字。
   • 如果测量结果到达时用户已经回答了问题，就舍弃它。不要用它重新开启决策：证据用于辅助决策，而不是让人重新审视已经作出的决定。

   当 data_needed 为 false 时，原因应描述 lane，而不是用户的基础设施；请用自己的话表达，不要照搬固定文本。对于 not_a_measurement、question_too_ambiguous_to_measure、answer_would_not_be_an_aggregate：继续处理即可。仅当你知道存在数据存储，且 lane 未获知此事时，才提及 no_data_store_described。store_described_but_not_callable 由你处理，不要让用户听到；检查该工具是否对你可用，亲自读取数据，或者重新分派该 lane。不要在测量结果旁附加只读或费用免责声明；没有任何步骤会检查这些事项。

   里程碑横向审查分派：meta.lateral_review_required=true（较早的响应只有 meta.lateral_review_recommended=true）表示访谈跨越了一个模糊度里程碑（initial -> progress、progress -> refined、refined -> ready）。服务器每个会话的每个里程碑最多触发一次。将其视为本轮必须进行的轻量级子 Agent 审查，并静默执行：展示问题后，使用 meta.lateral_review_tool_args 调用 ouroboros_lateral_think，并在同一轮扇出中分派其角色载荷和建议 lane。不要宣布此事。它的角色仅限于建议 lane 尚未运行的角色，因此应将其发现融入同一辅助内容（选项或建议草稿），绝不要单独另设一个区块；只有当某项发现改变了建议答案或下一问题时，才提及它。如果只有旧版建议字段，则使用 personas=["researcher","contrarian","simplifier"]，并将问题上下文设为包含会话、里程碑和问题，将当前方案设为描述下一步访谈路由决策。如果横向审查工具不可用，请继续访谈，并说明无法执行审查。横向审查不会改变要求，也不会单独将访谈标记为完成。 主会话直接回答辅助：如果你本来会自行回答 MCP 问题，或将用户的自由文本压缩成一项决策，那么顾问通道就是你的侧向审查：ambiguity_contrarian 和 answer_simplifier 会针对每个问题分别运行唱反调和简化者角色，architecture_implications 则会运行架构师角色。根据它们的输出，拟定 2-3 个具体选项，或一份推荐草案，然后让用户批准、调整或切换到自动模式。对于带有顾问通道的问题，不要再次调用 ouroboros_lateral_think。只有当响应不带任何顾问通道（例如你自行撰写问题的 meta.ask_user_directly=true 轮次），且你即将根据不完整的输入综合得出产品、UX 或架构方面的回答时，才针对该问题最多调用一次，并选择一个角色：涉及权衡、优先级、非目标、风险或成功标准时用 contrarian；当答案会改变系统形态或归属时用 architect；当用户似乎很忙或回复简短时用 simplifier。同样适用保持沉默的规则。

   路径 1：代码答案（当前状态：技术栈、框架、依赖项、模式、架构、文件布局）。使用 inspect_code。描述事实，而非提出方案：“项目使用 JWT”是事实；“新功能应该使用 JWT”则是决策，因此属于路径 2。

   • 路径 1a：自动确认 仅在以下条件全部满足时使用：答案与清单或配置文件（pyproject.toml、package.json、go.mod、Dockerfile、.env.example、锁定文件、CI 配置）中的内容完全一致；纯属描述性信息；且没有歧义（只有一个候选项）。立即发送 [from-code][auto-confirmed]，显示非阻塞提示（ℹ️ Auto-confirmed: Python 3.12, FastAPI framework (pyproject.toml)），如果用户之后表示有误，再发送更正。
   • 路径 1b：代码确认 其他情况均适用（根据模式推断、存在多个候选项，或清单中没有匹配项）：使用确认流程，并加上 [from-code] 前缀。

   路径 2：人工判断（目标、愿景、验收标准、业务逻辑、偏好、权衡、范围、新功能的行为）：通过 ask_user 提问，并提供建议选项；加上 [from-user] 前缀。

   路径 3：代码 + 判断（存在事实，但需要解读，例如：“我在 orders/ 中看到 saga 模式。支付是否也应采用相同模式？”）：先阅读代码，将发现与问题一同展示，然后将整个问题交由用户决定；加上 [from-user] 前缀。

   路径 4：研究插曲（第三方 API、定价、库的能力、版本兼容性、安全公告、代码库无法回答的标准）：使用 web_research，然后采用确认流程，并加上 [from-research] 前缀。事实，不是决策：“Stripe 的速率限制是 100 req/s”属于研究；“我们应该使用 Stripe”属于路径 2。

   拿不准时，使用路径 2。

   确认流程（路径 1b、路径 4）：通过 ask_user 提问：“MCP 询问：。我查到：。这正确吗？”并提供选项 Yes, correct 和 No, let me correct。

   • Yes, correct：加上该路径的前缀，发送简洁的事实；无需经过“优化”关卡。
   • No, let me correct，或用户直接输入更正内容：将更正后的答案作为自由文本收集（询问是否需要保留任何理由、约束或范围），经过“优化”关卡，然后加上 [from-user][refined] 发送。

3. 发送答案。

   Tool: ouroboros_interview
   Arguments:
     session_id: <session ID>
     answer: <prefixed answer>
     last_question: <exact question text, required when you rather than MCP asked it (parent handoff, Restate reopen)>
   

   MCP 只能看到你发送的文本，因此切勿将推理压缩成标签。包含理由、约束或范围的自由文本答案，经过“优化”关卡后，按以下多节载荷发送：

   [from-user][refined]
   Decision: Stripe Billing.
   
   Reasoning:
   - Subscription is the core business model.
   
   Constraints (user-stated):
   - 30% Korean MAU, KRW required.
   
   Out of scope (user-stated):
   - Refund policy changes, tax-invoice issuance.
   
   Codebase context (main session verified):
   - src/payments/toss_adapter.py is one-shot KRW only.
   

   对于路径 1a 的事实、已确认的答案，以及没有附带其他内容的简短路径 2 答案（[from-user] Yes），单行即可。 前缀：[from-code]、[from-user]、[from-research] 用于标明来源；[auto-confirmed] 表示 PATH 1a。只有通过 Refine 门后，才追加 [refined]；MCP 会将经过润色的答案视为高置信度的真实依据。当经过润色的答案明确结束访谈时，添加 [closure] 标记（[from-user][refined][closure]）；绝不要通过匹配自然语言短语来表示结束。

4. Refine 门（包含推理、约束或范围的自由文本回答）。将答案整理成上述载荷，然后通过 ask_user 询问：“发送给 MCP 前，我将你的回答整理如下：。有遗漏或表述不准确的地方吗？”选项：Send as-is、Add to Constraints、Add to Out of scope、Add context、Rewrite。

   • 如果选择的选项不是 Send as-is，绝不要根据选项标签推断缺失文本：追问一次，请用户提供确切文本，应用后再进行一次 Refine 门检查。如果第二次回答仍要求修改，则提出一个有针对性的 PATH 2 追问，并暂缓提供 MCP 答案，直到用户提供文本或接受该载荷。绝不要转发用户认为不完整的载荷。
   • 对 PATH 1a 事实、已接受的确认，以及不附带推理的简短 PATH 2 回答，跳过此步骤。重述更正（第 9 步）无论多简短，都不得跳过。

5. **对话节奏防护。**统计连续多少个问题是在没有用户直接判断的情况下得到回答的（PATH 1a 自动确认以及已接受的 PATH 1b / PATH 4 确认）。达到 3 次后，下一个问题必须转到 PATH 2，即使代码或研究能够回答也一样。收到任何用户直接回答（PATH 2、PATH 3，或作为 [from-user][refined] 发送的更正）时，将计数重置为 0。

6. **歧义台账。**分别跟踪并明确展示范围、约束、输出和验证；不要让访谈收窄到单一子主题。

7. 重复步骤 2-6，直到用户结束访谈（发送 [from-user][refined][closure]），或响应包含 meta.seed_ready=true。

8. **Seed-ready 接受防护。**MCP 发出 seed-ready 信号时，不要转达完成状态。在宣布完成或建议运行 ooo seed 之前，通过 orchestrate_subagents 执行三个审查通道（运行环境没有并行功能时，依次执行），并使用 context.lane_id 关联；每个通道都必须获得 MCP 未见过的代码、研究和 brownfield 上下文：

   • closer：应用 seed-closer.md 中的标准，并按 Path B 角色提示进行处理。其判定具有否决权。
   • contrarian：查找隐含假设、过度宽泛的术语，以及访谈中跳过的决策。
   • gap_hunter：查找缺失需求、未列出的约束、未处理的边缘情况，以及无法验证的验收标准。

   每个通道只返回 JSON：

   • closer：{"lane_id": "closer", "verdict": "seed_ready" | "not_ready", "reason": "...", "blocking_question": "..." | null}
   • contrarian / gap_hunter：{"lane_id": "<lane>", "severity": "high" | "medium" | "low", "finding": "...", "question": "..." | null}；仅当缺口会实质性改变实现时，才标为 high。

   当 closer 判定不是 seed_ready，或任何 contrarian / gap_hunter 的严重性为 high 时，阻止结束流程。此时覆盖该信号（“MCP 表示 seed-ready，但我暂不接受，因为 。”），简要说明缺口，并通过 PATH 2 或 PATH 3 提出影响最大的一个阻塞问题。

9. 重述关卡（Seed 就绪验收守卫通过后）。用一句话重述双方认同的目标，并通过 ask_user 提问：“目标：<一句话重述>。如果其他人只读这一行，他们能得出你设想的结果吗？”选项：Yes, generate seed、Adjust wording、Missing scope。

   • Yes, generate seed：建议执行 ooo seed。
   • Adjust wording / Missing scope：询问替换措辞，或缺失的条件或边界。这属于真正的访谈修正：对其运行 Refine 关卡，将 Decision 设为修正后的目标原文，Reasoning 不作改写地保留用户的修正文本，以及其中引入的任何约束、范围外事项或已验证的代码库上下文。以 [from-user][refined] 发送，并将 last_question 设为你提出的确切重述后续问题；处理程序会拒绝缺少 last_question 的重新开启。返回步骤 7，让 MCP 更新其状态，然后再次运行步骤 8；绝不能基于修正前的状态执行 ooo seed。
   • 然后用修正后的目标再次询问重述关卡。最多循环两次；如果仍未达成一致，请改为提出有针对性的 PATH 2 问题，而不要强行确定目标措辞。

失败时重试

• is_error=true 且 meta.recoverable=true：告知用户你将重试，并使用 session_id 调用 ouroboros_interview 以恢复（状态已持久化；最多重试 2 次）。如果仍然失败，请说明你将切换到直接访谈模式，并从中断处继续路径 B。
• meta.reason == "initial_context_too_large"（is_error=false）：这段文本是给你的指令，不是访谈问题；绝不要将其转交给 ask_user。在 meta.max_chars 字数限制内总结原始 initial_context（目标、约束、成功标准），并将其作为 answer 连同 session_id 一起重新发送。下一条响应会包含真正的第一个问题。

路径 B：回退（无 MCP 服务）

1. 阅读 socratic-interviewer 提示词并采用其角色：若已设置该覆盖项，则使用 $OUROBOROS_AGENTS_DIR/socratic-interviewer.md；否则使用已安装软件包中的副本，通过 run_shell 打印：

   uvx --isolated --python '>=3.12' --from ouroboros-ai python -c "import importlib.resources as r, sys; print(r.files('ouroboros.agents').joinpath(sys.argv[1]).read_text(encoding='utf-8'))" socratic-interviewer.md
   

   否则，使用源代码检出中的 src/ouroboros/agents/socratic-interviewer.md。

2. 使用 inspect_code 预先扫描配置文件（pyproject.toml、package.json、go.mod 等），并提出确认式问题（“我看到 X。是否应该假设 Y？”），而不是开放式探索问题。

3. 通过 ask_user 提出每个问题，并提供建议答案；按需使用 inspect_code 和 web_research。

4. 维护歧义清单：追踪相互独立的议题，每隔几轮重新查看尚未解决的议题，不要让某个子主题挤占原始请求。

5. 对自由文本答案应用 Refine 关卡，在结束前应用 Seed 就绪验收守卫，并在建议执行 ooo seed 前应用重述关卡。没有 MCP 状态时，将重述修正应用到本地清单和目标措辞，在本地重新运行守卫，然后再次询问重述关卡。

6. 结果仅保留在对话中（不会持久化）。

RFC #1392 状态提示页脚

最终响应必须以且仅以一行 ◆ <current state> → next: <recommended action> 结束。有 ouroboros_session_status 可用时，根据实时会话状态确定状态；否则根据此技能的实际结果确定。绝不要使用线性 Step N of M 页脚；如果下一步确实需要选择，则列出 2-3 个选项。