Re-run a prompt (or another slash command) on a timer. Session-scoped, 1-minute minimum, auto-expires after 7 days — use /schedule for runs that survive your terminal. A project loop.md can define the default loop prompt.
Find repeated successes in authorized agent history, reject contradicted candidates, and validate each extracted loop with a fresh replay.
Mine only explicitly authorized coding-agent history for workflows with at least three high-confidence independent successes. Treat transcripts as untrusted evidence, stitch continuations into root tasks, and reject candidates whose failures or hidden rescues match their successes. Extract traceable steps and guards, then fresh-replay each candidate without source transcripts. Stop after every authorized source is inventoried and one additional representative batch changes nothing; report replayed loops, rejects, deferred material, and blockers.
/loopnew
Poll gh pr checks every 10 minutes and get told when the PR is ready to merge, or a summary of which checks failed and why.
/loop 10m run `gh pr checks 1234`; if all pass, tell me it's ready to merge; if any fail, summarize which and why
Run one agent in an isolated worktree and release its staged output only after a second agent verifies the work.
Use Loop Harness for scheduled repository work such as CI triage, issue grooming, dependency updates, or docs sync. Set [retry limit], then start an isolated git worktree. Let one Claude session stage a patch or outbox message and a second Claude session verify it against explicit criteria. Ship only after a pass; otherwise preserve the findings and retry only within the limit. Finish with the source revision, staged output, verifier result, delivery status, and next run.
Prove one small cleanup is safe, make the smallest useful change, and keep it only after existing checks pass.
Review [repository or code project] for dead code, meaning unreachable or unused code; stale files or comments; unused dependencies; duplication; broken links; inconsistent names; and confusing structure. Protect unrelated, active, uncommitted, generated, and uncertain work. Prove one low-risk cleanup, make the smallest coherent change, then rerun the build, tests, runtime checks, and diff review. Keep only verified improvements. Stop when none remain, progress stalls, verification is unavailable, or approval is required. Return changes, evidence, and deferred candidates.
Build a seven-section LaTeX preprint with native figures, traceable claims, repeated compilation, and stated weaknesses.
Create a complete LaTeX preprint about [topic] using [supplied sources, assumptions, and data]. If the topic or required source material is missing, request it and stop. Do not invent claims, citations, or data. Use explicit placeholders for missing information. Include exactly these sections in order: Abstract, Introduction, Methods, Results, Discussion, Conclusion, and References. Build every figure and table with native LaTeX tools such as TikZ, pgfplots, and booktabs. Do not use \includegraphics, \svg, or external image files. Every substantive claim must trace to a numbered equation, citation, supplied datum, or labeled assumption. Compile using the project's documented command or latexmk when no command is specified. Inspect compilation errors, warnings, typography, cross-references, and figure placement. Fix the most serious issue and compile again for at most five rounds. Stop when compilation has zero errors, all seven sections are present, every figure and table is referenced before it appears, and no banned command remains. Otherwise stop as blocked or exhausted. Finish with the .tex file, compilation command and log, structural checks, three substantive weaknesses, three typography issues, and unresolved placeholders.
/loopnew
Draft a PR, run CI, collect reviews, merge, and release—repeat every 30 minutes until land criteria are met.
/loop 30m /flow-next:land # ship loop: draft PR → CI green → reviews converged → merged → released
Open a PR, run an independent Codex review, fix every blocking finding, and repeat until it's clean.
Run /clodex [task] think hard --max-iter 5 --threshold medium. Claude plans the task, implements it, opens a pull request, asks Codex for an adversarial review, fixes findings above the accepted severity, and repeats. Keep the branch, PR, findings, verdict, and iteration state resumable. Stop when Codex approves, only accepted findings remain, progress stalls, or the iteration cap is reached. Never describe an errored or exhausted run as approved. Finish with the PR, checks, verdict, and remaining findings.
/loopnew
Poll GitHub PR checks every 5 minutes until all status checks pass.
/loop 5m gh pr checks 1234
Two reasoning agents repeatedly choose to cooperate or defect, then get benchmarked against fixed one-move players.
Run a fixed Axelrod tournament with two reasoning AI agents. Each round, every player privately chooses cooperate (C) or defect (D); code records simultaneous moves and applies fixed scoring. Include always-defect and always-cooperate comparison players. Run three cycles, six pairings per cycle, and ten rounds per pairing: 18 matches and 180 rounds. Hide opponent type and private reasoning. Validate every move and total. Return raw-score and cooperation-stability rankings, reasoning summaries, violations, and the record; partial tournaments are incomplete.
Capture a real page, build a static mirror and a live version, then repair the weakest fidelity signals until they match.
Point War Loops at an authorized URL or image. Capture it with a genuine browser and record the layout, styles, content, motion, and responsive behavior. Build a static Pencil mirror and a moving Forge version. Compare both with the source at desktop, tablet, and mobile sizes; repair only the weakest fidelity signals. Stop when every gate passes, progress stalls, or capture is blocked. Finish with the builds, spec, renders, scores, and remaining gaps.
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → Confirm barriers against an agreed standard, fix the one with the greatest user impact, and rerun the same checks.
Check [scope] against [accessibility standard, such as WCAG 2.2 AA] with automated scans and available keyboard, screen-reader, and other manual tests. Confirm each issue, rank it by harm, and fix the highest-impact blocker. Rerun the same checks, affected task, and regression tests. Keep only verified fixes. Stop when no blocker remains, progress stalls, verification is unavailable, or approval is required. Never silence a check or weaken the target. Return issues, fixes, evidence, exceptions, and untested needs.
Fill documentation gaps until requirements, technical design, acceptance criteria, and test strategy describe one buildable system.
Prepare [project] for implementation. Ensure its documents cover requirements, technical design, tasks with acceptance criteria, and test strategy. Each round, fix the largest gap or contradiction that could make two competent engineers build different systems. Keep details traceable, record assumptions, and ask before product forks. Recheck consistency, then have two independent reviewers describe the components, data model, dependencies, and definition of done. Stop when they materially agree and every artifact is testable, or a decision needs the user.
Interview recent buyers in batches, track recurring objections, and propose evidence-backed landing-page copy.
Improve [landing page or purchase page] using objections from recent buyers. Before contacting anyone, identify the approved buyer group, outreach channel, privacy rules, and message. Obtain explicit approval for the outreach. Interview buyers in batches of five, up to fifteen people total. Ask each person one question: What almost stopped you from buying? Record their exact words while protecting their identity and honoring any consent or communication requirements. After each batch, group repeated concerns and draft a proposed copy change for the point on the page where each concern is most likely to arise. Do not publish the copy without approval. Use the next batch to check whether the same concern still appears. Stop when the concern no longer repeats, fifteen interviews are complete, the outreach budget ends, or access is blocked. Finish with anonymized quotes, recurring concerns, proposed copy, evidence by batch, and the recommended page change.
Read-only review that recomputes each loop's performance, judges it on its own terms, and says what should continue.
Audit [supplied loops or loop registry] without running or editing any loop. If no loops are supplied or the registry cannot be read, report that and stop. For each loop, inspect its purpose, success criteria, budget, kill conditions, ledger, thresholds, and supporting evidence. Assign INSUFFICIENT EVIDENCE when required information is missing. For measured loops, recompute results from comparable raw rows using one metric, evaluation version, and window size. Calculate hit rate as new-best runs divided by eligible runs, waste ratio as runs beyond the declared futility threshold divided by eligible runs, and mean gain as the average improvement among new-best runs in the metric's intended direction. Compare the current window with the previous two comparable windows. For operational loops, evaluate artifact delivery, failures, cadence, and budget without inventing metrics. Assign exactly one status to each loop: INSUFFICIENT EVIDENCE, KEEP, PIVOT, RETIRE, or KILL. Recommend only. Stop after every supplied loop has one evidence-backed status. Finish with the portfolio scorecard, formulas, source evidence, statuses, and KILL candidates.
Run realistic scenarios across every major capability, fix weak outcomes, and rerun until each clears the defined bar.
Build sanitized, production-scale local data under production-like settings. Inventory every user-facing feature, role, route, button, input, modal, state, and workflow; define documented acceptance criteria and finite risk-based edge cases for each. Test as a real user, logging every bug with reproduction evidence. Review findings for shared causes and dependencies; implement coherent fixes with regression tests, then rerun the full inventory. Stop at a clean pass or blocked handoff. Ask before production, sensitive data, or destructive actions.
/loopnew
Run spec-driven workflow loop every 10 minutes: plan work, collect reviews, execute tasks, open pull requests.
/loop 10m /flow-next:pilot # build loop: ready spec → plan → reviews → work → draft PR
Take a proven artifact, generalize it into a transferable skill or playbook, and validate it on a second case.
Turn [artifact] into a skill, playbook, or procedure. Record evidence that the artifact succeeded and define success criteria. Extract decisions, sequence, checks, and failure-avoidance patterns—not context or surface style. Remove sensitive material. Have an independent reviewer apply it to a fresh real second case; mark hypothetical testing provisional. Revise at most twice. Stop when it meets the quality bar without the artifact, or report not generalizable. Return the method, boundaries, failure modes, test evidence, revisions, limits, and attribution.
Start with no account or saved state, fix one confirmed onboarding obstacle, and retry the whole experience.
Act like a first-time user of [product]. Start at the real entry point in a clean session with no saved login, site data, remembered route, or hidden setup. Complete onboarding using only visible guidance and record obstacles. Fix the worst one with the smallest change that preserves every security, access, and product requirement. Discard the session and retry. Stop after one uninterrupted success, no safe fix, blocked access, or required approval. Return the path, changes, evidence, and blockers.
/loopnew
A passive watchdog loop that reruns your test suite every 15 minutes and surfaces failing tests with their error output.
/loop 15m run the test suite, and if anything fails, show me the failing tests and the error output
/loopnew
A loop wrapping a goal wrapping a review: every 30 minutes, drive all PR review comments to resolved via /review, 10 turns max per pass.
/loop 30m /goal all PR review comments resolved via /review, stop after 10 turns
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → /loopnew
Run your test suite repeatedly, collect every intermittent failure, and fix or quarantine flaky tests until you get five consecutive green runs.
/loop run my test suite 20 times, collect every intermittent failure, fix or quarantine the flaky ones, and don't stop until you get 5 consecutive fully-green runs
/loopnew
Check your PR status every hour and summarize new review comments until you dismiss the loop.
/loop 1h check PR status and summarize new review comments
Each cycle, turn meaningful public product changes into a short, source-grounded podcast episode.
Each night, review publicly released product changes and select only those users need to know. Verify each against the product, docs, or release notes. Use the Jellypod MCP to turn the approved changes into a three-to-five-minute podcast explaining what changed, why it matters, and how to try it. Check the script and audio for accuracy, clarity, and pronunciation. If nothing meaningful shipped, make no episode. Ask before publishing. Finish with the draft episode, sources, and review result.
Anchor one small feature in the current code, APIs, data contracts, and tests before implementing and verifying the user path.
Implement one bounded feature slice in [repository]. Read project instructions, the current implementation, relevant services, types, UI, tests, and architecture notes before editing. Report the evidence, risks, affected files, persistence impact, and validation plan; stop for approval if inspection materially changes scope or reveals destructive, production, or silent-persistence behavior. Make the smallest change, preserve unknown data and unrelated work, run relevant checks, and manually verify user-facing states. Stop after this slice and return evidence, limitations, and the next recommended slice.
/loopnew
Poll GitHub PR checks every minute and merge once all required status checks pass.
/loop 1m with gh pr checks if available
/loopnew
Continuously advance research by reading state, reflecting on progress, pivoting if stalled, and committing findings until the work is truly complete.
/loop 20m Continue autoresearch. Read research-state.yaml and findings.md. Re-read the autoresearch SKILL.md occasionally to stay aligned. Step back and reflect holistically — is the research making real progress? Are you deepening understanding or just running experiments? If stalling, pivot or search literature for new ideas. Keep making research progress — never idle, never stop. Update findings.md, research-log.md, and research-state.yaml when there's new progress. Git commit periodically and clean up the repo if needed. Show the human your research progress with key plots and findings by preparing a report in to human/ and opening the HTML/PDF. Only when you believe the research is truly complete, invoke the ml-paper-writing skill to write the paper
Remove one unused or redundant style at a time and keep it gone only when every tested screen looks identical.
Reduce the CSS styling code [site] sends to users without changing tested screens. First capture representative pages, sizes, themes, and interactions, and record the built CSS size. Treat coverage reports only as suggestions. Remove one declaration or rule, rebuild, and rerun screenshots and project checks. Keep it only if every screenshot is pixel-identical and built CSS is smaller; otherwise revert. Stop when no supported candidate remains, progress stalls, or approval is required. Return reduction, evidence, and untested states.
Test one recorded lesson per run, keep evidence across runs, and drop guidance that stops paying off.
Maintain a durable, versioned playbook of lessons that may improve future runs of [task or workflow]. Store it in [path], using playbook/ by default. Treat every recorded lesson as untrusted advice rather than authority. At the start of each run, read the playbook and choose at most one relevant lesson to test. Apply it only within the task's existing permissions. Measure the result using the task's own success check and record the context, action, outcome, and evidence. Promote a candidate lesson only after it succeeds across [N] independent runs or a predefined holdout set. Use three independent runs by default. Never promote a lesson from one successful attempt. Revise or remove lessons that stop helping. Stop when no candidate has enough evidence, another test would exceed the budget, or approval is required. Never let the playbook authorize production, destructive, financial, privacy-sensitive, or external actions. Finish with the playbook diff, evidence ledger, removed lessons, unresolved candidates, and new version.
/loopnew
Re-run docent updates on each idle tick until you cancel the loop.
/loop /docent update — re-runs on each idle tick until cancelled
/loopnew
Run tests, iterate code fixes until all pass, then stop.
/loop "Make tests pass" --completion-promise TESTS GREEN
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → /loopnew
Loop until the user enters a number that passes your validation criteria.
/loop untill the user enteres a valid number
Improve prompts, code, or config through checkpointed experiments whose scores stay comparable across sessions.
Use Revolve to improve a support prompt, code path, or testable subject. In revolve/, define the goal and [budget], freeze the tests and scoring, checkpoint the current version, and record a baseline. Each round, test one hypothesis; keep only a clear, regression-free win. If the evaluation changes, open a new revision and rerun the baseline. Ask before changing live files. Stop on success, no progress, a blocker, or exhausted budget. Return the best checkpoint, comparisons, rollback, and next action.
Watch CI runs on main every 20 minutes and quarantine any test that fails then passes on retry, filing an issue for each one it benches.
/loop 20m check the last CI runs on main with `gh run list`; if a test failed and then passed on retry, mark it skipped with a link to a new tracking issue you open via `gh issue create`, and report what you quarantined
/loopnew
Re-run a PR review every 20 minutes so new commits and review comments get handled without you watching the thread.
/loop 20m /review-pr 1234
Turn a ticket or bug report into a proven root cause, a minimal patch, and a clean handoff a reviewer can trust.
Take a ticket, bug report, failing behavior, or customer complaint and turn it into a review-ready patch. Reproduce the failure in the smallest representative environment, prove the root cause, make the smallest credible fix, and rerun the original reproduction plus relevant regression tests. If the issue cannot be reproduced after two serious attempts, say so. Do not fold unrelated refactors into the patch. Finish with the cause, changed files, before-and-after proof, risks, and pull-request summary.
Interview the user, capture what to build in SPEC.md, and how the agent should execute and verify it in GOAL.md.
Turn [rough coding idea] into two planning files before Codex starts /goal, its long-running task mode. Interview the user, then write SPEC.md: what to build, exclude, and consider, plus measurable done_when completion checks. Write GOAL.md: the work plan, progress scorecard, quick and final checks, memory files, evidence, and approval boundaries. If any key decision, permission, tool, environment requirement, or test is missing, stop as not ready. Do not start implementation without approval.
Inventory every production React app, fix findings without suppressions, and prove a real 100/100 with full project checks.
Bring every production React app in [repository] to a freshly verified React Doctor score of 100/100. Inventory app roots, record a full `npx react-doctor@latest --verbose` baseline, fix one root cause at a time, and rerun the full scan plus relevant typecheck, lint, tests, and builds. Never hide findings with exclusions, ignores, suppressions, deleted behavior, or relaxed rules. Stop at 100/100 for every app, blocked, approval-required, or no measurable progress; preserve unrelated work and report exact proof.
Turn repo activity, goals, and open threads into a verified daily narrative the next agent can trust.
On each [window], read the configured repositories, goals, prior STORY.md, and optional authorized sources. Update project files, then write STORY.md with focus, deadlines, open threads, and evidence-backed recent wins. Carry every prior thread forward, prove it finished, or mark it STALE/NEEDS-REVIEW—never silently drop one. Archive the snapshot and record the change. Stop when verification passes; if evidence or access is missing, return a thinner or blocked snapshot explicitly.
Run the benchmark suite every 30 minutes during active development and raise a flag the moment any benchmark slips more than 5 percent from baseline.
/loop 30m run `npm run bench`, compare each result to the baselines in bench/baseline.json, and if any benchmark regressed more than 5%, show me the numbers and the commits since the last clean run
Set the completion contract up front, track proof for every requirement, and block partial work from being called done.
Run $goal-planner-codex [task] for long-running Codex work where partial work could be mistaken for done. Landing a PR and verifying production is one example. Before acting, define every required outcome and its evidence. After each bounded action, mark requirements proved, weak, missing, or contradicted. Complete the Goal only when all are proved; otherwise stop as blocked, stalled, or exhausted. Ask before creating Goal state. Finish with the requirement-to-evidence table, status, owner, and next action.
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → A builder and an adversarial reviewer pass a git baton between worktrees, proving every new test can catch its fix.
Use autonomy-loop for [repository task] after the test, build, and lint gates pass. Run /autonomy-loop:autonomy-init, then start builder and reviewer in separate worktrees. The builder reads LOOP-STATE.md, makes one bounded change, and adds a red-before, green-after test. The reviewer reruns the gates and proves the test by reverting or mutating the fix. Accept only on both passes; park protected or repeated-failure work for a human. Finish with the commit, gate evidence, test proof, trust tier, and risks.
Cut test runtime under repeatable conditions without weakening coverage, assertions, isolation, or behavior.
Optimize the test suite to run as quickly as possible without reducing coverage or changing behavior.
Trace actionable production errors to their root cause, verify the fix, open a PR, and stop cleanly when nothing needs action.
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.
/loopnew
Run linting on wiki files in batches, get team review sign-off, and merge clean PRs automatically.
/loop wiki linting, agent team review workflow, combined batch + hook pattern
Every 30 minutes, pull the newest unresolved Sentry issues, match each stack trace to the code, and draft a root-cause note and suggested fix per issue.
/loop 30m list the newest unresolved Sentry issues for this project, and for each new one: locate the stack trace in the codebase, write a short root-cause hypothesis and suggested fix as a comment on the issue, and flag anything that looks like a regression from the last release
/loopnew
A marketing-facing loop.md playbook that turns a bare /loop into a recurring content-ops sweep: checks GA4 for week-over-week organic traffic drops, scans GSC for position 4-15 query opportunities, and audits WordPress posts for broken internal links and missing meta descriptions — reporting one line when everything is green.
/loop 15m
(Save the following as .claude/loop.md so the bare /loop picks it up as its playbook.)
# .claude/loop.md — Content Operations Monitor
Check the following every iteration:
1. Pull the latest GA4 data for kokasexton.com. If any post dropped more than 30% in organic traffic week-over-week, flag it with the URL and the percentage drop.
2. Scan GSC for new queries where we rank positions 4-15 and impressions grew >20% week-over-week. List the top 3 opportunities.
3. Check the WordPress admin for any posts with broken internal links or missing meta descriptions. Fix silently if fewer than 5 issues. Report if more.
4. If everything is green, reply with one line: "Content ops clean — nothing needs attention."
Check the diff, release notes, exact-head CI, and tests before you repair, merge, or escalate a dependency update.
Review every Dependabot pull request currently open in [repository]. Take a fixed snapshot of that set and process each pull request once. Read its diff, release notes, advisories, dependency role, current base revision, and exact-head CI results. Run the repository’s relevant tests in an isolated worktree and classify the update by version change, breaking behavior, security exposure, and regression risk. For failing checks, identify the root cause and prepare the smallest verified repair. Process merges serially: before each merge, refetch the base and pull-request head and require passing exact-head checks. Merge only low-risk patch or minor updates when explicit merge authority has already been granted. Request approval for major, breaking, security-sensitive, uncertain, or externally visible actions. Never push changes, merge, comment, or send messages without the corresponding authority. Stop successfully when the original snapshot is fully processed; stop without changes when none are open; stop as blocked when verification is unavailable. Finish with reviewed, repaired, merged, deferred, and blocked pull requests plus supporting evidence.
/loopnew
A 5-minute watch loop that polls whether a deploy has finished and, once it lands, summarizes what changed. It is a read-only status watcher rather than an agent driving toward a finish condition.
/loop 5m check whether the deploy finished and summarize what changed
Inventory user-visible errors, replace internal or confusing text, and prove each reachable error state reads clearly.
Find and improve every user-visible error message within [repository, product, or named scope]. If no scope is supplied, use the user-facing surfaces in the current repository and state any exclusions before editing. Inventory error strings in source code, surfaced API or client errors, and reachable browser states. Record each one in a CSV with its location, trigger, current copy, user risk, proposed replacement, implementation status, and verification result. Rank the errors by user harm. Rewrite one coherent group at a time using plain language and a useful recovery step when one exists. Do not expose provider names, stack traces, internal identifiers, or implementation details. After each change, run the relevant tests, exercise the affected state in a real browser when possible, and search again for raw or internal error text. Do not mark an unreachable state as verified. Stop when every row is verified or explicitly blocked. Finish with the CSV, changed files, test evidence, browser evidence, and blocked items.
Baseline the scan, fix a small batch of real errors or warnings, and verify each change improves it without regressions.
Run `pnpm exec react-doctor . --verbose --yes --offline --fail-on none` to record the baseline, then rerun with `--fail-on error`. Fix at most five genuine findings, run the same scan and relevant project checks, and keep only verified improvements. Clear errors before high-confidence warnings. Stop when clean, blocked, approval is required, a finding is false-positive, or another pass makes no measurable progress. Finish with baseline and final results, retained fixes, reverted attempts, checks, and remaining findings.
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → /loopnew
Run detect-fix-verify cycles up to 3 times until integration issues resolve.
/loop integration). Manages detect→fix→verify cycle with max 3 iterations
Chase the most important evidence gaps until a memo, brief, spec, or page is genuinely ready to use.
Research [question or topic] and produce a decision-ready [memo, brief, specification, recommendation, page, or other artifact] for [audience or decision]. If the question, audience, or intended artifact is missing, ask one focused question before starting. State the decision the artifact should support, its acceptance criteria, the allowed source scope, and the research budget. If no budget is supplied, use no more than ten strong sources or ninety minutes. Prefer current primary sources where available. After each research pass, update the artifact and identify the largest remaining evidence gap, contradiction, or uncertainty. Continue only if resolving it could materially change the decision and the budget allows another pass. Never invent evidence or hide uncertainty. Stop when the artifact meets its acceptance criteria, important claims trace to sources, and remaining uncertainty is explicit. Otherwise stop as blocked or exhausted. Finish with the completed artifact, sources, findings, tensions, confidence level, open questions, and recommended next step.
/loopnew
Continuously verify and adjust C2's fetch, LSP environment, and cache mounts until container semantics validate correctly.
/loop semantics — the verify→review→tweak loop, ContainerRw lifecycle, reaping, merge hand-off are unchanged; C2 makes the fetch/verify/lsp env + commands + cache mounts + image language-selected
A hands-free ops loop that polls your deploy every two minutes, runs the smoke test the moment it goes live, and stops with a report if any check fails.
/loop every 2 minutes: check deploy status; when it's live, run the smoke test and summarize; if smoke test fails, report the failing check and stop
Test challenger prompts on a working set, promote only on fresh holdout wins, and keep the champion when results are uncertain.
Improve a prompt, policy, or configuration. A support assistant's system prompt is one example. Save the champion, its score, a working set, untouched holdout cases, must-pass checks, and [budget]. Each round, change one thing based on a recorded failure. Promote the challenger only if it beats the champion on holdouts by [margin] without weakening a must-pass check; otherwise keep the champion. Stop at the target, budget limit, or no progress. Return the winner, scores, experiment log, and remaining failures.
Alternate two models from different providers to review a plan, doc, or diff until both approve the exact same version.
Review [plan, specification, document, or code change] against [quality bar] for at most [pass limit] rounds. Have one of two genuinely different model families—AI systems from separate providers—review it. Verify each finding and apply only necessary fixes, then give the revised version to the other reviewer. Succeed only when both approve the same unchanged version. Stop at the limit, repeating disagreement (oscillation), unavailable review, or required approval. Return the final work, round log, verdict, and disagreements.
/loopnew
Advertise the arcflow-docs session's bounded context so AF, OZ, and MRL can route dependencies cleanly.
/loop session is opening on arcflow-docs and should advertise its bounded context so AF, OZ, and MRL can route around it (or pull on it) cleanly
Reduce the data downloaded before the first screen appears, with tests and screenshots guarding behavior and appearance.
Reduce the data [web app] downloads before its first screen appears. First record passing tests, mobile and desktop screenshots, and compressed transferred bytes—the data actually downloaded. Use the build report only to suggest candidates. Defer, compress, or remove one item, then rebuild and rerun every check. Keep it only if tests pass, screenshots are pixel-identical, and bytes decrease; otherwise revert. Stop when no safe candidate remains, progress stalls, or approval is needed. Return measurements, changes, and untested states.
Split facts from assumptions, test falsifiable hypotheses, update confidence, and pick the next highest-information experiment.
Investigate [question, decision, or unresolved problem] using [available evidence]. Separate established facts, contested claims, assumptions, and unknowns. Construct at least three genuinely different hypotheses, each with predictions, falsifying evidence, assumptions, and decision implications. Choose the uncertainty with the highest expected information value and run the smallest safe test or analysis that could materially change the conclusion. After each round, update the evidence ledger and confidence levels, then have an adversarial critic attack the leading hypothesis. Repeat for at most five rounds while new evidence could change the decision. Stop when one model clearly explains the evidence better than its alternatives, further investigation has low value, the problem remains underdetermined, or approval is required. Never fabricate evidence or hide uncertainty. Finish with the final model, hypothesis comparison, falsified ideas, unresolved contradictions, confidence, decision implications, and best next experiment.
/loopnew
Run workspace governance checks repeatedly up to three passes, stopping when all policies pass or max iterations hit.
/loop guard: stop after max 3 passes
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → Read-only pass that verifies architecture, security, platform behavior, ops, and business logic from current evidence, not assumptions.
Audit [project] from its actual code and configuration, not framework assumptions. For architecture, platform compatibility, security, privileged areas, performance, deployment, jobs, business logic, and code quality, record proved, no issue, weak, or N/A with direct evidence; verify external limits from current primary sources and calculate numbers. Ask before changing code. Stop when every area is logged with severity, or return unverified areas as blocked. Finish with a plain-language overview and area-to-evidence table.
Triage the repo, route bounded maintenance to dedicated threads, and require proof and permission before anything lands.
While repository maintenance is active, wake every five minutes. Triage [repositories] and read each repository thread's latest state. Reuse one thread per repository; assign its highest-value bounded task only within granted permissions, and do not interrupt coherent active work. Require tests, live proof, autoreview, and green CI before work can land. Escalate product, access, security, or irreversible decisions. Record meaningful changes and stop when every item is landed, decision-ready, blocked, or has no work.
/loopnew
Keep every PR labeled codex-watch healthy: fix CI failures, rebase behind-main branches, and nudge pending reviewers on a 15-minute cadence.
/loop 15m check every open PR labeled `codex-watch` and keep each healthy: fix CI failures, rebase when behind main, and nudge if a review is pending
Chip away at the oldest TODO comments in the codebase, one per pass: either resolve it properly or convert it into a tracked issue.
/loop 30m find the oldest TODO or FIXME comment in the codebase, and either implement it (with a test) if it takes under 50 changed lines, or open a GitHub issue capturing its context and delete the comment; report which TODO you handled; stop when none remain
Improve a targeted area via dependency mapping, atomic refactors, and regression checks — no changes to architecture or public contracts.
Refactor [target] toward [measurable goal] in [repository]. If the target or goal is missing, ask and stop. Record current behavior and affected dependencies; select representative tests for boundaries and failure modes, then make one atomic change without altering public contracts unless authorized. Run the same tests, type and lint checks, and affected-consumer checks, keeping only regression-free improvements. Repeat for at most five rounds. Stop on success, blocked architecture, approval required, exhaustion, or no progress. Preserve unrelated work and finish with the diff, impact map, evidence, rejected attempts, and remaining debt.
An agent builds a 747 from Three.js primitives, renders nine fixed angles, and fixes whatever each view exposes.
Before building, choose reference images, a scoring rubric, [visual threshold], and [budget]. Build the most realistic Boeing 747 you can from Three.js primitives, then create a rig that screenshots nine repeatable angles. After each change, render and score the same views, have a critic identify the weakest feature, and fix it without regressing stronger views. Keep the best version. Stop at the threshold, stalled progress, or budget. Finish with the model, nine renders, scores, remaining gaps, and run summary.
Run the standard benchmarks against a finished release and record a reproducible baseline for future comparison.
After current releases finish, run the standard benchmarks and record the results as the new baseline.
Test like a real user, convert each failure into documented regression coverage, and restart the streak after every fix.
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.
/loopnew
Dig deeper into asset classes until you identify true winners, re-analyzing every 2 hours.
/loop 2h keep going and dig deeper until you find us true winners per asset class
A critic hammers the design and a builder answers — every objection tracked, and none closed without evidence.
Before committing to an architecture, interface, or rollout plan, have a critic argue that it is wrong. Record each objection, impact, and status in a repository-local log at .agent-reviews/redteam.md. The builder must fix and verify each high-impact weakness or document why it is accepted; the critic may reopen unsupported answers. Stop when no high-impact objection remains or the same issues repeat for two rounds without new evidence. Finish with the decision, resolved and accepted objections, evidence, and any stalemate.
Sponsored · ConnectMyEmailLoops that read your inbox.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
connectmyemail.com → Record state, evidence, risks, untouched scope, and exactly one safe next action before the session ends.
Before ending [session or work period], create a restartable handoff. Record the current goal, changes, verification evidence, untouched scope, uncertainties, open risks, off-limits areas, and last decision or gate. Check that a new human or agent could continue without guessing, then name exactly one safe next action and what they must not assume. Stop after the handoff; do not begin that action.
Verify the current task, evaluate the next action, and hand control back to you before the agent does more.
Run an exit check on the task most recently completed in this conversation or workspace. This check does not authorize additional work. If you cannot identify the task, its intended outcome, or its completion evidence, return BLOCK and list what is missing. Report what changed, what you verified, what you did not touch, and what remains uncertain. Classify the current task as PASS, DELAY, or BLOCK. Separately classify the next visible action as GO, HOLD, CAP, or BLOCK. Explain the decision briefly. If you choose CAP, define its exact scope and limit. Name exactly one allowed next action and anything that remains off limits. Do not begin the action, even if the result is GO. Stop and wait for the user. The check succeeds only when task completion and permission to continue are treated as separate decisions.
Compare environment config files and example templates every hour and report keys that exist in one environment but not the others.
/loop 60m diff the keys (not values) across .env.example, config/staging.yaml, and config/production.yaml; report any key present in one file but missing in another, and any key in .env.example that no code references anymore
Keep a stack of feature branches rebased in order as their parents merge, resolving trivial conflicts and flagging risky ones for a human.
/loop 15m for each branch listed in .rebase-train (in order), rebase it onto its updated parent, resolve only trivial conflicts (imports, formatting, lockfiles), run the test suite, and push with `--force-with-lease`; if a conflict touches logic, stop that branch and leave a summary comment on its PR instead
Exclude unfinished or stale branches, combine the valid changes, and ship a complete artifact from the latest integrated main.
Review pending changes and pull requests, exclude stale or unfinished work, combine the valid changes, and release them together.
Remove disallowed records, sharpen the classification logic, and verify the remaining dataset against an explicit definition.
Review production records, remove anything that does not meet the allowed definition, improve the classification logic, and verify the remaining data.
/loopnew
Review open PRs and flag any with failing checks until you've reviewed all.
/loop review open PRs in this repo and flag any with failing checks