CI 失败 PR 修复

要解决什么问题

PR 合并前被 CI 检查卡住是常态：本地跑得通，流水线却红了。排查这些失败通常要手动翻日志、定位根因、改代码、重新推送，一轮下来十几分钟到几小时不等，且这类排查高度重复。当失败原因明确、修复方案机械可执行时，这件事完全可以交给 agent 做。

工作方式

该技能基于 GitHub Next 的 pr-fix 工作流，在 PR 被失败的检查阻塞且修复方案机器可判定时介入：

• 读取失败上下文：通过 gh 与 gh-aw 扩展获取 CI 运行状态、日志和错误输出。
• 追踪根因：分析错误信息与失败栈，区分真实代码缺陷与偶发环境问题。
• 应用针对性修复：只在 PR 分支上做最小改动，不夹带无关重构。
• 留下可审查的历史：修复以独立的 commit 推送到原分支，reviewer 可以像对待人工提交一样逐条 diff 审查。

适用边界

• 仅适合机器可做的修复，例如修类型错误、补依赖声明、改配置文件、修正 lint 违规；架构级问题仍需人工介入。
• 依赖环境装有 GitHub CLI 和 gh-aw 扩展，未配置则无法运行。
• 修复提交在 PR 分支上进行，不会绕过 review 流程——它生成的是需要人来确认的代码变更，而非自动合并。