Loop Operator Kit for Claude Code
Seven work templates that stop a loop from running forever, dying with the laptop, picking the wrong model, touching production, or declaring done too early.
What you get
A budget card, a runtime map, a model table, safety layers, a completion contract, a Sentry loop, and a fit matrix, all ready to copy
Who it is for
For developers, founders, and agent operators who already let Claude Code or Codex work unattended and want to turn a successful experiment into a system they can trust.
1. Budget: a card before the run
If a small task drags on for hours, start here. Problem somewhere else? Jump straight to Runtime, Model, Safety, Completion, Sentry, or Fit. If a loop can retry, it needs to know in advance how many times it is allowed to fail.
- Goal: what needs to be true at the end.
- Time: how many minutes or hours it is allowed to work.
- Attempts: how many rounds of fixing and checking are allowed.
- Cost: a token or money ceiling that matches the value of the task.
- Checkpoint: after every round, what changed and what still fails.
- Escalation: what the agent returns when the budget runs out.
LOOP BUDGET
Goal:
[one outcome you can check]
Limits:
- max_runtime_minutes: [number]
- max_attempts: [number]
- max_cost: [amount or tokens]
After every attempt, record:
- what changed
- which check passed
- which check failed
Stop and escalate when any limit is reached.
Return the last evidence and the smallest decision I need to make.2. Runtime: where the loop should live
Do not pick the runtime that happens to be convenient right now. Pick by availability, context, and file access. A great loop in the wrong place just stops.
- Cloud Routines: when the task needs to keep going even with the laptop closed.
- /loop inside an open session: when the task needs the live context of the conversation.
- Desktop scheduled tasks: when the task needs local files and tools and the computer stays awake.
- Files that were never pushed to a shared source do not exist as far as a cloud agent is concerned.
- Before choosing, answer two questions: what the process needs access to, and how long it must stay alive.
RUNTIME DECISION
Must continue while laptop is closed?
-> Cloud routine
Needs the current conversation context?
-> /loop inside the open session
Needs local-only files or tools?
-> Desktop scheduled task
Needs more than one of these?
-> Move the missing context or files to a shared source,
or split the workflow at an explicit handoff.3. Model: calculate the cost of a mistake
A cheap model that returns a wrong answer can cost more than a strong one. First build a reliable baseline, then cut cost only on the stages that do not hurt the result.
- Model cost: how much every run costs.
- Mistake cost: fixing, rerunning, team time, and damage to a customer.
- Verification cost: how expensive it is to prove the result is correct.
- Start with the model that gives a reliable result on a small sample.
- Switch to a cheaper model only if the same check stays green.
- Keep a strong model for planning, judgment, edge cases, and risky decisions.
MODEL ROUTING CARD
Task: [the stage in the loop]
Failure impact: low / medium / high
Verification cost: low / medium / high
Baseline model: [the reliable model]
Cheaper candidate: [model to test]
Run both on the same sample.
Keep the cheaper model only if:
1. the required checks still pass,
2. retries do not increase,
3. human repair time does not increase.4. Safety: an instruction is not a hard boundary
A CLAUDE.md file tells the agent how to work. An action it must not perform also needs an enforcement mechanism before the tool runs, not just a sentence hoping the model complies.
- CLAUDE.md: defines behavior, process, and checks.
- permissions.deny: blocks tool calls that match a rule.
- PreToolUse: checks a command before it runs and can reject it.
- Access to production, money, customers, and deletion stays behind human approval.
- bypassPermissions only fits an isolated environment with no access to a real asset.
- Automatic safety checks help, but they are not a security contract.
SAFETY LAYERS
Instruction layer:
- Write the expected behavior in CLAUDE.md.
Enforcement layer:
- Deny dangerous tool patterns.
- Add a PreToolUse check before production commands.
Environment layer:
- Use an isolated worktree or sandbox.
- Keep production credentials unavailable.
Human gate:
- Require explicit approval for deploy, delete, payment,
customer messages, and irreversible changes.5. Completion: a contract that proves the work closed
Three open PRs are not a result. A loop finishes only when the deliverable, the tests, the handoff, and the approval are all in a state you can check.
- Deliverable: exactly what should exist at the end.
- Proof: which test, screen, URL, or log confirms it works.
- Handoff: who receives it and what they need to get.
- Approval: which decision still stays with a human.
- Notification: how you know the loop is waiting and not still spinning.
- Closeout: what needs to be merged, deployed, and documented before you mark it done.
COMPLETION CONTRACT
Deliverable:
[the final result]
Required proof:
- [test or command]
- [real screen, URL, log, or provider state]
Handoff:
- owner: [who receives it]
- package: [what is delivered]
- approval needed: [yes or no, and about what]
Do not report complete while any required proof is missing.
If waiting, report exactly what is waiting and notify the owner once.6. Sentry: turn errors into a maintenance loop
Customers do not always report. A good maintenance loop pulls errors from Sentry, works through a fixed process, and reaches a PR, but stops before merge or deploy.
- MCP pulls only errors that are new since the last round.
- A fixed skill defines reproduction, evidence, fix, and tests.
- Every fix happens on a branch or an isolated worktree.
- The PR includes the error, the root cause, and the test that passed.
- A human approves before merge, deploy, or a message to a customer.
- The next run ignores errors that already have a documented outcome.
DAILY SENTRY LOOP
1. Pull new production errors since the previous run.
2. Group duplicate fingerprints.
3. Reproduce the highest-impact new error.
4. Apply the fixed debugging skill.
5. Implement inside an isolated branch or worktree.
6. Run the required tests and save the evidence.
7. Open a PR with root cause, risk, and proof.
8. Stop for human approval before merge or deploy.
Record each fingerprint as fixed, rejected, duplicate, or escalated.7. Fit: when a loop is the right tool
More agents do not always give more capability. Every handoff can lose context. Choose the architecture by the shape of the task, not by how many workers you can spin up.
- Loop: a repeatable, measurable task, with fixed tools and a stop condition.
- One agent with full context: when a decision at a later stage depends on details from the first stage.
- Multiple agents: when parts are genuinely independent and can be checked separately.
- Human gate: when you need business judgment, customer approval, or an action that is hard to undo.
- If you cannot write a success check, it is not yet time to automate.
- Start with a small pilot, read the logs, and measure cost before you expand.
FIT CHECK
Use a loop when:
- the trigger is repeatable,
- success is measurable,
- the tools are stable,
- the stop condition is explicit.
Use one full-context agent when:
- later decisions depend on early details,
- summaries would remove important evidence.
Use parallel agents when:
- tasks are independent,
- each output has its own verification.
Keep a human gate when:
- the decision affects money, customers, production, or reputation.How to use this now
First pick your failure point: budget, runtime, model, safety, completion, sentry, or fit. Copy only the matching card, run a small pilot, and only turn it into a standing loop once you have evidence.