You have met every piece of the harness. This last lesson puts them in your hands: install it in two commands, see how each AI surface invokes the very same harness, then watch one rough idea travel all the way to a published course — Forge, the loop, a real proof, the course, the publish, and the one moment it pauses to ask you. Same engine everywhere; you stay on the dashboard.
Everything in this course — the loop, the Proof Gate, Forge, the AFK crew, the tools, the Publish Gate — lives inside one thing called the harness: a small set of skills (folders of instructions) that sit on your machine. This lesson is the hands-on finish. First you install it. Then you see that no matter which AI you happen to be talking to, you are reaching the same harness through a different front door. Finally you watch a single rough idea travel the whole way to a finished, published course, and notice the one place it stops to ask you a question.
Three kinds of reader meet the harness here, and it helps to name them up front. You, the human, mostly need one thing: the cheat-sheet — a short page called USAGE.md that reminds you how to start a run and where to watch it. The AI you are driving (an LLM) does the actual work: it reads the skill, runs the loop, gets a real proof, builds the course, and publishes it. And the agents themselves — Claude Code, Codex, Cursor, Gemini, and the rest — are interchangeable: the harness is byte-for-byte identical on every one of them, so the same instructions produce the same behaviour wherever they run.
That last point is the quiet magic of the whole design, so hold onto it: install once, behave the same everywhere. You do not learn a different tool for each assistant. You learn the harness, and then you can pick whichever AI is in front of you.
Think of it like… a recipe card pinned in several different kitchens. The card is the same in every kitchen — same steps, same finish line. One cook prefers a gas stove, another an induction hob, a third a campfire, but they all follow the identical card and serve the same dish. Installing the harness is pinning that one card into all your kitchens at once; the AIs are the cooks; you are the person who reads the short summary on the fridge and tastes the result.
It is a directory of skills — at minimum loop-engineering, visual-teach, brightdata-cli, and computer-use-cli, plus the Forge and fusion helpers. Each skill is a folder containing a SKILL.md (the instructions) and supporting files. Claude Code reads these as native slash-commands; other agents read the same SKILL.md as plain context. Nothing is compiled and nothing is a service — the harness is just instructions on disk, which is exactly why it can be identical everywhere.
The install step copies one canonical source and then symlinks it into every agent's skills directory. A symlink is a pointer, not a copy, so all twelve agents resolve to the same bytes. Change the canonical skill and every agent sees the change at once; there is no per-agent fork to drift. The single exception is Council, which can't follow symlinks the same way and instead uses small .md pointer files — covered in the install section below.
Installing the harness is genuinely two commands. The first copies the skills into your main assistant's skills folder. The second runs a small script that fans those skills out to every other AI on your machine, so they all share one source of truth. After that, the harness is live everywhere — no service to start, nothing to keep running.
Copy the skills into your main assistant
# from the suite folder, copy every skill into Claude Code's skills dir
cp -R skills/* ~/.claude/skills/
This puts the skill folders — loop-engineering, visual-teach, brightdata-cli, computer-use-cli and friends — where your primary assistant looks for them. After this one step, that assistant already has the whole harness.
Fan them out to every other agent
# symlink the 6 skills into all 12 agents' skill folders
bash install-agent-skills.sh
This script creates symlinks (pointers) from each other agent's skills folder back to the one canonical copy. The result: 6 skills shared across 12 agents, all pointing at the same bytes. It is safe to re-run — it only adds links that are missing.
Two details round it out. Council — the multi-model debate panel from lesson 8 — can't be wired with the same kind of symlink, so the script gives it small .md pointer files instead; same skills, reached a slightly different way. And inside your primary assistant, a plugin registers the skills so they show up as real commands you can type, like /loop-engineering. You do not configure any of this by hand — the two commands above set it all up.
Think of it like… putting one master copy of a document in a shared drive, then dropping shortcuts to it on twelve people's desktops. Everyone opens the same file; edit the master and every shortcut reflects it instantly. Council is the one teammate whose computer can't make a shortcut, so they get a sticky note with the file's address — it still leads to the same document.
Open a terminal in the suite's root folder (the one that contains the skills/ directory and install-agent-skills.sh). Run the two commands in order. cp -R skills/* ~/.claude/skills/ copies recursively; bash install-agent-skills.sh then creates the symlinks. Re-running the script is idempotent — it skips links that already exist, so it is safe to run again after you add a new agent.
Two quick checks. List the linked skills with ls -l ~/.claude/skills/ (you should see the folders) and, in your assistant, type / to confirm /loop-engineering and the /fusion-* commands appear. If an agent reads skills from a non-default path, the script's output names where it linked; nothing else needs editing.
It is worth seeing, in one picture, why this works. There is exactly one copy of each skill's instructions. Every agent's skills folder contains a pointer to that one copy rather than its own version. So when an AI "reads the skill," they are all reading the same words. There is no translation step and no per-agent edition to keep in sync — which is precisely what lets you treat the assistants as interchangeable.
The payoff
Learn the harness once. Because the install points every assistant at the same instructions, the command you type and the behaviour you get are the same on Claude Code, Codex, Cursor, Gemini, Kimi, Grok, Aider, OpenCode, Crush, and Goose.
Although the harness is identical everywhere, the way you start it differs a little by surface — because each AI has its own front door. There are three patterns, and that is the whole list. Some assistants give you slash-commands you type. Some you drive headless, from the command line, with a prompt. And some simply read the skill file as context and act on it. Same engine in all three; just three ways to turn the key.
Pattern A · slash-commands
You type a command and the skill takes over. This is the richest front door — it is where the loop, Forge, and the fusion panel are first-class commands.
# drive the whole harness by name
/loop-engineering
/fusion-3
/fusion-opus4.8
Pattern B · headless prompt
No slash menu — you hand the assistant a prompt from the command line and it runs unattended. This is how the orchestrator delegates a unit of work to another model during an AFK run.
# run unattended with a prompt cli -p "run /loop-engineering on GOAL.md"
Pattern C · read SKILL.md
These read the skill's SKILL.md as plain context and follow it. You point them at the file (or it is already in their skills path) and ask them to run the loop; the instructions do the rest.
# the skill is just context they read read SKILL.md → follow the loop
The pattern is a property of the agent, not the harness. Claude Code has a plugin system that turns a skill into a registered slash-command, so /loop-engineering and the /fusion-* panel appear in its menu. Headless CLIs (Codex, Kimi, Grok) expose a -p/prompt flag for non-interactive runs — ideal for an orchestrator that spawns workers with cli -p "…". The remaining agents have no command registry, so they consume the same SKILL.md as ordinary context. Because the underlying instructions are identical, all three roads lead to the same loop behaviour.
During an AFK run, the top model acts as orchestrator and delegates bounded units to other models precisely through Pattern B — cli -p — while the validator (never the builder) checks the result. The human is never in this path; they only read LOOP-LOG.md / review.md for observability, exactly as taught in lessons 5 and the Forge flow.
Here is the idea made tangible. Whichever front door you use, what you actually send the AI is a small, structured prompt — a few choices assembled into instructions. Below is a live tuner: turn the knobs on the left (which agent, how much it runs on its own, what it should produce, whether to publish) and watch the exact prompt the harness would carry rebuild itself on the right. The point to feel is that the same assembled instruction works identically no matter which assistant receives it.
This is also a faithful little model of how the harness thinks: your choices are inputs, one builder turns them into a single instruction, and the instruction is what travels. Change a knob, see precisely the words that move.
Every control writes into a shared state object (agent, autonomy, goal, publish) and calls render(). The preview is whatever buildParts(state) returns — nothing writes to it directly. Because the builder is pure (same state in, same string out), the instruction is reproducible, and only the line you changed flashes. Swap agent and notice the harness command line stays identical: that is "install once, behave the same everywhere" in miniature.
Agent uses real <button aria-pressed> toggles; autonomy is a native <input type="range"> with aria-describedby on its readout; the preview is an aria-live="polite" region so a screen reader announces each rebuild without stealing focus. Free-text is escaped before it touches the DOM.
Now the whole thing in motion. You start with a rough idea — barely more than a sentence. The harness turns it into something shippable through a fixed sequence of beats, and the human watches from the dashboard rather than steering each turn. Here is the journey, top to bottom.
Think of it like… dropping off a vague brief at a workshop and coming back to a finished, packaged product. The workshop has a standing process — clarify the brief, do the work in small checked passes, test it for real, write the manual, ship it — and a front desk that only calls you when a genuine decision needs your signature. You don't operate the machines; you read the progress board and approve the one thing only you can.
Start
A rough idea
You hand over one loose sentence — "teach my team how the harness works," say. Vague is fine; sharpening it is the next beat's job.
Forge
Idea → measurable scope
Because the idea is raw, the Forge front-end runs first: it grills the idea, optionally researches, then writes a GOAL.md with a done-when a verifier could check, and breaks the work into issues. No work starts until "done" is measurable.
Loop
One bounded unit per pass
The loop takes over: learn → analyze → execute one unit → verify → improve, repeating. Each pass changes exactly one thing and is small enough to check. The orchestrator may delegate units to other models headlessly.
Proof
Verify at the real boundary
Every pass ends at the Proof Gate: the check runs against the real thing — the test actually executes, the page actually loads — never a claim or a mock. If it fails, the loop keeps going; it cannot declare success on a guess.
Course
Turn the result into a course
When the goal converges, visual-teach builds a self-contained course explaining what was made — multi-lesson, beautiful, and bilingual (EN + PT-BR), exactly like the page you are reading.
Publish
Ship it and report the URL
The Publish Gate pushes the finished course to a private (secret) gist and reports the link back. The repository's course/ stays the canonical home; the gist is a flat, shareable copy.
Forge is the 7-step front-end (grill → research → prototype → to-prd → issues + GOAL.md → implement → review) covered in lesson 4. The loop and its learn/analyze/execute/verify/improve cycle are lessons 2 and 3; the Proof Gate's "real boundary, never a claim" rule is the spine of lesson 3. The course engine is visual-teach (lesson 10), and the Publish Gate (lesson 11) runs publish-course-gist.js to flatten the tree, rewrite internal links, and gh gist create a secret gist.
Nothing operational. Everything runs AFK; the human has observability only — they read LOOP-LOG.md, review.md, and status. Even QA is an agent (and never the same agent that built the unit). The single time the run reaches for the human is a deliberate fork, which is the next section.
A run this autonomous needs exactly one escape hatch: a moment where only a human can decide. The harness calls it a handoff. It is rare and it is specific — the run reaches a genuine fork it is not authorized to settle (a destructive action, a scope question, a call that needs your judgment), so it stops, writes down everything needed to decide, and waits. It does not guess past you, and it does not pester you for routine work.
Crucially, the handoff is decision-ready. When it pauses, it hands you a tidy summary — what is done, what is blocked, the options, and its own recommendation — so you can answer in one move and let it run on. You are never asked to operate the machinery; you are asked, once, to make the human call.
Think of it like… a trusted contractor renovating your kitchen while you are at work. They handle everything in the plan without calling. But if they open a wall and find a pipe that wasn't on the drawings, they stop, photograph it, lay out two options with a recommendation, and text you — because moving a water line is your decision, not theirs. One clear question, then back to work.
For all the machinery underneath, the human's surface is small on purpose. There is a short page called USAGE.md — the cheat-sheet — that tells you the handful of things you actually do: how to kick off a run, where to watch it, and how to read the result. That is the entire human interface. You do not memorize the loop; you read this and let the harness do the rest.
# 1 · install once (per machine) cp -R skills/* ~/.claude/skills/ bash install-agent-skills.sh # 2 · start a run from a rough idea (raw idea → Forge runs first) /loop-engineering # in Claude Code, or: cli -p "run /loop-engineering" # 3 · watch from the dashboard (you never operate, only observe) cat LOOP-LOG.md # progress, pass by pass cat review.md # the QA agent's observability report # 4 · collect the result # the run reports the private gist URL of the finished course
USAGE.md sits at the root of the suite next to install-agent-skills.sh; open it with cat USAGE.md or any viewer. Start a run by invoking /loop-engineering in Claude Code, or headlessly with cli -p "run /loop-engineering on GOAL.md" for the CLI agents. While it runs, the only files you need are the live logs — LOOP-LOG.md for pass-by-pass progress and review.md for the QA agent's report. You operate nothing else; that is the design.
Humans read this cheat-sheet and approve the rare handoff. The LLM drives the run and delivers the result, the course, and the published URL. The agents are interchangeable because the harness is identical on every one of them — which is the whole reason a single cheat-sheet works no matter which assistant you opened.
Three quick questions to lock in the lesson. Pick an answer on each; you will get instant feedback and a short why.
Q1What does bash install-agent-skills.sh do after the copy step?
Q2You are working in Cursor, not Claude Code. How does it invoke the harness?
Q3During an AFK run, when does the harness stop to involve the human?
/loop-engineering on a small idea of your own, watch LOOP-LOG.md as it goes, and read the course it publishes at the end. That is the loop engineering suite, in your hands.