Menu
证据驱动的追踪通道，在 Kimi 的 Agent 工具中编排互相竞争的 tracer 假设
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
oh-my-kimi 的目录入口，包含面向 Kimi CLI 的 agent、skill、hook 与 MCP 套件，衍生自 oh-my-* 谱系。
面向密钥、注入、authz/authn、不安全 IO、依赖与数据外泄风险的安全评审
LLM Wiki —— 跨会话持续累积的 markdown 知识库（Karpathy 模型）
面向作家的 agentic 记忆系统 —— 跟踪人物、关系、场景与主题
跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 'analyze'、'investigate'、'why does'、'what's causing'，或在提任何改动方案之前需要跨文件的有据解释时使用。
取消任何活跃的 oh-my-kimi 模式（autopilot、ralph、ultrawork、ecomode、ultraqa、swarm、ultrapilot、pipeline、team）
| name | trace |
| description | 证据驱动的追踪通道，在 Kimi 的 Agent 工具中编排互相竞争的 tracer 假设 |
| argument-hint | <observation to trace> |
| agent | tracer |
| level | 2 |
当问题是模糊的、因果的、证据密集的，目标是解释为什么会发生某个观察到的结果，而不是直接动手修代码或重写代码时，使用本 skill。
这是建在内置 tracer agent 之上的编排层。目标是让 tracing 像一个可复用的 oh-my-kimi 操作通道一样：复述观察、生成互相竞争的解释、并行收集证据、对解释排序、提出能最快折叠不确定性的下一步探针。
当问题是以下情形时，使用 /oh-my-kimi:trace：
例子：
始终保留下面这些区分：
不要塌缩成：
把证据按层级看待，而不是平的。
从最强到最弱：
当存在更强的反证时，对主要依赖低层证据的假设显式降级。
每一次严肃的 /trace 都必须尝试证伪自己最偏爱的解释。
对每个头部假设：
在以下情况下对一个假设降级：
/trace 使用 Kimi 的 Agent 工具。
Lead 应当：
重要：worker 应当追求有意不同的解释，而不是同一个解释的并行复制。
除非提示明显暗示更好的划分，默认使用这 3 条通道：
对通道 3，跨实体差异在升级前需要做一次前提审计：枚举实体维度，检查零行或不匹配的结果是源于把一个键应用到多个实体上，还是源于真正的系统缺陷；结果可能是验证方法本身的缺陷。
这些默认值刻意宽，让第一刀切片能跨 bug、性能、架构与实验追踪都适用。
在初轮证据采集之后，相关时用下面的透镜对领先者施压：
这些透镜不是凑数。只在它们可能挖出被忽略的解释、隐藏依赖或弱推断时使用。
每个 worker 应当是一条 tracer 通道的拥有者，而不是通用 executor。
每个 worker 必须：
有用的证据来源包括：
trace_timeline 拿到的已有 trace 工件trace_summary 拿到的已有聚合 trace 证据建议的 worker 返回结构：
最终的 /trace 回答应当是综合，而不是堆叠。
返回：
即使当前已经有一个主导解释，仍保留一份排序的候选清单。
在收尾前：
不要因为多个 worker 用了相似语言就声称汇聚。汇聚需要要么：
Lead 应当显式说明为什么一个假设下移：
这很重要，因为 /trace 应当教读者为什么一个解释胜过另一个，而不是只甩出一张最终表。
使用面向团队编排的提示，大致如下：
好的 /trace 输出是：
[发生了什么]
| 排名 | 假设 | 置信度 | 证据强度 | 为什么领先 |
|---|---|---|---|---|
| 1 | ... | 高 / 中 / 低 | 强 / 中 / 弱 | ... |
[当前最佳解释]
[让不确定性悬而未决的单一缺失事实]
[单一下一步探针]
[仅当不确定性仍然很高时]