Parallel CI Triage 是一个用于加速修复 GitHub Actions 失败的工作流技能。它的核心思路是：当 CI 出现多个失败任务时，不要串行地逐个排查，而是把失败任务（或独立的失败簇）拆分给多个并行子代理，每个子代理负责一个垂直切片——日志、根因、代码修复和本地验证。
用途
当 GitHub Actions 失败时，该技能用于获取失败任务的日志，并将每个失败任务分配给一个独立的子代理，让它们并行修复各自负责的那一部分问题。适用于多个 GitHub Actions 任务失败且失败看起来相互独立的情况，也适用于长工作流日志按任务拆分比顺序修复更容易的场景。
前置条件
需要安装并认证 GitHub CLI（gh），执行 gh auth login；或者使用 GitHub 网页界面/API 手动复制日志。同时需要对仓库有推送权限，以便推送修复并重新运行 CI。
工作流程
- 识别失败的运行
在仓库根目录执行：
gh run list --limit 5 gh run view <RUN_ID> --log-failed
或者打开 Actions 标签页，打开失败的 workflow run，记录哪些任务失败（不只是哪个步骤——按任务名称分组）。如果 gh 不可用，从 GitHub UI 下载日志并粘贴到对话中。
- 按任务（或失败簇）拆分
当任务测试不同内容时（例如 lint、test-node-18、e2e），每个失败任务分配一个子代理。当单个任务日志中出现多个不相关错误时，每个独立失败簇分配一个子代理——但优先采用一个任务一个代理，以避免同一文件中的编辑冲突。如果两个失败在同一文件中共享同一根因，则分配一个子代理同时修复两者。
- 启动并行子代理
对每个失败任务，在单条消息中启动一个 generalPurpose 子代理，使它们并发运行：
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:
- Infer the root cause from the log (command, stack trace, file:line).
- Open and edit only what this job requires.
- 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). - Report: what failed, what you changed, and confirmation that the local command passes.
在提示中包含确切的失败命令和错误行，以免子代理猜测。
- 合并与验证
收集每个子代理更改的文件。如果两个代理触及同一文件，手动解决重叠。尽可能在本地运行完整的 CI 等效命令：
Example: match your repo
npm run lint && npm test
使用约定式提交信息提交、推送，并重新检查工作流：
gh run watch
适用场景
多个 GitHub Actions 任务失败且失败看起来相互独立；长工作流日志按任务拆分比顺序修复更容易。
不适用场景
单个任务只有一个明确错误——在主代理中修复即可；纯粹是易波动的基础设施导致的失败——先重试或修复工作流配置。
注意事项
将日志粘贴到聊天中时，请对密钥进行脱敏。如果代理在共享文件上发生冲突，在并行处理之后按顺序合并。