Loop Engineering Checklist
A one-off prompt becomes a safe loop when the source, handoff, checker, memory, stop rule, and approval point are clear. Run through these checks before you let an agent iterate.
A completed example
A CI repair loop receives one failing TypeScript test. It may edit the affected parser in an isolated worktree, run the focused test and the full project checks, and prepare a reviewable diff. It may not merge the pull request.
The starting failure is captured before any edit
The run note records the failing test name, command, and original assertion output.
The checker is independent from the maker
A separate read-only review checks the final diff, test integrity, and changed-file list.
The loop stops when the same blocker repeats
Three attempts produce the same parse error with no new evidence, so the run reaches its pre-set stop rule.
Irreversible actions require a person
The loop can prepare a branch but has no authority to merge or deploy it.
Decision
Stop the current run because the repeated-failure limit was reached. Passing the other controls does not override a hard stop condition.
Next action
Preserve the worktree and failure evidence, report the smallest unresolved parser assumption, and ask a person whether the expected syntax or implementation should change.
Why this checklist matters
A loop can look disciplined because it has a prompt and a test, while still lacking an owner, a failure exit, or a safe handoff. This checklist covers the whole operating cycle so that repeated work does not quietly become repeated risk.
How to use this checklist
Decision after the check
Run manually when only low-risk gaps remain and a person is watching. Do not schedule the loop while validation, budget, stop rules, or approval ownership are missing.