用途
fix-ci-failures 是一个面向 Git 仓库的 AI 技能，用于读取指定分支（输入中未指定时默认 main）最新一次已完成的 CI 失败运行，基于已有日志逐个分类失败作业，并修复其中被判定为“真实”的失败。它把 CI 视为只读证据：只读取已存在的运行日志，不触发、不重跑、不等待 CI。
主要能力
- 查找最新失败：执行 git fetch origin 后，按工作流分组，仅取该分支上每个工作流最新一次已完成运行，并筛选出 conclusion 为 failure、timed_out 或 startup_failure 的运行；再列出其中失败的作业及其日志中的首个真实错误。
- 分类每个失败：结合失败运行之后的提交记录（git log --oneline <headSha>..origin/B），将每个失败作业归为 LEGIT（真实失败）、STALE（后续提交已修复）、FLAKY（不稳定）、INFRA（基础设施问题）四类之一，并给出一行证据。当命令无法在本地运行（缺少服务或密钥）时，仅依据日志和代码分类并标注“未复现”。
- 修复真实失败：对每个 LEGIT 失败做最小改动，在本地反复运行失败命令直至通过，然后使用显式暂存提交（Conventional Commits，并指明作业名）。若工作区脏或分支已被其他 worktree 检出，会使用 git worktree add .claude/worktrees/ci-<branch> origin/B 创建独立工作区，并按照 laravel-herd-worktrees 的 Bootstrap a bare worktree 部分使其可运行，直到第 5 步才清理。
- 落地修复：默认使用 git push origin HEAD:B（不带 --force）推送；若被拒绝则先 fetch、变基到 origin/B、重跑每个已修复命令后再推送。若直接推送被禁止（分支保护或仓库规则），则推送 fix/ci-<branch> 分支并创建拉取请求。输入或对话中的用户指令（如“打开 PR”“不要推送”）优先于默认行为。推送后启动的新 CI 运行保持运行，不等待结果。
- 清理与报告：若第 3 步创建了 worktree 且提交已在 origin/B 或打开的拉取请求中，则直接移除该 worktree（不带 --force）；若 git 拒绝或提交保留在本地，则保留并询问一次是否可删除。最终为每个失败作业输出一行状态（✅ 已修复或已过时、⚠️ 不稳定/基础设施/未复现），并说明提交落地位置以及 worktree 的移除或保留情况。
使用方式
该技能以分支名为输入（可附加覆盖性指导文本），按照上述五个步骤顺序执行。它依赖 Git、GitHub CLI（gh）以及仓库中的 AGENTS.md / CLAUDE.md 规则来处理测试、lint、缓存清理和脏工作区。执行过程中会使用 gh run list、gh run view 等命令读取 CI 数据，使用 git log 判断后续提交是否已修复问题。
适用场景
- 分支或 main 上出现 CI 失败，需要快速定位真实原因并修复。
- 需要区分真实失败、已修复、不稳定和基础设施问题，避免在无关失败上浪费时间。
- 希望在本地验证修复，而不是反复重跑 CI 来等待结果。
限制
- 仅使用已存在的 CI 运行作为证据，不触发 gh run rerun、gh workflow run 或 gh run watch，不推送空提交或重试提交，也不等待运行结果。
- 当失败命令无法在本地运行时，只能基于日志和代码分类，并明确标注为未复现。
- 修复后的验证以本地失败命令运行通过为准，而非依赖 CI 结果。
- 推送是否成功取决于分支保护和仓库规则；被拒绝时需要按规则变基或改为创建拉取请求。
- 若保留本地 worktree 需要用户确认，删除时不使用 --force。