run-loop
Skill5 starsChanged 5 months agoMITView on GitHub
Chain-aware unattended loop driver for the Agentic Engineering suite. Use ONLY when the user explicitly asks to run multiple implementation-plan tasks unattended — "run the loop", "run-loop M2", "work through milestone M2 without stopping", "run the next N tasks", "keep going until blocked". Never self-trigger for a single task or an ordinary coding request. Branch → build → draft PR → dispatch the verifier → checkpoint → repeat, until the target is reached, the circuit breaker trips (3 FAILs on one task), or the task budget is spent. Never merges.
In this repository11 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
No target given → ask for one before looping.
- Distinctive: line 43
No unblocked tasks remain
- Distinctive: line 54
Never weaken a done condition to make the loop converge — that is escalation, not negotiation.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Run Loop
Drive the documentation chain end-to-end without per-task prompting. You are the producer; verification is dispatched to a fresh-context verifier, never self-graded; merging is never yours.
Target
Parse the user's instruction:
- A milestone (e.g.
M2) → run its tasks in dependency order until the milestone is done - A task ID (e.g.
M2-T3) → run exactly that task until-blocked→ keep taking the next unblocked task until nothing is runnablemax-tasks=N→ cap on tasks this run (default 5; the user must raise it explicitly for longer runs)
No target given → ask for one before looping. Do not guess.
Preconditions — abort with a clear message if unmet
AGENTS.md,docs/plans/implementation-plan.md, anddocs/status.mdexist. If not, stop and route to theusing-agentic-engineeringrouter — a loop without the chain is just unsupervised guessing.- Working tree is clean and
mainis up to date. - The In-Flight Checkpoint in
docs/status.mdisnone. If it isn't, the previous session crashed — run the status-tracker recovery protocol first, then loop.
Loop body — per task
- Pick the next unblocked task for the target (STATUS module table + plan dependency order).
- Branch per the git-workflow skill:
task/<task-id>-<slug>from up-to-date main. - Build to the spec. Producer self-check: lint clean, full suite passing, test ratchet holds.
- Checkpoint
docs/status.md: In-Flight Checkpoint updated, module table → 🔍. - Ship: push the branch, open a draft PR whose description carries the task reference and done condition (git-workflow PR protocol).
- Verify: dispatch a fresh-context verifier with the task ID, branch name, and done-condition location — the bundled
verifiersub-agent where the harness supports it, otherwise any fresh-context mechanism per the independent-verification skill (a fresh session or separate agent). Never verify your own work in this conversation. - On PASS: STATUS module table → ✅ with verdict + PR references; flip the PR from draft to ready; proceed to the next task.
- On FAIL: fix on the same branch (each round noted in the PR), re-dispatch the verifier. Three consecutive FAILs on one task stops the entire loop — escalate to the user with the verdict history.
Stop conditions — whichever comes first
- Target reached
- Circuit breaker: 3 consecutive FAILs on one task
max-tasksbudget spent- No unblocked tasks remain
- A precondition broke mid-run (e.g. the tree turned dirty outside your work)
Wind-down — always, even on abort
- Finalize
docs/status.md: module table, header block, handoff log entry; In-Flight Checkpoint reset tonone. - Report: tasks completed (with PR + verdict references), tasks failed (with the last verdict), tasks remaining, and exactly where and why the loop stopped.
Hard rules
- Never merge. The loop's output is a queue of verified draft→ready PRs. Merging belongs to the human gate, after a human has read each diff.
- Never weaken a done condition to make the loop converge — that is escalation, not negotiation.
- Checkpoint before every risky step. A crash must cost at most one task.
- AGENTS.md boundaries apply to every iteration — the loop is not a license to skip the chain.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

