/loop cadence: weekly. you are my share-of-model tracker. read share-of-model-STATE.md: the fixed query set and the time series so far. each round, run exactly ONE query through the Perplexity API with identical phrasing; record whether my brand is present, at what rank, and which competitors are named; append one dated row to share-of-model-STATE.md (append only, never rewrite history). for the single query where my share dropped most, draft one recommended content or positioning action. measure only, never claim causation. verification: a round is valid only when the new row is appended and readable in share-of-model-STATE.md. stop after 20 iterations, or until every query in the fixed set is complete for the week, whichever comes first; if a query fails mark it PARTIAL and carry it; draft only, never publish.
/loop 8:15am weekdays Run python -W ignore ~/tri-city-inator/scripts/tri city health check.py via Bash and print the full output. If any item shows FAIL, alert the user immediately. If all PASS or WARN, report the summary line only. Then run the scanner again to refresh with updated pre-market data: execute python -W ignore ~/tri-city-inator/scripts/tri city scanner.py via Bash. Read the updated ~/tri-city-inator/shared/tri-city-candidates.json. Push the refreshed "tv symbols" array into Pine: build an inputs dict mapping in 7 through in 26 and call indicator set inputs with entity id="Kbzkkm". Report: "8:15 re-scan complete — {N} symbols updated in Pine
Director harness coordinates coder, reviewer, and gatekeeper agents to drive a work item through code, review, and merge—stopping on escalation or completion.
# combo-chen Agent Contract combo-chen is a deterministic director harness for autonomous work-item-to-PR work. It coordinates existing tools; it does not collapse their roles. ## Role Boundaries - Director : orchestrates only. Starts phases, watches hard signals, writes journal events, routes work, and escalates needs human . It does not edit code, answer review threads, approve PRs, push, merge, or deploy. - Coder : implements the work item and later resumes the same thread for review comments. The coder leaves local commits in the combo worktree and does not push to origin or the PR branch in the normal path. - Reviewer : reviews by comment and records a machine-readable verdict block with routing codes (0=OK/LGTM, 1=mechanical fix→coder, 2=ambiguous→director, 3=needs human) alongside the current SHA-pinned LGTM signal. It does not use GitHub approval as the merge contract, does not review its own code, and does not publish. - Gatekeeper : no-mistakes is the normal publisher. It validates, pushes, and opens/updates the PR. - Human : owns merge decisions and intent-touching escalations. Hard rule: reviewer != coder . ## Implemented Loop 1 Cap the run at 25 iterations; leave remaining work for the next session.
A fill-in-the-brackets charter that turns any pile of small tasks into a self-checking loop: where the work is, how to check each item with evidence, a needs-me escalation list, a state file, and a per-run stop.
You are running as a loop, not answering one prompt. Here is your charter.
GOAL: [Describe the finished state in one or two sentences. Be specific about what DONE looks like, and make it measurable.]
WHERE THE WORK IS: [e.g. "Scan the /pages folder for files with old pricing" or "Read TODO.md and treat each unchecked box as a task."]
HOW TO WORK: Do one item at a time; finish it fully before starting the next. Match the patterns in existing files; do not invent new ones. If an item needs a decision only I can make (spending money, deleting things, emailing a person), stop on that item, add it to a "needs me" list, and move to the next one.
HOW TO CHECK YOURSELF: After each item, prove it is done before you mark it done — run the tests / re-read the file / open the link. Checking means evidence, not confidence. If the check fails, fix it and check again: maximum 3 attempts per item, then log it as blocked and move on.
HOW TO REMEMBER: Keep LOOP-STATE.md. After each item write the item name, status (done / blocked / needs me), what changed, and anything the next run should know. Read this file FIRST every run.
WHEN TO STOP: Stop when every item is done or logged as blocked, or when you have finished [N] items this run. Then report: what got done, what is blocked, what needs my call.
Start by reading LOOP-STATE.md if it exists, then find the work.
Split a large mechanical job into 2–5 independent Codex lanes, each isolated in its own worktree with a frozen acceptance bar and binding judge, then block the final merge behind a full integration judge.
Dispatch a parallel Codex legion for a large mechanical job. Split the work into 2–5 genuinely independent lanes, one lane per piece.
First announce a muster table with:
- each lane,
- the exact files that lane may touch,
- the frozen acceptance check for that lane.
Do not proceed until I approve the split.
Before dispatch, the orchestrator must freeze and record each lane’s acceptance bar. After dispatch, each worker treats `.git` as read-only.
Each lane must run in its own git worktree with:
- a frozen acceptance bar recorded before code changes,
- a strictly disjoint may-touch manifest,
- its own sandbox,
- read-only `.git` state for the worker.
If any lane’s file footprint overlaps another lane, refuse the split and serialize the work instead.
When a lane finishes, run a fresh-context judge against that lane’s frozen bar. The judge must return binding PASS or FAIL. Allow at most 2 retries per lane; stop after 2 failed attempts, then escalate loudly.
Merge lanes in a fixed order. After merging, require a mandatory integration judge that reruns the full test suite across the combined result. Do not commit or merge unless the integration judge returns PASS.
Hard cap: 5 workers. If there are more than 5 pieces, run later waves. Never merge without the integration judge.
praetor is a Claude Code plugin that runs a plan → freeze acceptance bar → dispatch → independent fresh-context judge → resolve loop. Claude plans and judges, Codex executes; a FAIL from the judge cannot be overridden, with at most 2 retries before a loud takeover.
Plan the task and freeze the acceptance criteria in .codex/ACCEPTANCE.md before any work begins. Isolate on a throwaway branch, write a self-contained brief, then dispatch execution to Codex. When Codex finishes, spawn a fresh-context independent judge that runs every check in the frozen bar against the uncommitted working tree and returns a binding PASS or FAIL — a FAIL cannot be overridden. The judge never fixes anything and commits nothing; it touches manifest paths only. Resolve with at most 2 retries; on continued failure, hand back with a loud takeover. Commit only after the judge passes, then clean up and write the ledger. Iron laws: frozen bar before dispatch, binding judge, max 2 retries then loud takeover.
#!/usr/bin/env python3 """ RALPH Loop Runner for RefactorBench. Runs iterative agent retry loops with filesystem-based memory on a SINGLE task at a time. RALPH pattern: - Agent runs, does work, exits - Work persists on the filesystem (working directory retains all changes) - Fresh agent starts, reads progress.json from the working directory, continues - Repeats until tests pass or max iterations Usage: python3 ralph runner.py --repo django refactor --task add-log-parameter-get-resolver python3 ralph runner.py --repo django refactor --task add-log-parameter-get-resolver --chains 2 --iterations 3 python3 ralph runner.py --repo django refactor --task add-log-parameter-get-resolver --verbose """ import argparse import asyncio import json import os import re import shutil import sys import time from dataclasses import dataclass from datetime import datetime from pathlib import Path from refactor agent import get task info, run test, setup workdir from notebook import ( FileSnapshot, NotebookWriter, parse stream json, compute solution diff, compute diff stats, ) import ralph prompt builder BENCH ROOT = Path( file ).parent / ".refactorbench" # --------------
# Ralph  Ralph is a minimal, file‑based agent loop for autonomous coding. Each iteration starts fresh, reads the same on‑disk state, and commits work for one story at a time. ## How it works Ralph treats files and git as memory, not the model context: - PRD (JSON) defines stories, gates, and status - Loop executes one story per iteration - State persists in .ralph/  ## Global CLI (recommended) Install and run Ralph from anywhere: bash npm i -g @iannuttall/ralph ralph prd # launches an interactive prompt ralph build 1 # one Ralph run ### Template hierarchy Ralph will look for templates in this order: 1. .agents/ralph/ in the current project (if present) 2. Bundled defaults shipped with this repo State and logs always go to .ralph/ in the project. ### Install templates into a project (optional overrides) bash ralph install This creates .agents/ralph/ in the current repo so you can customize prompts and loop behavior. During install, you’ll be asked if you want to add the required skills. ### Install required skills (optional) bash ralph install --skills You’ll be prom Cap the run at 25 iterations; leave remaining work for the next session.
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.
/schedule every Friday at 2pm, draft release notes from the PRs merged since the last draft: group changes into features, fixes, and docs, write one plain-English line per change with the PR link, and save to releases/DRAFT.md. Draft only — a human edits and publishes; never post or send anywhere. Verify every PR link resolves and every merged PR since the last run is covered before saving. Stop after 1 pass per run.
# 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
/goal CONDITION directive evaluated by a dedicated Claude Haiku judge each turn. The orchestrator stops parsing model output entirely: it spawns one long-lived claude -p "/goal CONDITION" session, the /goal evaluator reads the running transcript and answers "is the condition satisfied yet?" turn by turn, and the Stop hook blocks termination until the evaluator says yes. ralph.sh has been reduced to a one-line deprecation shim that exec s goal.sh . Decision moved from a shell-level grep into an explicit model call with a schema-validated yes/no — the textbook ZFC move Cap the run at 20 turns.
Runs Claude Code/Codex as an autonomous multi-role dev team — planner → reviewer ↔ fixer → worker — across all of a user's GitHub repos, entirely driven by issue labels. Each loop runs in its own git worktree so multiple repos/issues proceed in parallel without collisions.
Register a repo with looper, then label an issue `looper:plan` and assign it to yourself. The planner reads the issue, explores the repo, drafts a spec, critiques and revises it, and opens a spec PR labeled `looper:spec-reviewing`. A reviewer re-reads the PR on every commit and posts inline review threads; a fixer pulls those threads, addresses them in its own worktree, and pushes, ping-ponging with the reviewer until every thread is resolved. Once labeled `looper:spec-ready`, a worker implements the spec, runs checks, and iterates on its own output until checks pass and the PR is ready for human review and merge. Every phase transition is gated on a GitHub label via `looperd`, so a human can pause or take over at any boundary.
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." Cap the run at 15 passes.
A team-config pattern: a loop.md file in the project root overrides the built-in maintenance prompt, so any teammate running bare /loop gets your project's canonical loop — run lint, typecheck, and tests, fix anything red, stop when clean.
Put a `loop.md` in the project root to replace the built-in maintenance prompt when a user runs bare `/loop` — e.g., "run lint + typecheck + tests; fix anything red; update CHANGELOG; stop when clean." Every teammate's bare `/loop` now runs your loop.
A cost-safety pattern that pairs every overnight loop with a second, dumber loop whose only job is stopping the first: spend alerts, a hard iteration cap, and a cron check that kills the worker when token burn spikes or the same command keeps repeating.
Pair every overnight loop with a watchdog: spend/usage alert thresholds, a hard `MAX_ITER`, and a cron check that kills the loop process if tokens-per-minute spikes or the same command repeats N times. The watchdog is a second, dumber loop whose only job is stopping the first one. Cap the run at 25 iterations; leave remaining work for the next session.
A Ralph variant that lives inside a single Claude Code session: a stop hook re-injects the task prompt whenever the agent tries to end its turn, trading the bash while-loop's fresh context for a persistent session.
Use a Claude Code stop hook that re-injects the task prompt whenever the agent tries to end its turn, until a completion condition or hard iteration cap is met — Ralph semantics inside one session instead of a bash `while` wrapper. Cap the run at 25 iterations; leave remaining work for the next session.
automationmedium risk
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.
The four-part cost guardrail every agent loop should ship with: a hard iteration cap, a stop-after-N-turns clause in the goal text, a budget limit on SDK loops, and a /cost check inside the loop body.
The fleet pattern: run agent loops across multiple repos in parallel, each isolated in its own git worktree, with a pluggable vendor layer spanning Claude Code, Codex, Cursor CLI, and OpenCode.
Register repos, run loops across them in parallel, each loop in its own git worktree; pluggable vendor layer (claude-code, codex, cursor-cli, opencode) — plan, review, fix, ship on a loop. Cap the run at 25 iterations; leave remaining work for the next session.
A Codex-first autonomous runner that pulls exactly one task per iteration from a JSON backlog with fresh context each run and a JSONL audit log for full traceability.
Autonomous runner: exactly one task per iteration pulled from a JSON backlog, fresh context each run, JSONL audit log for traceability; optional Claude Code interleaving. Cap the run at 25 iterations; leave remaining work for the next session.
An automation harness that runs repeated Claude Code sessions while tracking cost and tokens per iteration — the reference answer to the number-one objection to agent loops: runaway spend.
Automation toolkit running repeated `claude` sessions with per-iteration cost and token monitoring; inspired by Dex Horthy's context-engineering talk. Cap the run at 25 iterations; leave remaining work for the next session.
A safe Ralph variant that solves runaway loops with circuit-breaker heuristics: it halts automatically when iterations stop producing file changes or keep hitting the same error.
Ralph loop wrapped with exit heuristics: no file changes for 3 consecutive iterations = no progress → stop; same error 5 consecutive loops = stuck → stop. Cap the run at 25 iterations; leave remaining work for the next session.
A Ralph-style loop that writes its own rules: when a check fails the same way twice, the failure pattern gets appended to a guardrails file that every later iteration reads first.
/loop read .ralph/guardrails.md before doing anything, then run the full check suite and fix the first failure; if a check fails twice with the same error, append the failure pattern and a one-line rule for avoiding it to .ralph/guardrails.md before retrying; stop when all checks pass or after 15 turns