Appearance
gh-fix-ci 解决的是 GitHub PR CI 失败后，日志散在各个检查项里、人工找报错费时间的问题。它用 gh CLI 拉取失败日志、提取关键片段，然后走 plan→approve→implement 的闭环修复流程。
GitHub PR CI 失败怎么快速定位：gh-fix-ci 技能怎么用
PR 开了，CI 红了。
打开 Actions 页面，一堆 job，点进去翻日志，找到报错位置，再判断怎么修——这套流程手动做一遍不难，但如果每天要处理好几个 PR，或者让 AI 代替你盯，就需要一个可以自动化的路径。
gh-fix-ci 就是为这个场景设计的。它依赖 GitHub 官方 CLI gh，把"找日志→摘要失败→制定计划→执行修复"做成一条工作流。
它解决什么问题
手动调试 GitHub CI 失败时，常见的摩擦点有三个：
日志量大，找报错靠滚动。Actions 日志往往几千行，真正的报错可能藏在 step 3 里某一条 assert，或者 TypeScript 编译输出的第 47 行。
检查项多，不知道从哪个开始。一个 PR 可能有 lint、type-check、unit test、e2e、build 几个 job，只看红色标记不知道哪个是根因。
修了一个，出来另一个。没有系统提取失败上下文，修复往往靠猜，改了一处触发了另一处。
gh-fix-ci 的内置脚本 inspect_pr_checks.py 会把所有失败检查项的日志片段提取出来，交给 AI 统一判断，再用 plan 技能起草修复方案，等你确认后才执行。
前提条件
需要 gh CLI 已安装并完成认证：
bash
gh auth login
gh auth status如果在沙箱环境里 gh auth status 被拦截，加 sandbox_permissions=require_escalated 重新运行。
基本用法
调用内置脚本检查当前分支的 PR：
bash
python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"加 --json 输出机器可读格式，适合 AI 接收：
bash
python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123" --json如果要控制日志片段长度（默认 100 行，每侧 20 行上下文）：
bash
python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40工作流程说明
脚本输出失败摘要后，工作流接着走：
- 列出失败检查项 — 名称、状态、对应的 Actions run URL。
- 提取日志片段 — 找报错行，附上下文。
- 汇总给 AI — 所有失败统一交给 AI 判断根因，不是一个 job 一个 job 单独看。
- 制定修复计划 — 用
plan技能起草，列出每处改动。 - 确认后执行 — 等你批准再改文件。
- 重新检查 — 建议跑
gh pr checks验证。
非 GitHub Actions 的检查项（比如 Buildkite、外部服务）不会自动处理，只报告 detailsUrl，标注为 out of scope。
容易用错的地方
不要用 --json 后直接让 AI 解析全量 JSON。日志字段很长，应该先让脚本提取片段，再传给 AI。inspect_pr_checks.py 默认已经做了截断，不需要手动处理。
Buildkite 或其他外部 CI 不在处理范围内。如果 PR checks 里有 Buildkite job 失败，这个技能只报告 URL，不会尝试拉日志。不要期望它修 Buildkite 的问题。
认证 scope 不够会导致日志拉不下来。gh auth status 里需要有 workflow 和 repo scope。如果日志拉取失败，先检查 scope，不要直接去手动找日志。
和其他技能的关系
这个技能依赖 plan 技能来做方案确认环节——不会直接修改文件，必须先出计划、等你批准。如果你的 AI 工具没有 plan 技能，可以改成让 AI 把修复方案写到 plan.md，你审完再让它执行。
gh-fix-ci 解决的是"找哪里失败、怎么修"这一步。找到问题后，如果需要系统性改写 CI 流程或质量门配置，可以配合 CI/CD 自动化技能 一起用。
你可能还需要
同类技能：
同工具场景：