关于 root-cause
Root Cause 是用于找出解释故障及其后续症状的最小因果机制的技能。它将诊断与修复分开，通过比较假设和寻找区分性证据，确认或限定因果结论。
主要功能
- 01记录故障细节与证据
- 02比较不同因果假设
- 03选择安全且有区分力的探查
- 04区分原因与背景因素
- 05报告诊断状态及后续行动
适用场景
- 01调查可复现的软件故障
- 02区分主要故障与重试噪声
- 03通过有限探查检验竞争性解释
- 04证据不完整时记录诊断结果
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/root-cause确认已加载。
附带文件agents/openai.yamlreferences/probe-commands.md
详细介绍
根因
找出能够解释已观察到的故障及其下游症状的最小因果机制或充分因果集合。诊断与分诊、审查和纠正交付分开进行。
将大量分析、研究和专家工作委派给子 Agent，并返回简明的发现和证据链接，以保持主上下文精简。
一个实用模型如下：
trigger + enabling conditions + propagation + missing containment/detection → observed failure
锁定故障
记录确切症状、预期行为、已知的首次触发条件、候选版本／修订或事件标识、环境／上下文、可复现性、证据、范围以及读取／探查权限。报告、堆栈跟踪、相关性、变更产物或时间顺序都是证据，而非原因。
尽可能安全地复现；否则，锁定一项等效的直接观测。将主要故障与次要错误、重试、补偿行为和恢复噪声区分开来。
竞争机制
编写一份简短的假设表。对每个假设，说明触发条件／机制、促成条件、传播过程、可解释的证据、一项可用于区分假设的观测，以及风险最小的探查方式。
当有界的源代码／历史记录／Git 证据能够区分假设时，请阅读探查命令。优先使用适合该领域的现有观测、测试、日志、跟踪、配置、历史记录、测量结果和可逆诊断。
选择下一项观测或干预时，应依据其区分当前有效假设的能力，而不是因为存在某种偏好的调试惯例。切实可行时，控制重要混杂因素。只有当探查确实能够区分机制时，才一次改变一个因素；如果可能存在交互作用或耦合条件，则应设计能揭示这些交互作用的观测／探查，而不要假装各因素彼此独立。
对于拟议的因果解释，应确认：
- 解释充分性——拟议的机制／集合能够解释或复现已观察到的故障和重要下游症状，且不存在尚未解决的因果缺口。
- 因素支持——每个声称的因果因素都有区分性证据，证明其在相关上下文中的作用。在可行时，移除／控制某个因素应能按预期改变结果或预测的中介变量。
- 条件性与替代路径——如果其他充分路径、交互作用或上下文也能导致同一故障，不要将某个因素说成全局必要条件。说明该因素对于此处观察到的路径是必要的、起促进作用的、起促成作用的、存在交互作用的，还是尚未确定。
缺乏区分性证据支持的因素属于上下文因素／促成因素／未确定因素，不能仅因其发生在故障之前，就认定为已确认的根因。
根据证据停止
只有在下一项安全观测可能实质性更新因果模型时才继续。当剩余假设无法区分、没有安全探查能改变诊断、无法获得所需环境／可观测性／权限，或故障无法复现且不存在等效直接证据时，停止。
不要在根因分析过程中尝试纠正。
结果
返回以下其中一项：
CONFIRMED_ROOT_CAUSE— 最小因果机制／集合及区分性证据足以解释已观察到的故障／路径；DIAGNOSED_BUT_UNPROVED— 最佳解释存在重要的因果／证据缺口；EVIDENCE_BLOCKED— 明确指出证据／环境／权限／可观测性缺口；NOT_REPRODUCED— 未观察到已锁定的故障，且不存在等效直接证据。
包括故障标识、最小机制／集合、各因素的证据及因果作用、重要的交互作用／替代充分路径、促成因素／上下文因素／未确定因素、传播／遏制情况、决定性证据、已证伪的替代解释、受影响边界、置信度限制以及最小且有用的下一步行动。
将必要的持久诊断记录保存在项目现有的目标位置。对选定的共享工作区使用 akosile，并按需使用 html-artifact。