用途：闭合失败 CI 与通过 CI 之间的环节。技能会识别当前分支上最近一次失败的 GitHub Actions 运行，拉取日志，在代码中定位根因，本地修复，并在用户批准后提交并推送修复，让 CI 重新运行。触发场景包括用户说“修复 CI”“修复失败的工作流”“让构建变绿”等，或粘贴失败的 Actions 运行 URL 要求修复。
前置条件：需在 git 仓库内（git rev-parse --show-toplevel）；工作区应足够干净（git status --porcelain），若有未提交改动需展示给用户并询问是否继续。
工作流：第一步安全检查分支，获取当前分支 git rev-parse --abbrev-ref HEAD，若为 main、master 或 develop 则拒绝执行并停止，不提供强制选项。第二步查找最新失败运行：gh run list --branch "$BRANCH" --status failure --limit 1 --json databaseId,displayTitle,workflowName,headSha,conclusion,createdAt，取出 databaseId 作为 RUN_ID 并向用户展示一行摘要。第三步下载并扫描日志：gh run view "$RUN_ID" --log，优先使用 --log-failed 只返回失败步骤日志，搜索 FAIL、error:、AssertionError、Traceback、npm ERR! 等标记，判断失败任务、类别与具体信号。第四步在代码中定位问题，将日志信号映射回仓库；若日志指向本地不存在的文件或本地提交与 CI 运行的 headSha 不一致需告知用户。第五步应用聚焦修复，做最小改动，不重排、重命名或重构无关代码，不为消除失败而删除断言、加空泛 try/except、全局禁用 lint 规则或跳过测试，除非用户明确要求。第六步在可行时本地验证，如运行具体测试、npx tsc --noEmit、cargo check、mypy、go build ./... 或相同 linter。第七步总结并请求批准，列出失败运行、根因、改动文件与本地验证结果，等待用户明确肯定答复。第八步提交并推送：git add -- <改动文件>、git commit -m "<生成消息>"、git push，不使用 git add -A、不 amend、不强制推送、不使用 --no-verify；提交信息采用 Conventional Commits 风格并说明修复内容，推送后报告并提示可用 gh run watch 查看重跑。
限制：禁止在 main、master、develop 上运行；未经用户明确批准不得推送；不得强制推送、修改已发布提交或跳过钩子；不得以删除断言、空泛捕获、跳过测试、禁用 lint 规则等方式掩盖失败；不得在同一提交中包含与 CI 修复无关的改动；对基础设施抖动不得编造修复，应建议 gh run rerun；诊断不明确时应暂停询问用户。若 gh 未安装，引导用户访问 https://cli.github.com。