技能介绍

当 CI 挂掉时，你实际在做什么

一个 on: push 的工作流开始红了。你打开 Actions 页面，点进最后一次运行，翻到日志末尾。但如果同一个 job 已经连续失败三天，而且每次都像是「新」原因——先是超时，然后依赖源不可用，再是证书过期——你面对的其实不是一次失败，而是一个反复出现的模式，只是没人把三次运行摆到一起看。

手工排查的成本就在这里：你要在多个 run 之间来回切换，复制日志片段，判断哪条是新出现的，最后在 issue 里写一句「可能需要重试」。这句话对下一个值班的人几乎没有帮助。

这个技能怎么工作

它的核心是一个 CI Doctor workflow，把 agent 放在 CI failure investigator 的位置上：

监视运行记录：关注仓库里的 GitHub Actions runs，识别失败或异常的运行。
拉取失败日志：从失败的 run 中取出日志，保留可以定位的证据（job 名、step、报错行），而不是只留一行 summary。
追踪重复模式：把多次失败放在一起比对，找出反复出现的信号——同一个 step 超时、同一个第三方源不可用、同一个环境变量缺失。
开出调查 issue：整理成带具体下一步动作的 issue，并附上 run ID 链接，让别人可以直接点进去核对。

Reporting 部分还规定了运行信息的呈现方式，要求带上可点击的 run ID 链接，这样 issue 里的每一条结论都能溯源到具体的一次运行。

边界在哪

它不是 gh-aw 的功能清单页。这个技能的用途是调查失败，不是把 GitHub Agentic Workflows 当成产品来介绍。

要跑起来，环境里需要这些：GitHub、GitHub Actions、gh CLI、GitHub Agentic Workflows 扩展，以及 gh-aw 支持的 AI provider token。日志抓取和分析都在仓库的 CI 上下文里完成，所以能拿到什么，取决于 run 本身留下了什么。

还有一点要说清楚：它产出的是调查结果和下一步建议，不保证修复一定成功。当失败原因落在外部依赖上——registry、网络、轮换过的密钥——issue 里的 action item 仍然需要人来确认和执行。