用途
ci-debug 用于诊断失败的 CI 运行。它针对一个包含 11 种模式的 playbook 对失败进行分类，引用相关记忆条目，并提出精确的修复命令，但绝不自动应用修复。该技能是对 /insights 反复出现的 CI 调试模式的直接回应：约 3 周内约 12 个会话在做同样的分类工作，此技能将 11 种模式编码，使这一过程变成查表。
主要能力
- 支持三种输入方式：PR 编号（如 /ci-debug 822）、运行 URL、作业 URL。
- 解析失败的作业：从 PR 编号使用 gh pr checks 筛选 fail 桶；从运行 URL 使用 gh api 获取失败作业及其失败步骤。若多个作业失败，选择持续时间最短的，因为根因通常是第一个失败，后续作业是级联。
- 抓取失败日志：使用 gh api 获取作业日志，并用 grep 过滤错误、失败、冲突、退出码等关键词，捕获第一个不同的错误消息。
- 按顺序匹配 11 种模式，首个匹配即生效。模式包括：1) 计费阻断；2) 根锁文件漂移；3) uv.lock 漂移；4) ci-shared.yml 缺少权限；5) YAML 内嵌 Python；6) actionlint shellcheck 误报；7) macOS BSD date %3N；8) Runner pnpm Rosetta 架构漂移；9) 浅克隆误判分歧；10) 发布运行被取消；11) Vercel 状态孤立（路径跳过）。
- 对匹配的模式输出报告，包含失败作业、失败步骤、错误摘录、分类、记忆引用和拟议修复命令，并明确询问是否应用。
- 对未匹配的失败输出 NOVEL 报告，展示原始证据，建议用户识别根因后将其加入 playbook。
使用方式
用户通过以下方式之一调用：PR 编号、运行 URL 或作业 URL。技能执行步骤：解析失败作业、抓取失败日志、按 playbook 分类、报告。报告格式固定，包含分类、引用和拟议修复命令。用户需回复“go”才会应用修复。
无头调用（权限模式）：/ci-debug 需要 Bash 工具访问权限。在无头 claude -p 运行中，使用 --permission-mode acceptEdits；绝不要使用 dontAsk，因为它会静默拒绝需要权限的工具。claude -p 将认证/权限失败报告为 stdout 上的 JSON，而非 stderr，失败时需捕获并记录两个流。
适用场景
- 特定的 CI 运行、作业或 PR 检查失败，用户希望获得诊断。
- 用户粘贴运行 URL 或询问“PR #N 失败了——为什么？”。
限制
- 不适用于广泛的“整个组织哪些失败了？”——应使用 /status。
- 不适用于应用级测试失败（playbook 是 CI 基础设施特定的，例如不是 pytest 失败）。
- 在阅读实际日志之前不要推测。
- 关键护栏：绝不自动应用修复；绝不跳过抓取日志步骤；引用确切的记忆条目；每个分类必须有可证伪的证据。
- 如果日志已消失（超过 90 天，运行被删除），应说明并停止。
添加模式
当出现新的 CI 失败时，向表格添加一行：签名（足够独特的日志行/元数据组合，必须可证伪）、记忆引用（记录完整事件报告的记忆文件名）、拟议修复（确切的命令行，无散文）。提交 SKILL.md 更改，ci-sentinel 工作流会在下次扫描时自动获取新模式。
相关技能
- 组合：ci-sentinel（针对开放红色 PR 的自主每小时触发）。
- 反模式：手动重新运行 gh pr checks 并在 N 个仓库中肉眼查看日志。
- 上游：/status 用于组织范围的扫描，显示哪些 PR 是红色的；此技能回答为什么。