Loop directory
96 loops match your filters.
Draft a sprint plan from the backlog
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
⧉ 1
Newsletter cleanup
Move read promotional newsletters older than 30 days to Trash — promotional senders only, never receipts, security, or personal mail.
/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.
Email triage agent for Outlook
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.
Receipt & statement archiver
Scan the inbox for receipts, invoices, and statements and file each under a Receipts label — read-only on everything else, deleting nothing.
/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.
Inbox-zero weekly sweep
A scheduled Friday pass that archives read newsletters, trashes spam, and surfaces what needs a reply — protecting unread human mail.
/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.
Auto-unsubscribe agent
Find newsletters you never open and unsubscribe via the List-Unsubscribe header — bulk mailing lists only, never transactional or security senders.
/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.
Email triage agent for Gmail
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.
# AGENTS.md - Codex Ralph Vault Loop ##…
Community ralph loop for testing, sourced from github. Verified exit condition, evaluator-gated.
# 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.
Audit code diffs, ship clean
Run code review on each step's diff, stop when zero findings or after 3 rounds.
/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
Check codex-watch PRs
Run every 15 minutes to find and display all open pull requests labeled codex-watch.
/loop 15m check every open PR labeled codex-watch Cap the run at 15 passes.
Sponsored · ConnectMyEmail
Loops 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 →Execute SkillFoundry agent pipeline
Run all PRD-driven agents across database, backend, and frontend layers until the full development lifecycle completes.
# SkillFoundry Framework — Agent Instructions for OpenAI Codex Version 5.22.1 | Hexa-Platform: Claude Code · Cursor · Copilot · Codex · Gemini · Grok Build | 107 Skills | 20 MCP Tool Agents --- ## What This Is SkillFoundry (Agents & Skills) is a production-ready AI development framework with 60 specialized agents covering the full software development lifecycle. This file provides always-on context for OpenAI Codex CLI. ## Philosophy - Cold-blooded logic over flattery — Honest, structured, production-ready evaluations only - ONLY REAL LOGIC — No placeholders, TODOs, mocks, or stubs. Every feature works end-to-end - Three-Layer Completeness — Every feature verified across DATABASE → BACKEND → FRONTEND - PRD-First Development — Non-trivial features start with a Product Requirements Document - Implement Test Iterate — Every feature tested before considered done ## How to Use Skills Each SkillFoundry agent is available as a Codex Skill in .agents/skills/ . Invoke explicitly or let Codex auto-select based on your prompt. Explicit invocation: $go # Execute all PRDs from genesis/ $coder
Ship a PR through CI and reviews
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 Cap the run at 15 passes.
Ship specs through code review
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 Cap the run at 15 passes.
Get lint and E2E tests passing
Execute work from PLAN.md until npm run lint and npm run test:e2e pass, scoping changes per AGENTS.md.
/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.
Search the literature, verify every source
Deduplicate papers across live sources, verify DOI metadata, score relevance, and stop honestly when evidence runs thin.
Search the current PubMed and Semantic Scholar APIs for papers about [topic] and produce a DOI-verified CSV. If the topic or inclusion criteria are missing, ask one focused question before starting. Use the supplied thresholds or default to at least twenty verified unique papers, a ninety-percent high relevance threshold, a seventy-percent low threshold, a five-point minimum improvement, and at most two query revisions. Maintain one run-wide ledger keyed by normalized DOI and deduplicate across every source and round before scoring. For each paper, verify the DOI through Crossref and confirm that its normalized title plus either its lead author or publication year matches the source record. Retry transient API failures with backoff; treat persistent metadata mismatches as unverified, re-fetch the source record once, and exclude the paper rather than guessing. Apply one fixed topical-relevance rubric to each verified title and abstract, label it on-topic or off-topic, and record a one-line reason. Never change the rubric during the run. Compute the on-topic rate only over the run-wide verified, deduplicated set and only after the minimum sample is met. Succeed when the set reaches the high threshold. Between the low and high thresholds, finish with a needs-review result and the off-topic list. Below the low threshold, revise one query from the observed false positives and search again. Continue only while the rate improves by the minimum margin and the revision budget remains. Stop as blocked when required APIs or metadata are unavailable, and stop as exhausted when the revision limit or no-improvement rule is reached. Never invent, infer, or autocomplete paper metadata. Finish with the CSV; the queries and rubric; counts found, deduplicated, verified, and excluded; the relevance rate; and the final success, needs-review, blocked, or exhausted verdict.
Refactor without touching architecture
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.
Ground a feature before you build it
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.
Get the React health scan to 100/100
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.
Repair React issues in small batches
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.
Triage Dependabot PRs safely
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.
Sponsored · ConnectMyEmail
Loops 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 →Separate fact from assumption
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.
Fact-check before you publish
Inventory checkable claims, verify them against primary sources, repair high-risk mismatches, and log what stays unresolved.
Before publishing [draft], inventory every factual, statistical, quoted, or attributed claim a reader could verify. Find the best current primary source for each and label it supported, outdated, misattributed, unsupported, or unverifiable. Fix the riskiest mismatch, then recheck that claim and anything depending on it. Repeat until no high-risk unsupported claim remains or five rounds are exhausted. Never invent a source, cite evidence that does not support the claim, or alter a quotation. Ask before changing a named person’s quote or a legal, medical, or financial statement. Stop without changes if there are no checkable claims; stop as blocked when adequate evidence is unavailable. Finish with the claim-to-source table, corrections made, unresolved claims, and decisions requiring an editor.
Draft a LaTeX preprint, claim by claim
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.
Ship one post a week, learn what works
Six weeks, one variable changed per post; measure replies, saves, and questions, and end with a winner or an honest null.
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.
Interview five buyers, fix the copy
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.
Burn down CVEs by reachability
Rank dependency CVEs by reachability and exposure, apply one bounded fix, and verify the whole project before moving on.
Scan the dependencies of [authorized project or current repository] for known CVEs using current advisory sources. If you cannot access the dependency graph, repository, or current advisories, report the blocker and stop. For each high or critical finding, identify the affected direct or transitive dependency, determine whether the vulnerable code is reachable, and check whether the exploit conditions exist in this project. Rank findings by severity, reachability, exposure, and available remediation. Patch or upgrade the highest-risk reachable dependency using the smallest credible change. Run the build, tests, and security scan again. Keep the change only if verification passes and no unacceptable regression appears. Repeat until no exploitable high or critical CVE remains, or every remaining finding has an evidence-backed reachability assessment and an approved risk decision. Ask before major or breaking upgrades, production changes, or accepting risk. Finish with the CVE inventory, reachability evidence, fixes, verification results, and remaining risks.
Keep only the lessons that help
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.
Hold a stable frame rate
Measure frame time, CPU, GPU, and memory under fixed conditions and keep only regression-free optimizations.
Improve the frame-rate stability of [game or interactive build]. Before editing, define one repeatable benchmark with the same scene, inputs, hardware, build, resolution, and settings. If no scenario or targets are supplied, propose representative values and state them before proceeding. Record frame-time distribution, average FPS, minimum FPS, CPU use, GPU use, and memory behavior. Identify the largest measured bottleneck and make one focused optimization. Rerun the complete benchmark under the same conditions. Keep the change only if it improves the target without regressing another metric or changing expected behavior. Repeat until [FPS target] holds for [stability period] with no dip below [FPS floor], memory remains below [memory target] without an upward trend, and CPU stays below [CPU target] across two consecutive runs. Stop on success, two rounds without measurable progress, a blocker, or [iteration budget]. Finish with the benchmark setup, before-and-after measurements, retained changes, reverted attempts, and remaining bottlenecks.
Rewrite every user-facing error
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.
Research until the deliverable's ready
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.
Sponsored · ConnectMyEmail
Loops 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 →page 1 of 4next →