swe-loop

SWE Loop

The execute stage of the prompt → plan → execute → debug pipeline: it turns a coding prompt into working, tested, well-organised code. It runs the plan-loop to get an executable tasks.json, then walks the tasks in dependency order. Each task is driven by two isolated subagents — an Engineer that writes the code and a QA that owns the tests and the quality bar — looping until the gate holds. The feedback signal is two-part, like the repo's other evaluator loops: an objective gate (the task's tests pass, the full regression suite stays green, and tools/quality_check.py reports no threshold violation) and a qualitative gate (QA's score against rubrics/quality-rubric.md — simplicity, readability, comment hygiene, organisation, style-match). One task is kept per outer step; one change is proposed per inner round, so every delta is attributable.

When to use

Use to implement a prompt in a real repository when you want the work decomposed, built, and tested rather than written in one shot — and when "done" means a downstream engineer would accept it: tests green and the code clean. Default to executing the plan-loop's tasks.json task by task; the escape hatch is a genuine plan defect, which becomes an open_question for the human rather than an improvised detour. Simpler is better — a change that adds complexity to pass a test will be sent back by QA. Not for planning alone (plan-loop) or for minimising a metric on a finished artifact (optimize-loop).

Setup

Resolve bindings interactively. If loop.run.yaml exists, load it, confirm the values in one line, and skip to the loop. Otherwise: on Claude Code (the AskUserQuestion tool is available) infer a likely value per binding and recommend it; on other hosts ask each as a quoted prompt. Then write loop.run.yaml (format: examples/run.example.yaml) and confirm before building anything.