oh-my-claudecode 的 OMC trace 实战指南从/oh-my-claudecode:trace斜杠命令到证据驱动的 Tracer 多路编排【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode/oh-my-claudecode:trace是 oh-my-claudecode下称 OMC提供的一个兼容性斜杠命令它以极轻量的调度文档commands/trace.md暴露入口把真正完整、可复用的证据驱动因果追溯操作规范沉淀在 skills/trace/SKILL.md 中避免在每个 Claude Code 会话里都加载整份技能描述。读完本文你将掌握如何调用该命令、理解命令到技能的调度链路、以及那套观测—多假设—对抗性取证—降权—综合—下一个探针的可复用追溯协议并能结合 tracer Agent 的源码级定义判断它适用的场景边界。一、命令定位轻量兼容命令 完整技能的分层架构与常见的把全部逻辑塞进一条命令的做法不同OMC 把trace拆成两层兼容命令层commands/trace.md 本身只有十几行核心作用只有一个——让/oh-my-claudecode:trace始终可用同时不把完整的traceskill 描述灌入每一个会话上下文。完整技能层skills/trace/SKILL.md 承载全部追溯协议包括 frontmatteragent: tracer、level: 2、argument-hint: observation to trace与正文操作契约。这种命令薄壳 技能实体的模式在仓库中并非孤例。以同目录的 commands/verify.md 为例其结构与 trace 完全同构同样声明保持/oh-my-claudecode:verify可用但不加载完整 verify skill 描述然后按$ARGUMENTS派发到skills/verify/SKILL.md。可以推断这是 OMC 统一的兼容命令生成模板凡是有独立skills/name/SKILL.md的能力就会在 commands 目录生成一条等价的轻量派发命令。二、Dispatch 派发流程命令如何找到真正的技能命令文档明确定义了调度顺序共三个步骤从当前活跃的 OMC 插件/安装中读取完整的内置技能指令文件skills/trace/SKILL.md严格遵循该 SKILL.md 执行并把用户的输入参数原样视作$ARGUMENTS如果该文件无法直接从当前工作目录CWD读取则在活跃的CLAUDE_PLUGIN_ROOT/OMC_PLUGIN_ROOT、包根目录package root或已安装的 OMC 插件目录下定位后继续执行。也就是说技能文件存在三个可回退的查找层级CWD 直读 → 插件根目录 → 包根目录/已安装插件目录。这种多级回退保证了无论用户是在仓库源码内、全局安装态还是插件安装态下运行该命令/oh-my-claudecode:trace都能正确定位到同一份权威协议。对应的技能调用方式可以参考 skills/AGENTS.md 给出的统一规范# 手动调用 /oh-my-claudecode:trace # 携带参数 /oh-my-claudecode:trace observation to trace三、何时使用 trace适用的难题类别与不适用的回退trace面向的是歧义性、因果性、证据密集型的问题——目标是解释为什么观察到这个结果而不是立刻跳进修复或重写代码。典型输入场景包括运行时 bug 与回归regression性能 / 延迟 / 资源行为异常架构级 premortem / postmortem 分析科学或实验结果的追溯配置 / 路由 / 编排行为的因果解释以及最经典的一类——给定这个输出追溯回最可能的成因。同时协议明确警告不要坍缩为以下几种错误形态泛泛的修复式编码循环fix-it loop、泛化的 debugger 摘要、对 worker 原始输出的生硬转储raw dump以及在证据不足时伪造确定性fake certainty。四、核心追溯契约始终保留的七项区分无论追溯进行到哪一步都必须在输出与推理中守住这七项区分它们是整个协议的地基Observation观测—— 实际观察到了什么Hypotheses假设—— 相互竞争的多种解释Evidence For支持性证据—— 支持每种解释的事实Evidence Against / Gaps反驳性证据 / 缺口—— 与其矛盾或缺失的信息Current Best Explanation当前最佳解释—— 此刻的领先解释Critical Unknown关键未知—— 让领先解释之间无法拉开差距的那个缺失事实Discriminating Probe判别探针—— 能以最快速度坍缩不确定性的下一个高价值步骤。这七项不仅是思考清单也直接决定了最终报告的结构见下文Leader 综合契约。五、证据强度层级先分级再比较证据不是扁平的堆料必须分级处理从强到弱共六层受控复现 / 直接实验 / 具备唯一判别力的工件具有严格来源追溯的一手证据工件trace 事件、日志、指标、benchmark 输出、配置、git 历史、file:line行为多个独立来源收敛于同一解释单一来源的代码路径或行为推断弱情境线索时序、命名、栈顺序、与既往 bug 的相似性直觉 / 类比 / 推测。当强证据与弱证据冲突时应显式降权依赖低层级证据的假设。这一分级逻辑与 tracer Agent 提示词中的Evidence_Strength_Hierarchy完全一致tracer 提示词同样把一手且可溯源工件排在单一来源代码路径推断之前并要求如果更高层级与更低层级冲突通常应降权或丢弃低层级支持。六、强证伪Falsification规则必须尝试推翻自己的最爱每一次严肃的/trace都必须尝试证伪自己当前最偏爱的解释。对每个顶级假设需要做到收集支持它的证据收集反对它的证据说明它作出的独有预测distinctive prediction说明什么样的观测会与它难以调和找出能把它与次优替代方案区分开来的最廉价探针。一个假设在以下情况下应当被降权直接证据与它矛盾它只能靠不断追加未经验证的新假设才存活与对手相比它无法作出独有预测存在用更少假设解释相同事实的更强替代方案它的支撑大多是情境性弱证据而对手位于更高证据层级。对应地agents/tracer.md 中的Disconfirmation_Rules提供了两条关键反问如果该假设为真应该出现什么观测而我们现在真的看到了吗以及如果该假设为真什么观测会很难解释——并强调要优先选择能区分顶级假设的探针而不是再多收集同类支持。七、Team-mode 编排三条默认假设通道v1 默认/trace在Claude 内置 team mode下运行由 lead 统一编排。默认编排形状如下精确复述观测到的结果或为什么问题抽取追溯目标生成多条刻意不同的候选假设默认在 team mode 中孵化3 条 tracer 通道lane为每条通道指派一名 tracer worker指示每个 worker 同时收集支持与反对其通道的证据在领先假设与最强替代假设之间进行一轮答辩回合rebuttal round判断顶部通道是真正分歧还是收敛到同一根因把发现合并为一份带关键未知与判别探针的排序综合报告。关键原则worker 应追求刻意不同的解释而不是并行重复同一个解释。除非提示词强烈建议更优的切分方式v1 默认使用这三条通道代码路径 / 实现类成因Code-path / implementation cause配置 / 环境 / 编排类成因Config / environment / orchestration cause度量 / 工件 / 假设错配类成因Measurement / artifact / assumption mismatch cause——该通道覆盖验证方法本身的缺陷而不只是系统缺陷。典型例子包括验证查询在多个不同实体、租户、流或分组上复用了同一维度键比较过滤器的形态与 schema 粒度grain不匹配或目录/列名未经枚举就被假设可跨运行时移植。它明确包含跨实体前提/键假设错配。针对通道 3跨实体差异在升级为系统缺陷之前必须先做前提审计premise audit先枚举实体维度检查零行或错配结果是否来自用单一键去套多个实体而不是系统缺陷——结果可能是验证方法学缺陷。这三条默认通道刻意设计得足够宽让第一次切分就能同时覆盖 bug、性能、架构与实验追溯。八、必选交叉检查透镜systems / premortem / science完成第一轮证据收集后在相关的情况下要用三种透镜对领先假设做压力测试它们是实打实的分析工具而非凑数内容Systems 透镜队列、重试、背压、反馈回路、上游/下游依赖、边界失败、协调效应Premortem 透镜假设当前最佳解释不完整或错误——哪种失败模式会在事后让这次追溯难堪Science 透镜对照组、混淆变量、测量偏差、替代变量、可证伪的预测。九、Worker 契约每条通道的 owner 必须交付八项每个 worker 应是一条 tracer 通道的 owner而不是一个泛化 executor。worker 必须恰好拥有一个假设通道显式复述本通道的假设收集支持本通道的证据收集反对本通道的证据对其论据背后的证据强度排序指出缺失证据、失败预测与剩余不确定性点明本通道的关键未知推荐本通道最合适的判别探针除非被明确要求否则避免坍缩进实现细节。可用的证据来源包括相关代码、测试、配置、文档、日志、输出与 benchmark 工件以及既有追溯工件trace_timeline、既有聚合追溯证据trace_summary。推荐的 worker 返回结构共八项建议原样采用Lane通道Hypothesis假设Evidence For支持证据Evidence Against / Gaps反驳证据 / 缺口Evidence Strength证据强度Critical Unknown关键未知Best Discriminating Probe最佳判别探针Confidence置信度十、Leader 综合契约十项产出与收敛检测最终的/trace答案必须是综合而非简单拼接。lead 需返回Observed Result观测结果Ranked Hypotheses排序后的假设Evidence Summary by Hypothesis按假设归类的证据摘要Evidence Against / Missing Evidence反驳证据 / 缺失证据Rebuttal Round答辩回合Convergence / Separation Notes收敛 / 分歧说明Most Likely Explanation最可能的解释Critical Unknown关键未知Recommended Discriminating Probe推荐的判别探针Additional Trace Lanes可选仅在不确定性仍高时追加追溯通道即使某一解释当前占据主导也必须保留一个排序短名单ranked shortlist。在收尾前必须执行答辩回合与收敛检测让最强的非领先通道对当前 leader 提出最佳反驳强制 leader用证据而非断言回应反驳若反驳实质性地削弱了 leader则重新排序整个表格若两个看似不同的假设实际收敛到同一底层机制就合并它们并明说合并原因若两个假设仍暗示不同的下一步探针即便听起来相似也应保持分离。不能因为多个 worker 用词相近就宣称收敛。收敛必须满足二选一要么是同一根因因果机制要么是相互独立的证据流指向同一解释。十一、显式降权让读者理解为什么一个解释胜出lead 必须显式说明某个假设为何下移。标准理由清单包括被更强证据反驳、缺少它所预测的观测、需要额外的临时ad hoc假设、比 leader 解释的事实更少、输掉了答辩回合、收敛进了一个更强的父级解释。这一点尤其重要因为/trace不只是输出一张最终表格而是要教会读者为什么一个解释排在另一个之上。十二、推荐 Lead 提示骨架与质量门槛如果从零开始组织一次/trace会话可直接套用这条团队编排提示骨架精确复述观测。生成 3 条刻意不同的假设。在 Claude 内置 team mode 中为每个假设创建一条 tracer 通道。对每条通道收集支持与反对证据、对证据强度排序并点名关键未知与最佳判别探针。如有用对领先者应用 systems、premortem、science 透镜。在排名前二的解释之间执行一轮答辩回合。返回排序解释表、收敛说明、关键未知以及唯一最佳判别探针。质量门槛好的/trace输出应具备有证据支撑、简明但严谨、对过早确定性保持怀疑、明确列出缺失证据、对下一步行动务实、明确说明弱解释为何被降权。十三、最终综合报告的标准形态可直接复用一份合格的/trace终稿可按以下模板组织含推荐表格结构Observed Result[实际发生了什么]Ranked HypothesesRankHypothesisConfidenceEvidence StrengthWhy it leads1...High / Medium / LowStrong / Moderate / Weak...Evidence Summary by HypothesisHypothesis 1: ...Hypothesis 2: ...Hypothesis 3: ...Evidence Against / Missing EvidenceHypothesis 1: ...Hypothesis 2: ...Hypothesis 3: ...Rebuttal Round对 leader 的最佳反驳...leader 守住 / 落败的原因...Convergence / Separation Notes...Most Likely Explanation[当前最佳解释]Critical Unknown[使不确定性保持敞开的那个单一缺失事实]Recommended Discriminating Probe[唯一推荐的下一步探针]Additional Trace Lanes[仅当不确定性仍高时填写]十四、源码级佐证tracer Agent 与技能注册trace不是凭空捏造的角色它在源码与技能注册表中均有对应实体技能实体skills/trace/SKILL.md 的 frontmatter 声明name: trace、argument-hint: observation to trace、agent: tracer、level: 2即该技能由traceragent 执行Agent 注册src/agents/tracer.ts 中tracerAgent被定义为category: advisor、cost: EXPENSIVE、model/defaultModel均为sonnet的 AgentConfig其提示词通过loadAgentPrompt(tracer)加载Agent 提示词本体agents/tracer.md 完整定义了 Tracer 的角色、成功标准、约束、证据强度层级、证伪规则、九步Tracing_ProtocolOBSERVE → FRAME → HYPOTHESIZE → GATHER EVIDENCE → APPLY LENSES → REBUT → RANK/CONVERGE → SYNTHESIZE → PROBE、工具使用策略与Final_Response_Contract——要求最后一条 assistant 消息必须承载完整的 Trace Report 结构化交付物禁止以 done、no further comments 之类的空话收尾。从源码结构可以推断触发边界src/agents/tracer.ts中的元数据给出其avoidWhen纯实现/修复任务请用 executor/debugger泛化摘要不需要因果分析单文件检索用 explore 即可这正对应 SKILL.md 开头不要坍缩成修复循环 / debugger 摘要的纪律——两层文档在此互相印证。十五、总结与适用前提OMC 的trace是一套把科学怀疑精神工程化的团队编排能力用commands/trace.md提供低成本的斜杠命令入口用skills/trace/SKILL.md承载完整协议再由traceragent默认 sonnet 模型、advisor 类目在多通道 team-mode 中执行取证。适用前提是问题是歧义且因果密集的为什么你能接受当前最佳解释 关键未知 判别探针这种留有余地而非一口咬定的输出形态。若问题是确定性编码任务或单文件定位按设计应改用 executor / explore 等其它通道而不是强行启动三条取证通道。想进一步验证这套协议可依次阅读 skills/trace/SKILL.md协议全文、agents/tracer.mdagent 人格与终稿契约、src/agents/tracer.ts注册元数据并对比 commands/verify.md同构的兼容命令示例。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-claudecode 的 OMC trace 实战指南：从 `/oh-my-claudecode:trace` 斜杠命令到证据驱动的 Tracer 多路编排
oh-my-claudecode 的 OMC trace 实战指南从/oh-my-claudecode:trace斜杠命令到证据驱动的 Tracer 多路编排【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode/oh-my-claudecode:trace是 oh-my-claudecode下称 OMC提供的一个兼容性斜杠命令它以极轻量的调度文档commands/trace.md暴露入口把真正完整、可复用的证据驱动因果追溯操作规范沉淀在 skills/trace/SKILL.md 中避免在每个 Claude Code 会话里都加载整份技能描述。读完本文你将掌握如何调用该命令、理解命令到技能的调度链路、以及那套观测—多假设—对抗性取证—降权—综合—下一个探针的可复用追溯协议并能结合 tracer Agent 的源码级定义判断它适用的场景边界。一、命令定位轻量兼容命令 完整技能的分层架构与常见的把全部逻辑塞进一条命令的做法不同OMC 把trace拆成两层兼容命令层commands/trace.md 本身只有十几行核心作用只有一个——让/oh-my-claudecode:trace始终可用同时不把完整的traceskill 描述灌入每一个会话上下文。完整技能层skills/trace/SKILL.md 承载全部追溯协议包括 frontmatteragent: tracer、level: 2、argument-hint: observation to trace与正文操作契约。这种命令薄壳 技能实体的模式在仓库中并非孤例。以同目录的 commands/verify.md 为例其结构与 trace 完全同构同样声明保持/oh-my-claudecode:verify可用但不加载完整 verify skill 描述然后按$ARGUMENTS派发到skills/verify/SKILL.md。可以推断这是 OMC 统一的兼容命令生成模板凡是有独立skills/name/SKILL.md的能力就会在 commands 目录生成一条等价的轻量派发命令。二、Dispatch 派发流程命令如何找到真正的技能命令文档明确定义了调度顺序共三个步骤从当前活跃的 OMC 插件/安装中读取完整的内置技能指令文件skills/trace/SKILL.md严格遵循该 SKILL.md 执行并把用户的输入参数原样视作$ARGUMENTS如果该文件无法直接从当前工作目录CWD读取则在活跃的CLAUDE_PLUGIN_ROOT/OMC_PLUGIN_ROOT、包根目录package root或已安装的 OMC 插件目录下定位后继续执行。也就是说技能文件存在三个可回退的查找层级CWD 直读 → 插件根目录 → 包根目录/已安装插件目录。这种多级回退保证了无论用户是在仓库源码内、全局安装态还是插件安装态下运行该命令/oh-my-claudecode:trace都能正确定位到同一份权威协议。对应的技能调用方式可以参考 skills/AGENTS.md 给出的统一规范# 手动调用 /oh-my-claudecode:trace # 携带参数 /oh-my-claudecode:trace observation to trace三、何时使用 trace适用的难题类别与不适用的回退trace面向的是歧义性、因果性、证据密集型的问题——目标是解释为什么观察到这个结果而不是立刻跳进修复或重写代码。典型输入场景包括运行时 bug 与回归regression性能 / 延迟 / 资源行为异常架构级 premortem / postmortem 分析科学或实验结果的追溯配置 / 路由 / 编排行为的因果解释以及最经典的一类——给定这个输出追溯回最可能的成因。同时协议明确警告不要坍缩为以下几种错误形态泛泛的修复式编码循环fix-it loop、泛化的 debugger 摘要、对 worker 原始输出的生硬转储raw dump以及在证据不足时伪造确定性fake certainty。四、核心追溯契约始终保留的七项区分无论追溯进行到哪一步都必须在输出与推理中守住这七项区分它们是整个协议的地基Observation观测—— 实际观察到了什么Hypotheses假设—— 相互竞争的多种解释Evidence For支持性证据—— 支持每种解释的事实Evidence Against / Gaps反驳性证据 / 缺口—— 与其矛盾或缺失的信息Current Best Explanation当前最佳解释—— 此刻的领先解释Critical Unknown关键未知—— 让领先解释之间无法拉开差距的那个缺失事实Discriminating Probe判别探针—— 能以最快速度坍缩不确定性的下一个高价值步骤。这七项不仅是思考清单也直接决定了最终报告的结构见下文Leader 综合契约。五、证据强度层级先分级再比较证据不是扁平的堆料必须分级处理从强到弱共六层受控复现 / 直接实验 / 具备唯一判别力的工件具有严格来源追溯的一手证据工件trace 事件、日志、指标、benchmark 输出、配置、git 历史、file:line行为多个独立来源收敛于同一解释单一来源的代码路径或行为推断弱情境线索时序、命名、栈顺序、与既往 bug 的相似性直觉 / 类比 / 推测。当强证据与弱证据冲突时应显式降权依赖低层级证据的假设。这一分级逻辑与 tracer Agent 提示词中的Evidence_Strength_Hierarchy完全一致tracer 提示词同样把一手且可溯源工件排在单一来源代码路径推断之前并要求如果更高层级与更低层级冲突通常应降权或丢弃低层级支持。六、强证伪Falsification规则必须尝试推翻自己的最爱每一次严肃的/trace都必须尝试证伪自己当前最偏爱的解释。对每个顶级假设需要做到收集支持它的证据收集反对它的证据说明它作出的独有预测distinctive prediction说明什么样的观测会与它难以调和找出能把它与次优替代方案区分开来的最廉价探针。一个假设在以下情况下应当被降权直接证据与它矛盾它只能靠不断追加未经验证的新假设才存活与对手相比它无法作出独有预测存在用更少假设解释相同事实的更强替代方案它的支撑大多是情境性弱证据而对手位于更高证据层级。对应地agents/tracer.md 中的Disconfirmation_Rules提供了两条关键反问如果该假设为真应该出现什么观测而我们现在真的看到了吗以及如果该假设为真什么观测会很难解释——并强调要优先选择能区分顶级假设的探针而不是再多收集同类支持。七、Team-mode 编排三条默认假设通道v1 默认/trace在Claude 内置 team mode下运行由 lead 统一编排。默认编排形状如下精确复述观测到的结果或为什么问题抽取追溯目标生成多条刻意不同的候选假设默认在 team mode 中孵化3 条 tracer 通道lane为每条通道指派一名 tracer worker指示每个 worker 同时收集支持与反对其通道的证据在领先假设与最强替代假设之间进行一轮答辩回合rebuttal round判断顶部通道是真正分歧还是收敛到同一根因把发现合并为一份带关键未知与判别探针的排序综合报告。关键原则worker 应追求刻意不同的解释而不是并行重复同一个解释。除非提示词强烈建议更优的切分方式v1 默认使用这三条通道代码路径 / 实现类成因Code-path / implementation cause配置 / 环境 / 编排类成因Config / environment / orchestration cause度量 / 工件 / 假设错配类成因Measurement / artifact / assumption mismatch cause——该通道覆盖验证方法本身的缺陷而不只是系统缺陷。典型例子包括验证查询在多个不同实体、租户、流或分组上复用了同一维度键比较过滤器的形态与 schema 粒度grain不匹配或目录/列名未经枚举就被假设可跨运行时移植。它明确包含跨实体前提/键假设错配。针对通道 3跨实体差异在升级为系统缺陷之前必须先做前提审计premise audit先枚举实体维度检查零行或错配结果是否来自用单一键去套多个实体而不是系统缺陷——结果可能是验证方法学缺陷。这三条默认通道刻意设计得足够宽让第一次切分就能同时覆盖 bug、性能、架构与实验追溯。八、必选交叉检查透镜systems / premortem / science完成第一轮证据收集后在相关的情况下要用三种透镜对领先假设做压力测试它们是实打实的分析工具而非凑数内容Systems 透镜队列、重试、背压、反馈回路、上游/下游依赖、边界失败、协调效应Premortem 透镜假设当前最佳解释不完整或错误——哪种失败模式会在事后让这次追溯难堪Science 透镜对照组、混淆变量、测量偏差、替代变量、可证伪的预测。九、Worker 契约每条通道的 owner 必须交付八项每个 worker 应是一条 tracer 通道的 owner而不是一个泛化 executor。worker 必须恰好拥有一个假设通道显式复述本通道的假设收集支持本通道的证据收集反对本通道的证据对其论据背后的证据强度排序指出缺失证据、失败预测与剩余不确定性点明本通道的关键未知推荐本通道最合适的判别探针除非被明确要求否则避免坍缩进实现细节。可用的证据来源包括相关代码、测试、配置、文档、日志、输出与 benchmark 工件以及既有追溯工件trace_timeline、既有聚合追溯证据trace_summary。推荐的 worker 返回结构共八项建议原样采用Lane通道Hypothesis假设Evidence For支持证据Evidence Against / Gaps反驳证据 / 缺口Evidence Strength证据强度Critical Unknown关键未知Best Discriminating Probe最佳判别探针Confidence置信度十、Leader 综合契约十项产出与收敛检测最终的/trace答案必须是综合而非简单拼接。lead 需返回Observed Result观测结果Ranked Hypotheses排序后的假设Evidence Summary by Hypothesis按假设归类的证据摘要Evidence Against / Missing Evidence反驳证据 / 缺失证据Rebuttal Round答辩回合Convergence / Separation Notes收敛 / 分歧说明Most Likely Explanation最可能的解释Critical Unknown关键未知Recommended Discriminating Probe推荐的判别探针Additional Trace Lanes可选仅在不确定性仍高时追加追溯通道即使某一解释当前占据主导也必须保留一个排序短名单ranked shortlist。在收尾前必须执行答辩回合与收敛检测让最强的非领先通道对当前 leader 提出最佳反驳强制 leader用证据而非断言回应反驳若反驳实质性地削弱了 leader则重新排序整个表格若两个看似不同的假设实际收敛到同一底层机制就合并它们并明说合并原因若两个假设仍暗示不同的下一步探针即便听起来相似也应保持分离。不能因为多个 worker 用词相近就宣称收敛。收敛必须满足二选一要么是同一根因因果机制要么是相互独立的证据流指向同一解释。十一、显式降权让读者理解为什么一个解释胜出lead 必须显式说明某个假设为何下移。标准理由清单包括被更强证据反驳、缺少它所预测的观测、需要额外的临时ad hoc假设、比 leader 解释的事实更少、输掉了答辩回合、收敛进了一个更强的父级解释。这一点尤其重要因为/trace不只是输出一张最终表格而是要教会读者为什么一个解释排在另一个之上。十二、推荐 Lead 提示骨架与质量门槛如果从零开始组织一次/trace会话可直接套用这条团队编排提示骨架精确复述观测。生成 3 条刻意不同的假设。在 Claude 内置 team mode 中为每个假设创建一条 tracer 通道。对每条通道收集支持与反对证据、对证据强度排序并点名关键未知与最佳判别探针。如有用对领先者应用 systems、premortem、science 透镜。在排名前二的解释之间执行一轮答辩回合。返回排序解释表、收敛说明、关键未知以及唯一最佳判别探针。质量门槛好的/trace输出应具备有证据支撑、简明但严谨、对过早确定性保持怀疑、明确列出缺失证据、对下一步行动务实、明确说明弱解释为何被降权。十三、最终综合报告的标准形态可直接复用一份合格的/trace终稿可按以下模板组织含推荐表格结构Observed Result[实际发生了什么]Ranked HypothesesRankHypothesisConfidenceEvidence StrengthWhy it leads1...High / Medium / LowStrong / Moderate / Weak...Evidence Summary by HypothesisHypothesis 1: ...Hypothesis 2: ...Hypothesis 3: ...Evidence Against / Missing EvidenceHypothesis 1: ...Hypothesis 2: ...Hypothesis 3: ...Rebuttal Round对 leader 的最佳反驳...leader 守住 / 落败的原因...Convergence / Separation Notes...Most Likely Explanation[当前最佳解释]Critical Unknown[使不确定性保持敞开的那个单一缺失事实]Recommended Discriminating Probe[唯一推荐的下一步探针]Additional Trace Lanes[仅当不确定性仍高时填写]十四、源码级佐证tracer Agent 与技能注册trace不是凭空捏造的角色它在源码与技能注册表中均有对应实体技能实体skills/trace/SKILL.md 的 frontmatter 声明name: trace、argument-hint: observation to trace、agent: tracer、level: 2即该技能由traceragent 执行Agent 注册src/agents/tracer.ts 中tracerAgent被定义为category: advisor、cost: EXPENSIVE、model/defaultModel均为sonnet的 AgentConfig其提示词通过loadAgentPrompt(tracer)加载Agent 提示词本体agents/tracer.md 完整定义了 Tracer 的角色、成功标准、约束、证据强度层级、证伪规则、九步Tracing_ProtocolOBSERVE → FRAME → HYPOTHESIZE → GATHER EVIDENCE → APPLY LENSES → REBUT → RANK/CONVERGE → SYNTHESIZE → PROBE、工具使用策略与Final_Response_Contract——要求最后一条 assistant 消息必须承载完整的 Trace Report 结构化交付物禁止以 done、no further comments 之类的空话收尾。从源码结构可以推断触发边界src/agents/tracer.ts中的元数据给出其avoidWhen纯实现/修复任务请用 executor/debugger泛化摘要不需要因果分析单文件检索用 explore 即可这正对应 SKILL.md 开头不要坍缩成修复循环 / debugger 摘要的纪律——两层文档在此互相印证。十五、总结与适用前提OMC 的trace是一套把科学怀疑精神工程化的团队编排能力用commands/trace.md提供低成本的斜杠命令入口用skills/trace/SKILL.md承载完整协议再由traceragent默认 sonnet 模型、advisor 类目在多通道 team-mode 中执行取证。适用前提是问题是歧义且因果密集的为什么你能接受当前最佳解释 关键未知 判别探针这种留有余地而非一口咬定的输出形态。若问题是确定性编码任务或单文件定位按设计应改用 executor / explore 等其它通道而不是强行启动三条取证通道。想进一步验证这套协议可依次阅读 skills/trace/SKILL.md协议全文、agents/tracer.mdagent 人格与终稿契约、src/agents/tracer.ts注册元数据并对比 commands/verify.md同构的兼容命令示例。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考