Trace Skill（追踪技能）
当问题模糊、涉及因果和密集证据，且目标是解释为什么会观察到某个结果，而不是直接跳入修复或重写代码时，请使用此技能。
这是 tracer 代理之上的一层编排层。其目标是让追踪感觉像一个可复用的 OMC 操作车道：重述观察结果，生成竞争性解释，并行收集证据，对解释进行排序，并提出能最快消除不确定性的下一步探针。
好的入口案例
当问题具有以下特征时，使用 /oh-my-claudecode:trace：
- 模糊
- 因果性
- 证据密集
- 最好通过并行探索竞争性解释来回答
示例：
- 运行时错误和回归问题
- 性能/延迟/资源行为
- 架构/事前分析/事后分析
- 科学或实验结果追踪
- 配置/路由/编排行为解释
- “给定此输出，追溯可能的原因”
核心追踪契约
始终保留这些区分：
- 观察结果 —— 实际观察到的情况
- 假设 —— 竞争性解释
- 支持证据 —— 支持每个解释的内容
- 反对证据/差距 —— 与之相矛盾或仍然缺失的内容
- 当前最佳解释 —— 目前最可能的解释
- 关键未知因素 —— 使顶级解释之间保持分歧的缺失事实
- 鉴别性探针 —— 消除不确定性的最高价值下一步行动
不要退化为：
- 一个通用的修复编码循环
- 一个通用的调试器摘要
- 工作节点输出的原始转储
- 在证据不完整时虚假的确定性
证据强度层级
将证据视为分级的，而不是平面的。
从最强到最弱：
- 可控复现/直接实验/唯一定义性工件
- 具有严格溯源的主要源代码工件（追踪事件、日志、指标、基准输出、配置、git 历史、file:line 行为）
- 指向同一解释的多个独立来源
- 单源代码路径或行为推断
- 弱间接线索（时间、命名、堆栈顺序、与先前错误的相似性）
- 直觉/类比/推测
当存在更强的矛盾证据时，显式地降低主要依赖较低层级的假设的排名。
强证伪/否证规则
每次严肃的 /trace 运行都必须尝试证伪其最喜欢的解释。
对于每个顶级假设：
- 收集支持它的证据
- 收集反对它的证据
- 说明它做出的独特预测
- 说明哪些观察结果会很难与它协调一致
- 确定能够将其与次优替代方案区分开来的最便宜探针
在以下情况下降低假设的排名：
- 直接证据与之矛盾
- 它仅通过添加新的未经验证的假设而存活
- 与竞争对手相比，它没有做出独特的预测
- 一个更强的替代方案以更少的假设解释了相同的事实
- 其支持主要是间接的，而竞争对手拥有更强的证据层级
团队模式编排形态
在 /trace 中使用 Claude 内置团队模式。
主节点应：
- 精确重述观察到的结果或“为什么”问题
- 提取追踪目标
- 生成多个故意不同的候选假设
- 在团队模式下默认生成 3 个追踪分支
- 为每个分支分配一个追踪工作节点
- 指示每个追踪工作节点为其分支收集支持和反对的证据
- 在主导假设与最强的剩余替代方案之间运行一个 反驳回合
- 检测顶级分支是否真正不同，或者实际上收敛于同一个根本原因
- 将发现结果合并成一个排序的综合报告，包含明确的关键未知因素和鉴别性探针
重要提示：工作节点应追求故意不同的解释，而不是并行追求相同的解释。
V1 的默认假设分支
除非提示强烈建议更好的划分，否则使用以下 3 个默认分支：
- 代码路径/实现原因
- 配置/环境/编排原因
- 测量/工件/假设不匹配原因 —— 涵盖验证方法缺陷，不仅仅是系统缺陷。例如：验证查询在多个不同实体、租户、流或组之间重复使用单个维度键；比较过滤器的形状与模式粒度不匹配；或者假设目录或列名在未枚举的情况下跨运行时可移植。这包括多实体前提/关键假设不匹配。
对于分支 3，在升级之前需要先进行前提审计：枚举实体维度，并检查零行或不匹配结果是否来自于将单个键应用于多个实体，而不是系统缺陷；结果可能是验证方法的缺陷。
这些默认值故意设计得很宽泛，以便第一次切片可以在错误、性能、架构和实验追踪中工作。
强制性交叉检查视角
在初步证据传递之后，在相关时使用以下视角对领导者进行压力测试：
- 系统视角 —— 队列、重试、背压、反馈循环、上游/下游依赖、边界失败、协调效应
- 事前分析视角 —— 假设当前的最佳解释是不完整或错误的；以后什么故障模式会让追踪感到尴尬？
- 科学视角 —— 控制、混杂因素、测量偏差、替代变量、可证伪预测
这些视角不是填充物。当它们能够揭示被遗漏的解释、隐藏的依赖或薄弱的推理时再使用它们。
工作节点契约
每个工作节点应该是一个 tracer 分支的所有者，而不是一个通用的执行器。
每个工作节点必须：
- 完全拥有一个假设分支
- 明确重述其分支假设
- 收集支持该分支的证据
- 收集反对该分支的证据
- 对其案例背后的证据强度进行分级
- 指出缺失的证据、失败的预测和剩余的不确定性
- 命名该分支的关键未知因素
- 推荐最佳的特定于分支的鉴别性探针
- 除非明确指示，否则避免退化为实现
有用的证据来源包括：
- 相关代码、测试、配置、文档、日志、输出和基准工件
- 通过
trace_timeline获取现有的追踪工件 - 通过
trace_summary获取现有的聚合追踪证据
推荐的工作节点返回结构：
- 分支
- 假设
- 支持证据
- 反对证据/差距
- 证据强度
- 关键未知因素
- 最佳鉴别性探针
- 置信度
主节点综合契约
最终的 /trace 答案应该是综合的，而不仅仅是拼接。
返回：
- 观察到的结果
- 排序后的假设
- 按假设的证据摘要
- 反对证据/缺失证据
- 反驳回合
- 收敛/分离说明
- 最可能的解释
- 关键未知因素
- 推荐的鉴别性探针
- 额外的追踪分支（可选，仅当不确定性仍然很高时）
即使一个解释目前占主导地位，也应保留排好序的候选列表。
反驳回合和收敛检测
在关闭追踪之前：
- 让最强的非主导分支向当前领导者提出最佳反驳
- 迫使领导者用证据而不是断言来回应反驳
- 如果反驳实质上削弱了领导者，则重新排序表格
- 如果两个“不同”的假设归结为相同的基础机制，则合并它们并明确说明
- 如果两个假设仍然暗示不同的下一步探针，即使它们听起来相似，也要保持它们分开
不要仅仅因为多个工作节点使用了相似的语言就声称收敛。收敛需要满足以下条件之一：
- 相同的根本因果机制，或者
- 指向同一解释的独立证据流
显性下调排名指导
主节点应明确说明为什么某个假设被降级：
- 被更强的证据反驳
- 缺少其预测的观察结果
- 需要额外的特设假设
- 解释的事实少于领导者
- 输掉了反驳回合
- 收敛到一个更强的父解释中
这很重要，因为 /trace 应该教给读者为什么一个解释优于另一个，而不仅仅是呈现一个最终表格。
建议的主节点提示骨架
使用一个面向团队的编排提示，大致如下：
- “精确重述观察结果。”
- “生成 3 个故意不同的假设。”
- “使用 Claude 内置团队模式为每个假设创建一个追踪分支。”
- “对于每个分支，收集支持和反对的证据，对证据强度进行分级，并命名关键未知因素和最佳鉴别性探针。”
- “如果有用，对领导者应用系统、事前分析和科学视角。”
- “在最好的两个解释之间运行一个反驳回合。”
- “返回一个排序的解释表、收敛说明、关键未知因素和单个最佳鉴别性探针。”
输出质量标准
好的 /trace 输出是：
- 以证据为基础的
- 简洁但严谨
- 对过早的确定性持怀疑态度
- 明确的缺失证据
- 关于下一步行动的实用性
- 明确说明为什么较弱的解释被降级
示例最终综合格式
观察到的结果
[发生了什么]
排序后的假设
| 排名 | 假设 | 置信度 | 证据强度 | 为何领先 |
|---|---|---|---|---|
| 1 | ... | 高/中/低 | 强 / 中 / 弱 | ... |
按假设的证据摘要
- 假设 1：...
- 假设 2：...
- 假设 3：...
反对证据/缺失证据
- 假设 1：...
- 假设 2：...
- 假设 3：...
反驳回合
- 对领导者的最佳反驳：...
- 领导者为何维持/失败：...
收敛/分离说明
- ...
最可能的解释
[当前最佳解释]
关键未知因素
[保持不确定性开放的唯一缺失事实]
推荐的鉴别性探针
[单个下一步探针]
额外的追踪分支
[仅当不确定性仍然很高时]