A starter kit for writing your own agent loop skill.
An agent loop is a prompt that runs repeatedly, on a timer or self-paced, until a condition is met. A loop skill is the document that tells the agent how to behave inside that loop: what one iteration does, what state survives between iterations, and exactly when to stop. Good loop skills all share one skeleton; this repo gives you that skeleton so you only have to fill in your use case.
If you want ready-made loop skills instead of writing your own, see loop-skills, which ships five built from this same anatomy.
| File | What it is |
|---|---|
| OUTLINE.md | The anatomy of a loop skill, section by section, with guidance on what each section must answer and the mistakes each one prevents |
| TEMPLATE.md | A copy-paste SKILL.md skeleton with fill-in placeholders |
| example/certifying-backups/SKILL.md | A complete worked example written by filling in the template |
| CHECKLIST.md | A pre-flight checklist to run before trusting your skill in a real loop |
- Copy
TEMPLATE.mdtoskills/<your-skill-name>/SKILL.md. - Name the skill with a verb-first gerund that says what the loop does:
babysitting-ci,certifying-backups,sweeping-stale-branches. - Fill every
{{placeholder}}. The placeholders are the design decisions; if one is hard to fill, that is the design telling you something is unresolved. - Walk the worked example next to yours. Every section in the example earns its place; yours should too.
- Run the checklist. The paper test in it (handing scenarios to a fresh agent with only the skill text) finds the gaps you cannot see because you already know what you meant.
- One unit of work per iteration. Batching destroys the feedback signal that makes loops safe.
- Persist a ledger. Every iteration reads state from a file and appends what it did. A loop without memory retries failed strategies forever.
- Written exit conditions, checked first. Success, stall, regression, and budget exhaustion are defined before iteration one, and every iteration evaluates them before doing any work.
- Escalate instead of improvise. The loop's authority is whatever was agreed up front. Anything outside it gets reported, loudly, and the loop stops.
- Match the interval to the signal. Polling faster than the watched thing changes is pure waste.
Loops fail in stereotyped ways: they repeat work because nothing recorded what was tried, they grind past the point of diminishing returns because nobody wrote down when to stop, they batch five changes and cannot tell which one broke things, and they improvise actions nobody authorized at 2am. Every section in the skeleton exists to block one of those failure modes. That is also why the order matters: exit conditions are checked at the top of every iteration, not discovered at the bottom of a transcript.
MIT