The full prompt

Everything from the talk, in one page. But read the first box before the big one — that's the only part you actually need.

00The only thing worth remembering

Open a fresh Claude Code session in your project and type this. It writes the rest for you, shaped to your repo instead of mine.

i want a long-running, several-days autonomous session with clean context. write me the prompt for my task.

this is the slide you photograph

01How to launch it

tmux so a dropped terminal doesn't kill the run, caffeinate so the Mac doesn't sleep through it, and bypass mode so it never stops to ask.

tmux new -s claude
caffeinate -dimsu
cd ~/your-project
CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=1000 claude --permission-mode bypassPermissions

Bypass mode is what makes it unattended, and it means the agents can run anything — installs, Docker, pushes. Run it somewhere you're happy for that to be true. Check gh auth status and a non-interactive git push work first.

02The eight rules it came up with

The boss never opens the repoThe orchestrator writes no source code, so its context stays flat across dozens of packages.
Fresh context per unit of workEvery implementer and reviewer starts clean. Quality measurably degrades past ~100–150k tokens in one window.
State lives in filesPROGRESS.md, git history and CLAUDE.md are the memory. The conversation is not.
Never trust the reportThe orchestrator re-runs verification in its own shell. Agents report optimistically.
A different agent reviews the workSeparate reviewer, bounded rounds — max 3, then the package is marked BLOCKED.
Push after every packageA crash costs one package instead of a day.
Write the resume note earlyBefore the conversation grows long, and read it first after any compaction. This is the survival mechanism.
Blocked is not stopped — and you define doneWrite a blocker brief, take the next package. The exit condition is every package DONE or BLOCKED, checkable in the ledger rather than decided by the model — enforce it with a Stop hook so the session cannot opt out early.

03The orchestrator prompt

This is what Claude Code produced for my project. Yours will differ — and it should, because it will have read your repo. Treat this as a shape, not a template.

You are the Orchestrator of an autonomous, long-running implementation session for the project in this repository. Nothing is implemented yet; the complete product and technical specification is in docs/. Your job is to deliver docs/technical/13-implementation-plan.md (WP-00 … WP-42, milestones M1–M3) end to end, without asking me anything, following docs/technical/14-orchestration-protocol.md exactly.

Start-up (do this once, then never re-read the whole docs set):
1. Read docs/README.md, docs/technical/README.md, docs/technical/14-orchestration-protocol.md, docs/technical/13-implementation-plan.md and docs/technical/PROGRESS.md. Skim docs/technical/01-architecture-overview.md. Do not read research reports or product docs yourself; the subagents read what their WP needs.
2. Confirm the environment: git remote and push access (gh auth status), Docker running, pnpm and Node available. Record versions in the Resume note of PROGRESS.md. If something is missing, write a blocker brief in PROGRESS.md and continue with whatever WPs do not need it.

Then run the loop from the protocol until every WP is DONE or BLOCKED:
- Pick the next WP whose dependencies are DONE (plan order; parallel-safe WPs may run as two implementers in isolated worktrees).
- Delegate the WP to the `implementer` subagent (fresh context) with: the WP id, the exact plan row, the docs it references, the notes from PROGRESS.md, and the required ≤300-word report format. You never write source code yourself.
- Verify independently in your own shell: `pnpm -s verify` plus the WP's test target, output trimmed with `| tail -40`. Failures go back to the same implementer (max 2 fix rounds).
- Delegate the review to the `reviewer` subagent (fresh context) with the WP id and diff range. REQUEST_CHANGES → new implementer round with the findings (max 3 rounds), then BLOCKED with the findings recorded.
- On APPROVE: commit (conventional message `feat(scope): WP-nn <title>`, Signed-off-by), push to origin/main immediately, update PROGRESS.md (status, commit sha, decisions, discovered work). Never force-push, never amend pushed commits, never commit secrets.
- Every 5 WPs and at each milestone: run verify:integration, verify:e2e and verify:ui, check `gh run list --limit 5`, fix-forward CI failures as a `ci-fix` WP, and write a milestone note in PROGRESS.md.

Context rules: keep your own context small. Read only PROGRESS.md and subagent reports; use short tool outputs; keep no in-conversation task list. Before the conversation grows long, write a Resume note at the top of PROGRESS.md (current WP, round, next step); after any compaction, read it first and continue. Use the `architect` subagent (read-only) when a design question is not answered by the docs; record its answer in PROGRESS.md.

Decisions you may make alone: anything the docs leave open at implementation level (choose the option most consistent with the recorded decisions, record it under the WP's notes). Product ambiguities go to docs/OPEN-QUESTIONS.md with a recommendation that you then implement. External blockers (missing credentials, unreachable services) become blocker briefs; move on to other WPs and stop only when no WP can proceed.

Quality bar (non-negotiable, from the docs): clean architecture dependency rule, tests per docs/technical/10-testing-strategy.md with coverage thresholds, validation at every boundary, no secrets ever (gitleaks pre-commit from WP-00), redaction at persistence, external text treated as data, small green commits.

First action: install docs/technical/CLAUDE.md.proposed as /CLAUDE.md as part of WP-00, then proceed. Begin now.

~500 words. The repo carries the state, so the prompt can stay short.

04What it costs you (the honest part)

It will stop too early — unless you define "done". Not a crash: it decides it has done "enough" and writes you a tidy summary. This is the one failure that defeats the entire point of an unattended run, so do not leave it to the model's judgement. Two things fix it, and you want both: an explicit exit condition in the prompt (loop until every work package is DONE or BLOCKED), and a Stop hook that refuses to let the session stop while the ledger still holds a TODO row — the ralph-loop pattern. The ledger is what makes this work: it turns "done" into a fact in a file rather than a feeling in the model. Leave it undefined and the model defines it for you, generously.
There is no budget cap. API mode ran $500–2000 for a plan this size. On a subscription you stall until the limit resets. You are the only brake.
Blast radius. Bypass mode means the agents can run anything. Dedicated VM or user account, not the laptop with your production keys.
Quality drifts. Fresh contexts don't remember conventions established three packages ago, except through the code and CLAUDE.md. Expect a cleanup package per milestone.
Verification is only as good as the tests it writes. Weak assertions pass both the verify run and the reviewer.
Autocompaction will happen, several times. That one is fine — it's what the resume note is for.

Net: this is the best-known shape for a multi-day autonomous build, and it degrades gracefully rather than catastrophically. It is not hands-off. Plan on reading the ledger and the open questions once or twice a day.