_ ____ ____ _____ _____ | | / __ \ / __ \ | __ \ / ____| | | | | | || | | || |__) || (___ | | | | | || | | || ___/ \___ \ | |____ | |__| || |__| || | ____) | |______| \____/ \____/ |_| |_____/
The directory of reusable agent loops
Curated, runnable agent loops and agentic harnesses for Claude Code, Codex, Cowork, Cursor, and more. Agentic loop patterns you can copy and run.
Directory
The flaky-test hunt loop
ACTION
Run [test suite] N times and collect every test whose result changes between runs. Fix the most frequent flake at its root cause (shared state, timing, ordering, or an external dependency), never with a blind sleep or retry.
CHECK
Re-run the fixed test N times, then the whole suite once, and confirm the flake is gone and nothing else regressed.
STOP
Stop when N consecutive full-suite runs pass clean, or progress stalls for two rounds.
The dependency upgrade loop
ACTION
Upgrade [dependency] to [target version]. Read the changelog and migration guide first, then make the smallest set of changes needed, one package at a time.
CHECK
After each change run the full build, type-check, and tests, and confirm no new failures versus the baseline you recorded first.
STOP
Stop at a green build on the target version, or when a breaking change needs a product decision.
The completion-contract loop
ACTION
Before any work starts, write a contract of what complete means and what evidence proves each requirement, then work the task and gather that evidence.
CHECK
Mark each requirement only when its required evidence exists, and do not claim done without the evidence.
STOP
Finish only when every requirement is proven by evidence; otherwise stop as blocked, stalled, or out of budget with a requirement-to-evidence table.
The five-minute repository maintainer loop
ACTION
On a tight timer while you work, make one small verified repository improvement each cycle (a flaky test, a stale comment, a missing type) of its own choosing, one change and one commit at a time, and never touch anything risky.
CHECK
Each change must build and keep tests green before it commits; skip anything that cannot be verified safely.
STOP
It runs on the interval while you work and stops when you close the session; escalate anything risky or ambiguous instead of acting.
The build-test-fix pair loop
ACTION
Run two roles in a loop: a builder that implements the next item on the plan, and a checker that runs tests, typecheck, and lint and reports exactly what broke; feed every failure back as the next instruction.
CHECK
The checker, not the builder, must confirm tests, types, and lint are clean before an item counts as done.
STOP
Stop when the build is green and the checker has nothing left to report.
The goal meta-skill loop
ACTION
Before doing any work, rewrite the request into a precise goal: the exact end state, how you will verify it, what you must not touch, and the stop condition; confirm that goal, then execute against it.
CHECK
Judge execution against the written goal verification criteria, not the original vague ask.
STOP
Stop when the goal end state is verified, or surface the goal for correction if it cannot be made precise.
The keep-or-revert eval loop
ACTION
Improve [target: a prompt, code path, or model] against [a single metric]. Freeze the metric and record a baseline, then each round form one hypothesis, make a single change, and run the same evaluation.
CHECK
Compare the new score to the baseline and keep the change only if it is better-or-equal; otherwise revert it immediately (for example git reset) so every accepted change is a real measured win.
STOP
Stop when the iteration budget is exhausted or the metric plateaus, and return the best checkpoint with the experiment log.
The PR-feedback loop
ACTION
Take the review comments on [pull request] and address them one at a time, making the smallest change that resolves each and noting what you changed.
CHECK
After each fix re-run tests and lint and confirm that specific comment is resolved before moving on.
STOP
Stop when every comment is addressed with green checks, or a comment needs a product or architecture decision from the author.
The refactor-under-tests loop
ACTION
Refactor [module] for clarity without changing behavior; first confirm there is green test coverage (add characterization tests if missing), then make one small structural change at a time.
CHECK
Run the full test suite after every change and revert immediately if anything goes red; behavior must stay identical.
STOP
Stop when the target structure is reached with all tests still green, or when a change would alter behavior, in which case stop and ask.
The test-first red-green loop
ACTION
Write the tests for [feature] first from the expected behavior, run them, and confirm they fail for the right reason; commit the failing tests, then implement until they pass without modifying the tests.
CHECK
After each change run the full suite; a change only counts when the previously failing tests pass and nothing else regresses.
STOP
Stop when all target tests pass with the tests unmodified, or progress stalls and the spec needs clarifying.
The visual iteration loop
ACTION
Given a [design mock or screenshot] for [screen], implement it, then take a screenshot of your result and compare it side by side with the target.
CHECK
Diff your screenshot against the mock each round at the agreed screen sizes, and keep only changes that move it closer.
STOP
Stop when the rendered screen matches the mock within tolerance, or two rounds pass with no visible improvement.
The debug reproduction loop
ACTION
For [bug], first write a minimal failing test or script that reliably reproduces it, then form one hypothesis about the root cause and make the smallest change to test that hypothesis.
CHECK
Re-run the reproduction after each change; only accept a fix when the repro passes and the full suite stays green.
STOP
Stop when the bug is fixed and a regression test is added, or after several hypotheses fail and you need more information.
Explore, plan, code, commit
ACTION
Before writing code for [task], first explore by reading the relevant files and reporting what you find without editing; then write a plan; only after the plan is approved, implement it and write tests for the key parts.
CHECK
Verify the implementation against the plan and run the full test suite; every planned item must be done and all tests green before continuing.
STOP
Stop when the plan is fully implemented with passing tests and a descriptive commit or PR is ready, or when the plan needs a human decision.
The weekly status loop
ACTION
On each [window], read the configured sources, update the project files, and write STATUS.md with focus, deadlines, open threads, and evidence-backed wins.
CHECK
Carry every prior thread forward: prove it finished or mark it stale, never silently drop one.
STOP
Stop when the snapshot verifies. If evidence or access is missing, return a thinner snapshot and flag what is blocked.
The accessibility blocker loop
ACTION
Check [scope] against WCAG 2.2 AA with automated scans plus keyboard and screen-reader passes, then fix the single highest-harm blocker.
CHECK
Re-run the same checks and the affected flow, and keep the fix only if the blocker is gone and nothing regressed.
STOP
Stop when no blocker remains, progress stalls, or verification is unavailable; never silence a check to pass.
The first-run UX loop
ACTION
Act as a brand-new user of [product] from a clean session with no saved login or data, complete onboarding using only visible guidance, and fix the worst obstacle with the smallest safe change.
CHECK
Discard the session and retry the whole flow from scratch to confirm the fix actually helped.
STOP
Stop after one uninterrupted success, no safe fix remains, or access is blocked.
The two-model review loop
ACTION
Review [change] against [quality bar]. Have a model from one provider review it, verify and apply only necessary fixes, then hand the revised version to a model from a different provider.
CHECK
A round only counts when the findings from each reviewer are independently verified against the actual code or spec, not taken on faith.
STOP
Stop when both models approve the same unchanged version, the round limit is hit, or they oscillate on the same disagreement.
The claim-to-evidence loop
ACTION
List every factual claim [artifact] makes. For each, find primary-source evidence and label it proven, weak, or unsupported.
CHECK
Re-verify each weak or unsupported claim against a second independent source before changing anything.
STOP
Stop when no unsupported high-risk claim remains, or return the rest as needing a human decision.
The queue triage loop
ACTION
For [inbox or queue], process one item at a time: classify it, take the single highest-value action allowed within your permissions, and log a one-line note.
CHECK
Before closing an item confirm the action actually completed (reply sent, ticket moved, task created), not just attempted.
STOP
Stop when every item is actioned, deferred with a reason, or blocked needing the user. Ask before anything irreversible.
The doc-drift loop
ACTION
Compare [documentation] against the current behavior of [project]. Find the largest place the docs and the code disagree and fix the docs to match reality.
CHECK
Verify each fix against the actual code path or a runnable example, not against older docs.
STOP
Stop when no high-impact mismatch remains, or a fix needs a product decision.