用途：swe-loop 是 prompt→plan→execute→debug 流水线的执行阶段，把编码提示（功能、缺陷修复或重构）实现为可运行、经测试、组织良好的代码。它先运行 plan-loop 得到可执行的 tasks.json，再按依赖顺序逐项执行。
主要能力：每个任务由两个隔离子代理驱动——Engineer 写代码，QA 负责测试与质量标准，循环直到门槛成立。反馈信号分两部分：客观门槛（任务测试通过、完整回归套件保持绿色、tools/quality_check.py 无阈值违规）与定性门槛（QA 按 rubrics/quality-rubric.md 评分：简洁性、可读性、注释卫生、组织、风格匹配）。外层每步保留一个任务，内层每轮只提出一个变更，保证每次差异可归因。
使用方式：交互式解析绑定；若存在 loop.run.yaml 则加载并确认后进入循环，否则推断或询问各绑定值并写入 loop.run.yaml。绑定包括 prompt、repo、tasks_file、test_command、sandbox_root、iter_strategy、pr_mode、base_branch、task_budget、patience、quality_thresholds。客观质量门槛命令为：python3 <skill_dir>/tools/quality_check.py <changed_files> --max-comment-block 8 --max-comment-line-len 100 --max-func-loc 60 --max-nesting 4 --max-file-loc 400。
流程：Phase 0 规划并记录回归基线；每个任务先检查点，再进入 Engineer⇄QA 内层循环，通过则保留并提交，否则按 verdict.fixes 精修；达到预算或耐心值仍无改善则回退并标记 blocked。PR 模式分 stacked（默认，每任务一个 PR）、single（整轮一个 PR）、none（仅本地提交）。
适用场景：在真实仓库中实现提示，希望工作被分解、构建并测试，而非一次性写出；完成标准是下游工程师可接受——测试绿色且代码整洁。
限制：不用于单独规划（plan-loop）或对已完成产物做指标最小化（optimize-loop）。写入范围必须分离：Engineer 只改源码，QA 只改测试。测试只能加强，不得削弱、跳过或删除。不得为绕过工作而修改计划。任务未保留前不得在其上继续构建。需要 gh 已认证且有远程仓库才能开 PR，否则回退为 none。若任务持续以相同方式失败，应让 Engineer 换一种方法而非继续精修死路。