parallel-ci-triage

并行 CI 故障排查

将失败的作业（或相互独立的故障簇）分配给并行子 Agent，加快修复 CI 的速度。每个子 Agent 负责一个垂直切片：该切片的日志、根因、代码修复和本地验证。

前提条件

• 已安装并完成身份验证的 GitHub CLI（gh）（gh auth login），或者使用 GitHub 网页界面 / API 手动复制日志。
• 拥有仓库的推送权限，以便推送修复并重新运行 CI。

工作流

1. 找出失败的运行

在仓库根目录运行：

gh run list --limit 5
gh run view <RUN_ID> --log-failed

或者打开 Actions 选项卡，打开失败的工作流运行记录，并记下失败的作业（而不只是失败的步骤——按作业名称分组）。

如果无法使用 gh，请从 GitHub 网页界面下载日志并粘贴到对话中。

2. 按作业（或故障簇）拆分

• 如果作业测试的内容不同（例如 lint、test-node-18、e2e），则每个失败的作业分配一个子 Agent。
• 如果单个作业的日志中包含多个互不相关的错误，则每个相互独立的故障簇分配一个子 Agent——但优先按每个作业分配一个 Agent，以避免对同一文件产生冲突修改。

如果两个故障在同一文件中有相同的根因，则指派一个子 Agent 同时修复这两个故障。

3. 启动并行子 Agent

针对每个失败的作业，在同一条消息中启动一个 generalPurpose 子 Agent，让它们并行运行：

Task: Fix CI failure for job "<JOB_NAME>"

Context:
- Workflow run: <RUN_URL or RUN_ID>
- Branch: <branch>
- Relevant log excerpt (failed steps only):
<paste gh run view --job <JOB_ID> --log or the failed section>

Instructions:
1. Infer the root cause from the log (command, stack trace, file:line).
2. Open and edit only what this job requires.
3. Run the same commands locally that failed in CI (or the narrowest equivalent, e.g. `npm run lint`, `pytest tests/foo`, `pnpm test --filter pkg`).
4. Report: what failed, what you changed, and confirmation that the local command passes.

提供失败的确切命令和错误行，避免子 Agent 猜测。

4. 合并并验证

• 收集每个子 Agent 修改过的文件。如果两个 Agent 修改了同一文件，手动解决冲突。

• 尽可能在本地运行完整的 CI 等效流程：

  # Example: match your repo
  npm run lint && npm test
  

• 使用符合 Conventional Commits 规范的消息提交、推送，并重新检查工作流：

  gh run watch
  

适用场景

• 多个 GitHub Actions 作业失败，且故障看起来互不相关。
• 与依次修复相比，将冗长的工作流日志按作业拆分更容易处理。

不适用场景

• 单个作业出现一个明确的错误——在主 Agent 中修复。
• 纯粹由不稳定的基础设施导致的故障——先重试或修复工作流配置。

注意事项

• 将日志粘贴到聊天中时，请隐去机密信息。
• 如果 Agent 修改了共享文件并产生冲突，请在并行处理完成后依次合并。