How to go from a fresh machine to a task running, and the complete map of what the harness can do — every use case to its modules and commands. This is the last lesson: one command to set up, one command to drive, and a board of all 36 use cases so you always know which part of the suite answers the job in front of you.
You have seen every part now — the loop, the gates, Forge, AFK observability, cross-agent delegation, fusion, Council, the tools, visual-teach, the Publish Gate, the monolith. This last lesson stops explaining parts and becomes the operator's guide: how to take a fresh machine, get the harness installed, and put a task in motion — plus a complete map so you always know which part answers the job in front of you.
The shape is deliberately small. The harness is the default working mode: any non-trivial task is driven by the loop. One command sets the whole thing up. One command starts a task. And the human only observes — you read the diary while it runs, and you are pulled in only when a genuine human-only decision appears. Everything else in the suite is a named tool you reach for when the job calls for it, and the board at the end of this lesson is the index of all of them.
Think of it like… getting the keys to a well-built workshop. One visit sets up the bench and every machine (setup). To start a job you hang the work order with a clear "done" written on it (drive a task). Then you watch the floor through the window — the crew runs every machine, and they only knock on your door for a call that is genuinely yours to make. The wall chart by the door lists every machine and what it is for: that chart is the use-case board.
This lesson is structured as the runbook: (1) Setup — one idempotent bootstrap that distributes the monolith to every agent; (2) Start a task — classify (rough idea → Forge; crisp spec → the loop directly), then the exact invocation per agent; (3) the use-case board — all 36 cases from USE-CASES.md, each mapped to its modules and its command.
The human role is AFK observability, not operation: you read LOOP-LOG.md and review.md while the loop runs on its own, and you enter only at a decision-ready handoff. Drop the harness instructions into $HOME (the global CLAUDE.md / AGENTS.md) and the loop becomes the default mode for every task, not something you opt into per request.
The whole harness installs with a single bootstrap. It is self-sufficient — the method, the teaching, and the setup all travel in one skill — so there is nothing to clone piecemeal and no build step.
bootstrap the harness on this machine# one command — preflight, distribute to every agent, verify, report
bash ~/.claude/skills/loop-engineering/setup.sh
That command does four things in order. It preflights the prerequisites and the agent command-line tools, reporting which are present and which are missing (never fatal — the loop is model-agnostic). It distributes the monolith skill, by symlink, into every coding agent's skills directory from your canonical ~/.claude/skills/. It verifies that the skill resolves in each place. And it prints a readiness report plus the exact human-only next steps (authenticate a CLI, run npx wrangler login, enable Cloudflare Access).
It is idempotent and safe: it only creates symlinks and reads files. It never deletes anything, never overwrites your CLAUDE.md, and never sends anything out. Re-run it any time — after editing a module, or after adding a new agent to the roster — and it simply reconciles.
Think of it like… wiring one master switch to every room. You flip it once and the lights come on everywhere; flip it again after rewiring a room and only that room reconnects. Nothing gets torn out, nothing leaves the building — it just makes sure every room is on the same circuit.
On a fresh machine where the skill is not yet under ~/.claude/skills/, copy it in first, then bootstrap. Because the skill is a monolith, the embedded modules (Forge, fusion, Council, visual-teach, the tools, the brief, the publish scripts) come with it.
# 1 · place the monolith under your canonical skills dir cp -R skills/loop-engineering ~/.claude/skills/ # 2 · distribute + verify (idempotent; symlinks + reads only) bash ~/.claude/skills/loop-engineering/setup.sh
Drop the harness instructions into $HOME — the global CLAUDE.md (or AGENTS.md for agents that read that) — so every non-trivial task is driven by the loop by default, rather than something you opt into per request. After this, the same way of working is present no matter which installed agent picks up the next unit (case 1 on the board).
With the harness installed, starting a task is a short, fixed sequence. Walk it once and it becomes automatic. The only branch is at the top: whether the task arrives as a rough idea or as a crisp spec.
If you are on one of the installed agents, it is already ready — the monolith is in its skills dir. A brand-new machine just runs the two setup commands from section 2 first.
If the agent has never run the harness, have it read the harness-brief module first — a dense, top-to-bottom brief of the whole suite, written for a machine to absorb fast (harness-brief/MODULE.md + its 6 lessons).
A rough or vague idea enters through Forge — grill → research (opt) → prototype (opt) → PRD → issues + /goal — which sharpens it into a measurable done-when. A crisp spec with a clear finish line enters the loop directly; skip Forge and capture the done-when inline.
On Claude Code, invoke /loop-engineering <task + done-when>. On Codex, Kimi, Grok and the rest, tell the agent to use the loop-engineering skill to drive the task. For headless delegation of a bounded unit, the proven flags per agent are below.
# Claude Code — JSON out claude -p "<task + done-when>" --output-format json # Codex — quiet exec codex exec --quiet "<one bounded unit>" # Kimi — text out (never -p WITH --yolo; no --work-dir) kimi -p "<one bounded unit>" --output-format text # Grok — plain out, auto-approve, explicit cwd grok -p "<one bounded unit>" --output-format plain --always-approve --cwd .
The loop runs on its own. You read LOOP-LOG.md (the per-pass diary — what it looked at, the one unit it picked, whether the proof passed) and review.md (the QA write-up). You are pulled in only for a genuine user-only fork, surfaced as a decision-ready handoff.
When the done-when is met, the run delivers a visual-teach course and clears the Publish Gate — a private gist always, a Cloudflare Pages site when configured — and reports the URLs back to you.
Here is a copy-paste start with a measurable done-when baked into the ask, the way the loop wants it.
a real start — measurable done-when included# Claude Code — crisp spec, straight into the loop /loop-engineering Add rate limiting to the /search endpoint. done-when: a real request burst of 100/s returns HTTP 429 after the 60th request within 1s, proven by a live curl loop against the running server (not a mock), and the existing test suite stays green.
Before delegating, the orchestrator runs command -v (or the panel-detect step, bash fusion/scripts/detect_panel.sh) so only live agents are dispatched to. The roster is declared at the start of a run; default is agnostic — any agent runs any unit, and the Validator is always a different agent than the builder, which is what makes the Proof Gate trustworthy.
Forge exists to satisfy the Scope Gate when the ask is fuzzy: its 7 steps end in a GOAL.md with a measurable done-when (the ultragoal discipline refuses to compile until the done-when can fail at a real boundary). A crisp spec already has that finish line, so the loop captures it inline and starts looping — no Forge needed.
This is the index of the whole suite: 36 use cases in 8 categories, each mapped to the modules it uses and the command or steps that drive it. Filter by category, and click any card to reveal its modules and exactly how it runs. When a job lands on your desk, find it here and you know which part of the harness answers it.
No category selected.
Each card's front is the case title with its module tags (the embedded parts it uses: the loop + gates, forge, fusion, council, visual-teach, ultragoal, brightdata-cli, computer-use-cli, harness-brief, the publish scripts). Expanding it shows the how — the command or the steps, verbatim from USE-CASES.md. The invariants apply to every case: prove at the real boundary, one bounded unit per pass, the Validator is never the builder, model-agnostic, no AI attribution.
A Setup & distribution · B Driving a task (the core loop) · C Hardening scope (Forge sub-methods) · D Verification & decisions · E Multi-agent / AFK delegation · F Tools · G Teaching & delivery · H Combined / end-to-end. The full cookbook is USE-CASES.md; the human runbook is USAGE.md.
That is the whole operator's guide. The harness is the default working mode; one command sets it up, one command drives a task, and the board above is the map for everything else. You watch through LOOP-LOG.md and review.md; the loop runs on its own and hands you a finished result plus a published course.
The whole guide in three lines
One command to set up (setup.sh). One command to drive (/loop-engineering <task + done-when>, or Forge for a rough idea). A 36-case board for everything else — find the job, read its modules and command, run it.
USE-CASES.md (every case → modules → command) and the human runbook in USAGE.md; the agent-facing brief is harness-brief/MODULE.md. Head back to the course index to revisit any lesson, or pick a card above and run it. This is the last lesson — the rest is doing the work.