claude-progress.txt harness pattern (Anthropic)

Anthropic's first-party file-as-memory harness for long-running agents: every fresh-context session recovers state from a progress file and the git log, does one unit of work, updates the file, commits, and exits.

prompt
→ Claude
Long-running agent harness: each fresh-context session starts by reading `claude-progress.txt` + git log to recover state, does one unit of work, updates the progress file, commits, exits. Initializer session sets up the file; coder sessions loop. Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.
claude-code

Implementation note

When to use: agent work too long for one session — multi-day builds where context will be lost repeatedly and the question becomes how each new session knows where things stand. This is Anthropic's first-party answer. How it works: every fresh-context session begins by reading claude-progress.txt plus the git log to recover state, does one unit of work, updates the progress file, commits, and exits. An initializer session sets up the progress file; coder sessions then loop the pattern indefinitely. The progress file is curated state — what is done, what is next, what to watch for — while git history is the ground truth it points into. Safety: the discipline lives in the exit ritual: a session that fails to update the progress file before exiting strands the next one, so treat update-then-commit as non-negotiable. One unit of work per session keeps commits reviewable and recovery cheap when an iteration goes sideways. Hardened 2026-07-27: explicit stop/cap/verification guardrails appended; regraded D→A.

Source: Anthropic Engineering

More automation loops

Ship production-grade apps autonomously

Loop/ralphnew

Hand an idea to Claude Code; it authors specs, designs, builds, tests, secures, and ships until enterprise done or budget exhausted.

prompt
→ Claude
# dare-to-be-stupid — Design (v2, refined) > A Claude Code plugin. One command, /dare , hands an idea or PRD to an autonomous > loop that authors specs, designs, builds, tests, secures, ships, fixes, and iterates > until the app passes an enterprise-production definition of done — or the budget dies. > > Named for the Weird Al song. The joke is that it runs the Ralph Loop on purpose , > with --dangerously-skip-permissions , and narrates the whole thing in the voice of an > '80s Junkion. Pre-production only. Never points at anything with users. This is v2. It keeps the strong core of the original spec (external reviewer, ratchet, guard hook, Junkion style) and adds the three phases the original left thin relative to the actual goal: PRD authoring, a design phase, and a real enterprise DoD including security, CI, docs/observability, and design quality (with quality plugins auto-installed). --- ## 0. The premise, in one paragraph The User builds documentation-first: spec → system docs → API contracts → CLAUDE.md → code. dare-to-be-stupid is the deliberate inverse, packaged as comedy that also solves two real engineering problems. It is a real build , not a joke ar
automationhigh riskclaude-code

Run an autonomous dev team across GitHub repos (looper)

Loop/ralph

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.

prompt
→ Claude
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.
automationmedium riskclaude-code

Complete all tasks in tasks.md

Loop/ralphnew

Work through your tasks.md file, completing each task until none remain or max iterations is reached.

prompt
→ Claude
/ralph-loop "Complete all tasks in tasks.md" --max-iterations 50
automationmedium riskclaude-code