该技能名称为 swarming-to-green，来源为 oaustegard/claude-skills。其核心循环为：已知失败状态 known.json 按签名聚类生成工作项，每个工作项由一个无头工作单元在独立工作树中处理；工作单元输出结果 JSON，经过串行门禁：在主分支应用补丁、执行兼容性检查、运行冒烟测试、目标测试和抽样测试，要求零回归且至少一个目标测试由失败转为通过；通过后快进主分支，再复查整个聚类，如此循环。
适用条件：测试命令能以 JSON 报告每个测试的状态；存在数百或更多失败测试；修复可通过重跑测试验证；任务将持续运行数小时，超出人工持续观察时长。若任务少于十个、仅需一次性无合并的扇出分发、需要固定多步骤流程、仅有少量失败测试或尚无机器可读测试输出，则资料建议改用其他方法或先编写测试运行器。
预检清单要求：确保有足够的失败测试供应、为执行真实计算的工作单元规划容器 CPU 上限、磁盘至少 10 GB 空闲、注意后台 Bash 任务 2 小时上限（建议使用 timeout: 7200000 与 --max-minutes 110）、协调器会话需指定低成本模型、联邦推送需允许相应命名空间前缀、忽略构建产物并固定语言版本等。
配置方面：需复制 assets/swarm.example.toml 至根目录 swarm.toml，填写 tests.command、paths.code/allowed/forbidden、queue.ladder、gate.always_suites/cheap_suites、gate.compat_command、worker.system_prompt、worker.repro_command 以及 worker.deny 等。工作单元提示词需保留结果 JSON 契约、禁止 git 提交、在仓库外使用临时目录、新增文件而非编辑共享列表、失败时回退并报告。
启动方式为一次前台背景 Bash 调用，运行 $SWARM run --concurrency 24 --max-usd 50 --max-minutes 110 --batch 6 --sample 80，并重定向日志。随后通过 send_later 每隔约 50 分钟自重新安排检查点，读取 status 中的 SIGNALS 信号并依据信号表处理，如循环未运行则重启、刷新中则等待、门禁积压则调整参数、CPU 受限则扩展节点、供应不足则加速构建测试套件等。
扩展方法：当单容器 CPU 成为瓶颈时，增加兄弟会话，各自负责一组测试套件，通过同一 git 仓库的分支和一个拥有主分支的枢纽连接，并对每个候选重新门禁。
模型选择：默认使用 Haiku 加退避阶梯；资料记录 2026-10-12 在 haiku-cc 工作负载上的测量数据：Haiku 5.5 默认努力解题率 76/80、8/8、19/20，每次解题成本约 $0.011–0.012；高努力为 8/8、20/20，成本约 $0.018–0.023；Sonnet 5.5 中等努力为 80/80、8/8、20/20，成本约 $0.075–0.087，约为 Haiku 的 7 倍。另一工作负载显示 Haiku 存在真实上限，例如匹配反编译任务中成本随努力等级上升而增加。
部分得分：当测试可测量地接近通过但不能完全通过，且失败之间存在依赖时，可设置 gate.partial_credit = "frac"，门禁在目标度量总和提升至少 gate.partial_min_gain 且零回归时合并候选。仅限通过/失败型套件不应启用。
资料还列出多种故障模式及对应信号与修复方法，例如磁盘满导致 worktree 添加失败、陈旧已知状态导致修复已通过测试、共享文件冲突主导拒绝、子代理后台任务随子代理消亡等。所有数值与经验均来自特定日期与特定工作负载，复用前需重新测量。