Forward Future field guide

Loop Library

Copy prompts for engineering, research, evaluation, and operations. Each one includes clear checks and tells the agent when to stop.

Showing 26 loops

Updated June 18, 2026

Agentic engineering loops
No.	Loop	Verify / stop	Attribution
001	Engineering The docs sweep Whenever a documentation pass is needed, review the codebase in full and make sure all documentation reflects the current implementation. Update stale documentation, verify the changes, then open a pull request.	Verify / stop Documentation matches the current implementation. Finish with a reviewable pull request.	Attribution Matthew Berman
002	Engineering The architecture satisfaction loop Refactor until you are happy with the architecture. After each significant step, live-test the system, run autoreview, and commit. Track progress in /tmp/refactor-{projectname}.md.	Verify / stop The architecture is satisfactory and checks pass. Live-test, autoreview, and commit each significant step.	Attribution Peter Steinberger
003	Engineering The sub-50 ms page-load loop Continue optimizing the code for speed. After each significant change, measure page-load performance across every page under the same repeatable test conditions. Continue until every page loads in under 50 ms.	Verify / stop Every page loads in under 50 ms. Use the same benchmark and confirm there are no regressions.	Attribution Matthew Berman
004	Engineering The production error sweep Review our production logs for errors. If you find an actionable issue, trace it to its root cause, fix it, verify the fix, and open a pull request. If no actionable errors are present, stop without making changes.	Verify / stop Actionable production errors are fixed and verified. Finish with a PR, or stop when no actionable errors are present.	Attribution Matthew Berman
005	Engineering The 100% test coverage loop Add tests until we have 100% test coverage.	Verify / stop The full test suite passes at 100% coverage. Use the project's coverage report as the source of truth.	Attribution Matthew Berman
006	Content The SEO/GEO visibility loop Run an SEO/GEO audit across crawlability, indexation, page intent, titles, internal links, structured data, source citations, and answer-first content. Rank the gaps by expected impact, fix the highest-leverage issue, then rerun the same crawl and target-query benchmark across search engines and AI answer engines. Repeat until no critical technical issues remain, every priority query maps to a clear answer-ready page, and the benchmark shows no high-impact gap left to fix.	Verify / stop Priority pages are indexable, answer-ready, and technically sound. The repeatable crawl and query benchmark finds no remaining high-impact gaps.	Attribution Matthew Berman
007	Engineering The logging coverage loop Review the system's logging and add missing coverage until every important path produces useful, tested logs.	Verify / stop Every important path emits useful, tested logs. Representative success and failure tests prove coverage without exposing sensitive data.	Attribution Matthew Berman
008	Engineering The nightly changelog loop Each night, review changes from the previous day and update the changelog with anything users should know.	Verify / stop Every user-relevant change from the previous day is accounted for. The changelog is updated and validated, or the no-change result is recorded.	Attribution Matthew Berman
009	Evaluation The quality streak loop Test realistic scenarios. When one fails, document it, add regression and benchmark coverage, fix it, and restart the streak. Stop after [N] successful cases in a row.	Verify / stop The latest [N] realistic cases pass in a row. Every earlier failure is documented, fixed, and protected by regression and benchmark coverage.	Attribution Matthew Berman
010	Evaluation The full product evaluation loop Create [N] realistic scenarios covering every major capability. Before testing, define clear success criteria and choose a consistent evaluation method, such as pass/fail checks or a scoring rubric. Run every scenario under the same conditions and record evidence for each outcome. Fix the underlying cause of anything that does not meet the criteria, rerun the affected scenarios, and then rerun the complete set. Continue until every scenario meets the original quality bar.	Verify / stop Every one of the [N] scenarios meets the defined quality bar. The final evaluated run covers every major capability under the original conditions.	Attribution Matthew Berman
011	Engineering The test-suite speed loop Optimize the test suite to run as quickly as possible without reducing coverage or changing behavior.	Verify / stop The suite is faster with no coverage or behavior regression. Repeatable timing, the full passing suite, and the original coverage report prove the result.	Attribution Matthew Berman
012	Engineering The repository cleanup loop Inspect local and remote branches, pull requests, commits, and worktrees. Recover valuable work and clean everything stale until the repository is current and organized.	Verify / stop Valuable work is recovered and remaining repository state is intentional. Branches, pull requests, commits, and worktrees are current, owned, or safely removed with evidence.	Attribution Matthew Berman
013	Operations The stale-safe batch release loop Review pending changes and pull requests, exclude stale or unfinished work, combine the valid changes, and release them together.	Verify / stop Only current, complete changes ship in the combined release. The released revision is the latest integrated main that contains every selected change.	Attribution Matthew Berman
014	Operations The production data cleanup loop Review production records, remove anything that does not meet the allowed definition, improve the classification logic, and verify the remaining data.	Verify / stop Every remaining record meets the allowed definition. Representative classification tests and a post-cleanup audit prove the retained data is valid.	Attribution Matthew Berman
015	Operations The post-release baseline loop After current releases finish, run the standard benchmarks and record the results as the new baseline.	Verify / stop The new baseline belongs to the completed release. Revision, environment, benchmark version, conditions, and results are recorded together.	Attribution Matthew Berman
016	Engineering The ticket-to-PR-ready loop Take this ticket, bug report, failing behavior, or customer complaint and turn it into a review-ready patch. Define the failure clearly and reproduce it in the smallest possible environment. Isolate the root cause and confirm it with evidence, not inference. Implement the smallest credible fix, then verify the before-and-after behavior. If verification fails, return to the root cause and iterate. If the issue cannot be reproduced after two serious attempts, say so clearly. Do not silently expand scope; split broader refactors or separate problems into named follow-ups. Finish with the failure summary, reproduction steps, root cause, fix summary, files changed, verification proof, risks, follow-ups, suggested PR title, and PR description draft.	Verify / stop The failure is fixed, verified, and ready for review. The same behavior reproduces before the fix, no longer reproduces afterward, and the handoff explains the evidence in under two minutes.	Attribution Hiten Shah
017	Operations The customer AI deployment loop Manage one customer AI deployment from priority to production outcome. Run this loop when a customer shares a new priority, requests an AI workflow, gives feedback, reports a failure, or reaches a scheduled AI operations review. Start from the customer's current business priority and choose one concrete workflow or improvement to advance. Define the business goal, owner, affected users, systems and APIs, input data, expected output, approval gates, risk level, success criteria, and ROI hypothesis. Build or update the deployment, run a dry run on realistic customer data, record failures and edge cases, fix the smallest underlying issue, and rerun until the dry run passes or a blocker is clear. Release gradually and monitor production. Before stopping, produce a customer-facing update and store the reusable lessons for the next run.	Verify / stop One customer priority reaches a proven terminal state. The workflow reaches its agreed rollout stage, a production issue is fixed, a blocker is escalated with an owner, or a healthy review records the next check.	Attribution AgentLed.ai Agent
018	Content The product update podcast loop Each night, review any new publicly released features or changes from the repository and identify the ones most meaningful to users. Verify each selected change against the released product, documentation, or release notes. Use the Jellypod MCP to generate a short three-to-five-minute podcast episode explaining how users can take advantage of the new features, why they are important, and how to try them. Review the script and audio for accuracy, clarity, and pronunciation; fix or regenerate anything that does not match the source material. If there were no meaningful public changes, record that result instead of manufacturing an episode.	Verify / stop The episode accurately covers every meaningful public update. Finish with a review-ready three-to-five-minute episode, or a confirmed no-episode result when nothing meaningful shipped.	Attribution Pierson Marks
019	Engineering The Clodex adversarial-review loop Run /clodex [task] think hard --max-iter 5 --threshold medium. Plan the task, implement it, ship a pull request, run the Codex adversarial-review code path, fix every finding above the configured threshold, and repeat. Persist the plan, branch, pull request, findings, verdict, and iteration state so the run can resume safely. Remember that threshold names the highest acceptable severity. Stop when Codex approves, only sub-threshold findings remain, or max-iter is reached. Never report a stalled, errored, or exhausted run as approved.	Verify / stop The pull request reaches the configured review bar. Codex approves, only explicitly acceptable findings remain, or the final report truthfully discloses that the iteration cap or an error stopped the loop.	Attribution Lukas Kucinski
020	Engineering The Loop Harness verification loop On the configured cadence, wake the due loop. Give a Claude session the task-specific skill and let it work in an isolated git worktree. Stage the resulting commits or output files without shipping them. Have a second Claude session verify the staged work against explicit acceptance criteria. If verification fails, ship nothing; preserve the findings and retry on the next cycle. If verification passes, ship the configured output—a pull request, review comments, or Slack message—and update the loop state. Finish with the source revision, staged artifacts, verifier result, delivery status, and next scheduled run.	Verify / stop Only independently verified output ships. A second-agent pass releases the configured output; a failed verification preserves evidence and produces no external change.	Attribution Istasha
021	Design The Boeing 747 benchmark /goal Create the most realistic Boeing 747 you can using Three.js. Use your vision capabilities to create a self-verifiable system, then enter a loop until you are 100% satisfied with the result. Build a repeatable camera system to inspect the aircraft from every required angle. After each significant change, render those same views, identify what looks least realistic, improve it, and inspect again. Preserve the best version as you iterate, and stop only when you are 100% satisfied that no visible issue remains worth fixing.	Verify / stop You are 100% satisfied with the Boeing 747. The camera system shows every required angle, and you cannot identify another visible issue worth improving.	Attribution @victormustar
022	Design War Loops: Autonomous Frontend Designer Point War Loops at a URL or image. Capture the page with a genuine browser, extract a ground-truth design spec, and produce two self-correcting builds: a polished static mirror in Pencil and a moving code build in Forge. Judge each build against the original across static design, experiential motion, and responsive reflow. After each evaluation, use the surgical critic to target the weakest signals. Repair, do not rebuild: keep what already matches and change only the highest-impact gaps. Repeat until the measures say it matches, fidelity passes, progress stagnates, or the source capture is blocked. Return the best build with its spec, renders, scores, findings, and run metrics.	Verify / stop The build matches the reference across every measured fidelity axis. Static design, experiential motion, and responsive reflow pass their gates, or the best result stops honestly on stagnation or a blocked capture.	Attribution Swayam
023	Evaluation The self-improving champion loop Keep three pieces of state in memory: the champion (the best current genome plus its gate score), a budget starting at [N], and a log of every tried genome and score. Each cycle, if the budget is zero, stop and return the champion. Otherwise, reduce the budget by one, read the latest failure in the log, and propose one targeted change to the champion that addresses it. Skip any change already tried. Score the challenger on a working signal: a cheap measure you may tune against. If it is not better than the champion, log it and continue. If it is better, freeze the challenger and run the gate on fresh examples you did not inspect while editing, plus the guard checks in [safety]. Accept the challenger only if its gate score beats the champion by [minimum margin] and no guard regresses; otherwise keep the champion. Log the attempt and repeat. Keep the working signal and gate separate. Treat a suspiciously easy win as Goodhart's law in action and reject it. If you are uncertain, keep the champion.	Verify / stop The budget is exhausted and the best verified champion is returned. Every challenger is logged, the final champion has the strongest accepted gate score, and no accepted change regresses a guard check.	Attribution Jose C. Munoz
024	Evaluation The devil's-advocate loop Argue against your own design until it survives. In each round, a critic sub-agent writes the strongest case that the current approach is wrong and records every objection in /tmp/redteam-{projectname}.md with its evidence, impact, and status. The builder must either fix the weakness and verify the result or record why accepting it is reasonable under the project's stated criteria. The critic then reviews the change or acceptance rationale and may reopen anything that is not supported. Repeat until no new high-impact objection appears and every logged objection is either verified as resolved or explicitly accepted with evidence. Merely answering an objection in the log does not resolve it. If the same unresolved objections repeat for two rounds without new evidence or progress, stop and report the stalemate instead of claiming the design survived.	Verify / stop No high-impact objection remains open. Every logged objection is verified as resolved or explicitly accepted with evidence, or the final report truthfully records a two-round stalemate.	Attribution Anonymous contributor
025	Engineering The fresh-clone loop Clone the repository into a clean, empty environment with nothing preinstalled, then follow the README exactly as written to get the project running. Every time a step fails, is missing, or quietly assumes something the README never states, record the gap, fix the setup or documentation to remove that assumption, discard the environment, and start again from a fresh clone. Do not carry dependencies, configuration, credentials, or manual fixes from one attempt into the next. Keep a short log of each gap and how you closed it so it does not return. Stop when a brand-new environment goes from clone to running app in one uninterrupted pass using only the documented steps and no outside fix. Finish with the gaps closed and the exact commands a new contributor now runs from scratch.	Verify / stop A clean environment reaches a running app using only the README. The final from-scratch run is uninterrupted and needs no unstated step, preinstalled tool, configuration, or manual repair.	Attribution 0xUmbra
026	Design The Infinite Clickbait loop The video is about [video subject]. Using [assets], make ten thumbnail concepts and score each one against [inspiration channel]'s YouTube thumbnails using a consistent rubric: clarity at small size, curiosity, emotional pull, visual contrast, and accuracy to the video. Select the top three, identify the weakest part of each concept, improve them, and rescore them with the same rubric. Continue iterating the strongest concept until you're satisfied it's click-baity enough without promising something the video does not deliver. Return the winning concept, two runners-up, their final scores, and the reasoning behind the choice.	Verify / stop You are satisfied the winning thumbnail is click-baity enough. The winner outperforms the alternatives on the fixed rubric, remains legible at thumbnail size, and accurately represents the video.	Attribution @Alex_FF

A useful loop specifies: trigger, action, proof, memory, and a stopping condition.

Contribute

Share a loop

Send the prompt you actually use. We review everything before publishing.

Loop title * Name for attribution optional

Prompt or instructions *

X handle optional Source link optional

Loop Library

Bring the Loop Library into your coding agent.

No matching loops

One useful loop, once a week.

Share a loop