看到 PR 变红之后，gh-fix-ci 会把检查状态、具体运行日志和相关代码接起来。它的边界是 GitHub Actions：先找真正失败的步骤和日志片段，再形成修复计划；外部 CI 服务通常只保留详情链接，不能假装已经读取其内部日志。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer gh-fix-ci
- 目标仓库的本地工作副本与准确 PR 链接
- 已认证且能读取检查和运行日志的 GitHub CLI
- 本地可执行项目相关测试的环境
先用 gh auth status 确认账号，再用 gh pr checks 查看当前分支 PR；也可以指定 PR 号码或链接。检查仍处于 pending 时，并不等于已经失败。 [4]
第一次怎么用
在目标仓库里，先把诊断范围限定到当前 PR：
$gh-fix-ci
用当前分支 PR 的 GitHub Actions 失败检查定位问题。先给出失败任务、关键日志片段、对应代码与最小修复计划，等我确认后修改。区分代码错误、环境缺失和外部 CI；不要为了变绿删除测试或绕过检查。
接下来怎样推进
-
找到失败的运行。 核对 PR 与提交，查看失败检查的详情链接和日志；不要用旧提交的失败解释最新代码。
-
确定修复范围。 把首个有因果意义的错误与后续连锁错误分开，提出影响最小的改动和验证方法。
-
修改并复查。 计划确认后实施，先跑相关本地检查，再看相应提交的远程检查结果；报告没有验证到的部分。
从失败检查走到可验证的修复
先固定 PR 编号和失败的提交 SHA，再读取该提交的 check 列表。gh pr checks <PR编号> 能帮你找出失败项；若 GitHub Actions 页面有多个作业，应追到具体作业日志。把第一个真正失败的命令与它之后的连锁报错分开。一个常见例子是安装依赖失败导致后面测试全部未执行，不能把每个测试都当作独立缺陷。
让 Codex 的计划至少回答：错误发生在安装、构建、测试还是部署；是代码回归还是环境差异；最小修复涉及哪些文件；本地可以运行哪条同等检查。若失败检查来自第三方服务，而 GitHub Actions 日志并不可读，只保留检查链接和待查范围，不虚构诊断。
为什么本地通过仍未结束
修复后先运行相关命令，再确认锁文件、运行时版本、工作目录和必要环境变量与 CI 一致。远程检查必须对应包含修复的新提交；旧提交变绿或本地测试通过，都不能证明新 PR 已通过。若新运行仍在排队，报告为“待完成”，并附上实际观察到的日志与未验证范围。
另一个场景：只在某个运行时版本失败
假设 PR 的测试矩阵里 Node 20 通过、Node 18 失败。可以要求：“先确认两个作业运行的是同一提交；比较失败命令、依赖安装和错误栈，只判断差异是否与运行时版本有关。若证据不足，列出下一步该看的日志，不先修改代码。” 安装后的 Skill 附带 scripts/inspect_pr_checks.py，可用 python "<Skill目录>/scripts/inspect_pr_checks.py" --repo "." --pr "123" --json 取得机器可读检查摘要；<Skill目录> 和 123 需换成实际路径与 PR 编号。验收时要看到具体失败作业与日志，而不只是“CI 红了”。
交付后先检查什么
交付应说明哪个检查失败、为何失败、改了什么，以及哪些验证实际通过。远程检查尚未结束时应写“等待结果”；本地测试通过不能直接等同于远程 workflow 成功。
从失败检查读到关键日志
排查时先让 Agent 列出失败的检查名称、运行 ID 和关键报错，再决定是否读取完整日志。辅助脚本能提炼错误附近的片段；如果检查刚结束却显示日志待生成，可稍后重查或定位到具体 job。若 detailsUrl 指向 Buildkite、Jenkins 等外部 CI，这套 GitHub Actions 日志流程不一定能继续，应打开对应平台的原始日志。
常见卡点
日志已失效或不可读。 提供可访问的运行链接或保留的日志，检查账号权限；拿不到日志时先说明诊断范围。
本地正常、CI 失败。 比较依赖锁文件、运行时版本、环境变量和工作目录，再用同样条件复现。
失败来自外部平台。 把详情链接交给对应工具或人工排查，不将其描述为已修复的 Actions 问题。