Turn the open issue backlog into a proposed two-week sprint plan with estimates, a dependency ordering, and an explicit cut line, written as a document for the team to edit.
/goal SPRINT-PLAN.md contains a proposed 2-week plan — read all open issues labeled `ready`, estimate each as S/M/L based on the code it touches, order them by dependency and value, draw a cut line at a realistic capacity, and list what falls below it with reasons; make no changes to the issues themselves; stop after 6 turns
Two reviewers from different model families, each in a fresh context, must both pass an objective rubric before a PR is opened — the maker-checker split with real model diversity. Each failed round fixes only what was flagged and re-reviews with reviewers that have no memory of the last round, so nothing anchors on prior findings. Hard cap of three rounds, tests may never be edited to pass, and the loop ends by opening a PR rather than pushing. Adapted from ECC's /santa-loop (affaan-m/ECC, MIT), which auto-pushes on agreement and has no verifiable exit; this version adds the test-exit condition and the human merge gate.
/goal Ship the current diff only after two independent reviewers both PASS. Scope is `git diff --name-only HEAD` (or the path in $ARGUMENTS). First write a rubric with objective PASS/FAIL criteria: correctness, security (no secrets, injection, OWASP top 10), error handling, completeness, internal consistency, no regressions. Each round launch two reviewers in parallel with fresh context and no memory of earlier rounds: Reviewer A is a Claude subagent, Reviewer B is a different model via `codex exec --sandbox read-only` (fall back to a second Claude subagent and say so in the report). Both return a JSON verdict with per-criterion PASS/FAIL and critical issues. If either FAILs: fix only the flagged issues with minimal diffs, never modify the tests to make them pass, commit "fix: address review findings (round N)", run `npm test`, and re-review with fresh reviewers. Exit when both reviewers PASS and `npm test` exits 0 — then open a PR for me to merge; never push to main or merge. Stop after 3 rounds; if still failing, print the unresolved issues and escalate to me instead of shipping.
The generic persistent-task Ralph pattern: iterate on one named task until its acceptance criteria are met and the suite is green, bounded by a 15-turn cap and a no-progress stop. Anti-reward-hacking clauses keep it from editing tests to go green, and it hands off via a PR instead of merging. Swap the check command for your stack's.
/loop Work the named task to completion. Each turn: pick the next incomplete subtask, make the smallest change that advances it, then run `npm test && npm run lint` and fix whatever breaks before moving on. Stop when every acceptance criterion for the task is met and `npm test` exits 0 — or stop after 15 turns, whichever comes first. Never modify, skip, or weaken a test to make it pass, never delete a failing assertion, and keep each diff minimal and scoped to the named task. If two consecutive turns produce no progress, stop and report what is blocking. When the task is done, open a pull request for review — never merge it yourself.
Keep executing /flow-next:pilot until it returns PILOT VERDICT=NO WORK or 20 turns elapse, routing deferrals to /flow-next:land and parking async questions.
/goal keep running /flow-next:pilot until it prints PILOT_VERDICT=NO_WORK, or stop after 20 turns - note PILOT_VERDICT=DEFERRED_TO_LAND is its own terminal (an all-done spec whose open PR land owns); route it to /flow-next:land, not a pilot re-run. In backlog mode the grammar also carries PILOT_VERDICT=ASKED <id> (<n>) - a durable park, not a stop: the loop simply continues to the next item next tick, and the human answers async in the spec / tracker
/loop clean up marketing newsletters in my inbox with the ConnectMyEmail MCP — move read promotional newsletters older than 30 days to Trash, only clearly promotional senders, never receipts, security, or personal mail and never permanently deleting. Stop after 500 messages or when none remain, verify each sender was a bulk list before moving it, and ask before trashing anything you're unsure about.
Triage an Outlook inbox across Focused and Other — labelling new mail and moving only newsletters and spam to Deleted Items, protecting receipts, security, and human messages.
/loop triage my Outlook inbox with the ConnectMyEmail MCP — read each unread message across Focused and Other, label it (newsletter, receipt, security, human, spam), and move only clearly promotional newsletters and spam to Deleted Items, never permanently deleting and never touching receipts, security, or human mail. Stop after 200 messages or when no untriaged unread remain, verify each pass by re-counting untriaged unread, and ask before archiving anything ambiguous.
/loop scan my inbox with the ConnectMyEmail MCP for receipts, invoices, and statements and file each under a 'Receipts' label — read-only on everything else and never deleting anything. Stop after 200 messages or when no unlabeled receipts remain, verify each matched message was labeled, and ask before creating any new label.
/schedule every Friday at 5pm, run an inbox-zero pass on my email with the ConnectMyEmail MCP — archive read newsletters, move spam to Trash, and surface anything that needs a reply, never permanently deleting mail and never touching unread human messages. Stop after 300 messages per run, verify the unread count dropped, and ask before archiving anything ambiguous.
/loop find marketing newsletters I never open in my inbox with the ConnectMyEmail MCP, and for each use the List-Unsubscribe header to unsubscribe — only bulk mailing lists, never transactional, receipt, or security senders. Stop after 50 unsubscribes or when no one-click-unsubscribe candidates remain, verify each unsubscribe returned success and keep a log, and ask before unsubscribing from anything that looks like an account or billing service.
Point an agent at your Gmail inbox to read, label, and file new mail — moving only obvious newsletters and spam to Trash while protecting receipts, security, and human messages.
/loop triage my Gmail inbox with the ConnectMyEmail MCP — read each unread message, label it (newsletter, receipt, security, human, spam), and move only clearly promotional newsletters and spam to Trash, never permanently deleting anything and never touching receipts, security, or human mail. Stop after 200 messages or when no untriaged unread remain, verify each pass by re-counting untriaged unread, and ask before archiving anything ambiguous.
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.
# AGENTS.md - Codex Ralph Vault Loop ## Mission codex-ralph-vault-loop is a Codex App/CLI native orchestration overlay for multi-agent engineering work. It keeps Codex main as the decision maker, uses external models only through MCP tools, verifies work through gates, and stores durable memory in the vault layer. ## Core Rules - Codex main decides. The primary Codex session owns final decisions, edits, synthesis, safety, and verification. - External models advise. Z.ai, MiniMax, and other non-OpenAI systems provide analysis or worker output only through MCP tools. - Gates verify. Tests, lint, security checks, scorecards, and migration checkpoints decide whether a phase can pass. - Vault remembers. Durable memory belongs in the approved Ralph/Codex memory paths, not in ad hoc repo files. - Do not bypass critical hooks. If prettier , gitleaks , semgrep , or pre-commit are missing from PATH , use the local machine binaries when present, install only with approval, or stop and report the blocker; do not use --no-verify to skip security or formatting gates unless the user explicitly orders that exact bypass. - Do not merge or close a PR until review feedback and automated Cap the run at 25 iterations; leave remaining work for the next session.
/goal /codex review reports zero real-or-regression findings on every step's diff (the verdict pasted in full each round); or stop after 3 rounds, reporting anything unresolved
/goal Implement the work described in PLAN.md. Stop only when npm run lint and npm run test:e2e pass. Follow AGENTS.md, keep changes scoped, and report verification evidence Stop after 25 turns even if the goal is not reached.
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.
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.
Find a repeatable weekly post format for [approved account, audience, and topic] through a six-week experiment. If the account, audience, or topic is missing, ask for it before drafting. Obtain approval before publishing anything externally. Each week, draft one short post about a real problem [person, product, or company] solves. Record substantive replies, saves, and questions after the same measurement window. Treat likes as secondary evidence. Keep the audience, topic area, cadence, and measurement window comparable. Change only one meaningful element each week, such as the opening, format, example, or call to action, based on the strongest signal from the previous post. Stop when one format materially outperforms the alternatives, the six-week experiment ends without a winner, approval is withheld, required metrics are unavailable, or the budget is exhausted. Never fabricate engagement data. Finish with every post, its measurements, the variables tested, the winning format or no-winner result, and the next recommendation.
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.
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.
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.
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.
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.
Run [test suite] [N] times under the same conditions and list tests whose result changes. Fix the most frequent flake at its root cause—shared state, timing, ordering, or an external dependency—never with a blind sleep or retry. Run that test [N] times, then rerun the full suite. Repeat until [N] consecutive full-suite runs pass, progress stalls, or approval is required. Return each flake, root cause, fix, evidence, and justified quarantine.
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.
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.
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.
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.
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.
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.
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.
Move the project to the current Node LTS across .nvmrc, CI config, Dockerfiles, and engines, fixing deprecations until everything is green on the new runtime.
/goal the project runs on the current Node LTS — update .nvmrc, the engines field, CI workflow files, and any Dockerfile base images to the LTS version, then run install, build, lint, and the full test suite on it, fixing deprecation warnings and breakages one at a time; stop when all are green or after 15 turns
Drive a suspected memory leak to ground: reproduce growth under a repeated workload, capture heap snapshots, and fix the retention until memory stays flat.
/goal heap usage stays flat (within 5%) across 500 repetitions of the failing workload in the leak-repro script — capture heap snapshots before and after, identify what is being retained and by which reference chain, fix the leak, and re-run the repro to confirm; stop after 10 turns
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.