triangulate-diagnosis

三方诊断

根据运行默认设置选择执行模式。 如果用户未要求使用子 Agent，则调用 diagnose 进行单次内联诊断，标明其范围， 并停止此工作流；不要将其说成独立的三方诊断。

以下三轮分支要求用户请求的范围涵盖三名工作者，并且能够观察到彼此独立的上下文。 如果其中任一条件不满足，应报告限制，而不是虚构授权或独立性。比较彼此隔离的报告， 记录它们的趋同或分歧；不要把多数意见说成比其反馈循环所能支持的更强证据。

此技能会编排其他小型技能：

• diagnose：每个子 Agent 执行的、严谨的复现、假设和定位 循环。
• to-spec：将趋同的诊断或决策记录为规范。
• to-tickets：需要执行具体工作时创建后续工单。
• wayfinder：梳理范围仍过宽或问题仍不清晰、无法通过一次诊断 完成的 Bug 区域。

阶段 0：撰写共享简报

分发任务前，提炼一份所有子 Agent 都会原样收到的 Bug 简报。这是唯一的共享上下文。 简报应陈述事实，不带解读，以保持三份诊断相互独立。不要加入你自己的假设或对原因的 猜测。

简报必须包含：

• 用户描述的确切症状，包括错误文本、错误输出、发生时间或截图。
• 如何找到相关代码：仓库路径、服务、入口点和相关命令。
• 对话中已知的复现步骤、测试夹具或环境说明。
• 硬性约束：哪些功能必须继续正常运行，以及哪些内容不在范围内。
• REFERENCE.md 中规定的输出约定。

在证据进入共享简报、委派诊断或持久化报告之前，按照规范的 diagnose 机密信息脱敏边界处理证据。

如果缺少会改变简报内容的事实，且只有用户掌握该事实，则在分发任务前提出一个简短的 阻塞性问题。否则继续。

阶段 1：分发三项独立诊断

运行用户要求的三名诊断工作者；仅在请求范围和实际宿主支持的条件下并发运行。每名工作者都要：

• 根据共享简报运行 diagnose 技能。
• 隔离工作。不要向子 Agent 提供你的猜测，也不要让子 Agent 看到彼此的结果。
• 返回 REFERENCE.md 中定义的结构化诊断报告：根本原因、证据、反馈循环、 修复位置、置信度，以及已排除的其他可能性。

为了促成有价值的差异，让每个子 Agent 除共享简报外还采用不同的观察角度：

1. 优先复现：优先建立反馈循环，并通过二分定位引入 Bug 的变更。
2. 数据流：端到端追踪输入在各模块中的流转；重点怀疑边界、类型和联结。
3. 近期变更／环境：重点怀疑近期提交、配置、依赖项、基础设施和时序问题。

观察角度只决定他们优先从哪里着手，不决定得出什么结论。每名工作者都必须跟随证据 进行调查。

如果子 Agent 报告无法建立反馈循环，则应将其报告视为低置信度，并在阶段 2 中说明。

第 2 阶段：收敛

收集三份报告并进行比较。生成简短的收敛摘要：

• 共识根因：至少有两个子 Agent 独立识别出的原因，只陈述一次。统一措辞，并引用每份认同报告中最有力的证据。
• 分歧：说明各方在哪些方面存在分歧，以及原因。
• 独特见解：只有一个子 Agent 提出的实际发现，例如排除的替代方案、相关问题或遗漏的测试边界。
• 置信度：如果三方都达成共识且有共同的反馈闭环，则为高；如果三方中有两方达成共识，则为中；如果三方各执一词，或没有任何一方构建闭环，则为低或受阻。

决策门槛：

• 三方或三方中的两方达成共识：携带共识根因继续进入第 3 阶段。
• 三方意见不一，或分歧取决于只有用户掌握的信息：停止。列出候选原因及其证据，并询问用户要继续调查哪一个。只有当用户请求的范围包含额外一轮时，才允许增加一名决胜工作者。

除非用户明确要求完全自主执行，否则必须先向用户展示收敛摘要，再进行其他操作。

第 3 阶段：将共识记录为规范

调用 to-spec，并传入收敛摘要作为已收集的上下文：

• 将共识根因作为诊断规范的核心。
• 将一致同意的修复位置或方法作为 Decision / Solution 的起点。
• 将排除的替代方案列入 Options Considered。
• 将独特见解列入 Evidence、Testing Decisions 或 Open Questions。
• 如果置信度为中或低，则将状态设为 Proposed，并将未解决的分歧列为开放问题。

将规范保存或更新至 docs/specs/<slug>.md。

第 4 阶段：必要时创建后续工单

如果共识意味着需要执行工作，则调用 to-tickets，并将诊断规范或决策规范设为父项。生成的工单应保存至：

docs/tickets/<spec-slug>/<NN>-<ticket-slug>.md

每份工单都应说明要构建的内容、验收标准、明确的阻塞项、前沿状态和验证预期。

如果用户只要求诊断和文档记录，则将后续工作作为规范中的一个章节，不要创建工单文件。

最终回复

最终回复应简短：

• 用一行说明共识原因。
• 置信度。
• 规范路径。
• 若已创建，则列出工单文件夹或工单路径。
• 任何开放问题或需人工决策的事项。

可移植性说明

针对用户要求的各轮任务，使用彼此独立且可观察地隔离的主机工作者。如果无法并发运行，则依次运行这些工作者，同时保留彼此独立的上下文。如果主机完全无法隔离上下文，则报告这一限制，不要运行三轮受锚定的任务；清除可见备注并不能证明隔离已实现。