用途：当 GitHub Actions 出现多个相互独立的失败作业时，把每个失败作业（或独立失败簇）拆给一个子代理并行处理，加快修复 CI 的速度。每个子代理负责一个纵向切片：日志、根因、代码修复和本地验证。
前提条件：已安装并认证 GitHub CLI（gh auth login），或改用 GitHub 网页界面/API 手动复制日志；对仓库有推送权限，以便推送修复并重跑 CI。
使用方式：先用 gh run list --limit 5 和 gh run view <RUN_ID> --log-failed 定位失败运行，或从 Actions 页面按作业名记录失败作业。若 gh 不可用，可从 GitHub UI 下载日志粘贴到对话中。然后按作业拆分：不同作业测试不同内容时，每个失败作业一个子代理；单个作业含多个无关错误时，可按独立失败簇拆分，但优先一作业一代理以避免同文件冲突；若两个失败共享同一文件中的同一根因，则交给一个子代理一起修。启动时在单条消息中为每个失败作业启动 generalPurpose 子代理以并发运行，任务中需包含作业名、运行 URL 或 ID、分支、失败步骤日志摘录，并要求推断根因、只改该作业所需内容、本地运行与 CI 相同的失败命令（如 npm run lint、pytest tests/foo、pnpm test --filter pkg），最后报告失败原因、改动和本地通过确认。合并时收集各子代理改动文件，手动解决重叠；尽量本地运行完整 CI 等价命令（如 npm run lint && npm test），用约定式提交信息提交、推送，再用 gh run watch 复查工作流。
适用场景：多个 GitHub Actions 作业失败且看起来相互独立；长工作流日志按作业拆分比顺序修复更高效。
限制与注意：单个作业只有一个明确错误时，直接在主代理中修复；纯属基础设施抖动导致的失败，应先重试或修工作流配置。粘贴日志到对话时需脱敏密钥；若代理在共享文件上冲突，应在并行阶段后顺序合并。