用途：为 CI 失败提供结构化调试工作流。它不采用“看报错→猜修复→推送→等待→重复”的方式，而是强制遵循：分析日志→定位根因→本地复现→修复→本地验证→一次性推送。适用于 PR 或 push 时 CI 检查失败、用户说“CI is red”或“fix the pipeline”、以及 pr-ready 检测到 CI 失败之后。不适用于编写新的 CI 流水线，那应使用 ci-setup。
执行模型：始终由主智能体直接运行该技能，因为 CI 修复需要终端访问（本地跑测试）、文件编辑和迭代调试。Token 预算约 3-8k，视失败复杂度而定。
工作流：第一步获取 CI 状态，可用 gh run list --limit 5、gh run view <run-id> --log-failed，用户提供 run ID 或 URL 时直接使用。第二步将失败归类：Lint/Format（eslint、ruff、prettier、markdownlint）、类型检查（tsc、mypy、pyright）、测试失败（pytest、jest、vitest）、构建失败（编译错误、缺依赖）、配置错误（YAML 语法、无效 action 版本）、环境问题（缺 secrets、runner 错误、超时）、依赖问题（lockfile 冲突、版本不匹配）。第三步提取根因，读取失败 job 日志，确认哪个 job 和步骤失败、实际错误信息、文件与行号，以及是否为偶发失败（对比上次运行是否通过），可用 gh run view <run-id> --log-failed 2>&1 | tail -50。第四步本地复现：lint 跑同一 linter，测试跑特定失败测试，构建跑构建命令，类型检查跑类型检查器；若本地无法复现，说明问题与环境相关（secrets、runner 版本、缓存）。第五步应用最小修复：每个失败类别单独修，不要混修；改动尽可能小，不要在修 CI 时重构；修复后本地跑同一检查。第六步本地验证：运行与 CI 完全相同的命令，例如 npm run lint（或 ruff check .）、npm test（或 pytest）、npm run build（或 python -m build）、npm run typecheck（或 mypy .），全部通过后才能推送。第七步推送并监控：git add -A、git commit -m "fix: <category> — <what was wrong>"、git push，然后用 gh run watch 监控。
规则：先读日志，绝不猜测 CI 修复，始终读取真实错误输出；本地复现，修复前先验证失败，盲目推送浪费 CI 分钟和时间；一次一个类别，lint 问题与测试失败分开修复，让修复提交清晰可回滚；最小修复，修 CI 时不要重构、优化或“改进”代码；推送前验证，本地跑相同检查，绝不推送后祈祷；不使用内置 explore 子代理类型。