steinberger-loop-engineering
Design the system that prompts the coding agent instead of manually supplying every next prompt.
Choose work that deserves a loop
Start with one task that is:
- recurring rather than one-off;
- narrow enough to isolate and revert;
- driven by a discoverable queue, query, event, or schedule;
- verifiable through tests, builds, linters, policies, or another deterministic signal;
- inexpensive enough to survive failed attempts inside a fixed budget.
Do not begin with work whose acceptance depends mainly on taste, broad product judgment, or an agent grading its own prose. Run the first version in report-only mode when the failure surface is not yet understood.
Write the loop contract
Define these fields before the first iteration:
| Field | Required decision |
|---|---|
| Goal | The single recurring outcome the loop advances |
| Discovery | How one eligible work item is selected |
| Writable surface | Files, branch, worktree, or sandbox the agent may change |
| Acceptance | Commands and signals that prove the item is done |
| Budgets | Maximum iterations, elapsed time, tokens or spend, and retries |
| No-progress rule | The repeated state or failure that must halt the loop |
| Authority | Actions that still require a person, such as merge or release |
| Escalation | The evidence the loop must return when it cannot proceed |
Never allow the prompted agent to weaken the evaluator, broaden its own permissions, change its budgets, or redefine done.
Keep state outside the conversation
Persist enough state for a fresh agent to resume safely:
- goal and loop version;
- selected item and isolated workspace;
- attempt number, prompt, and accepted base revision;
- changed files and tool calls worth retaining;
- verification output and decision;
- total elapsed time and spend;
- remaining items, stopping reason, and escalation status.
Use an append-safe ledger or state file. Conversation history may be helpful context, but it is not the source of truth.
Run one iteration
For each iteration:
- Read the contract and durable state.
- Stop immediately if a completion, budget, no-progress, or escalation condition already holds.
- Discover or select one eligible item that is not already accepted or exhausted.
- Create or restore its isolated writable workspace.
- Prompt the agent with the goal, item, constraints, prior evidence, and exact verification commands.
- Inspect the resulting diff and run every required check outside the agent's claims.
- Accept and record the revision only when all acceptance checks pass.
- Otherwise revert, record the failure, and retry only when the contract still permits it.
- Persist the new state before selecting another item.
Do not stack multiple unverified items into one iteration. A loop becomes harder to trust when it cannot attribute a result to one bounded attempt.
Stop or escalate safely
Stop when the queue is complete, the scheduled unit of work succeeds, any budget is exhausted, repeated attempts make no progress, infrastructure becomes unreliable, or the next action exceeds authority.
Return:
- accepted items and revisions;
- exact checks and results;
- rejected attempts and useful failure evidence;
- time, iteration, and spend totals;
- the stopping reason;
- the smallest human decision needed next.
Keep merge, release, production mutation, destructive rollback, credential changes, and material scope expansion behind explicit human authority unless the user has separately authorized them.
Source attribution
Independently compiled by XSkills from Peter Steinberger's public post about designing loops that prompt coding agents. Steinberger did not author or review this skill. The shift from manually prompting coding agents to designing loops that prompt them comes from the source. The work-screening criteria, contract, durable-state schema, iteration protocol, verification boundary, budgets, and stopping rules are XSkills adaptations. Attribution does not imply endorsement.