One skill now carries the whole harness — the loop plus eight embedded modules — so installing and distributing it means shipping all of it at once. What used to be a drawer of separate skills you found and installed one by one is now a single self-sufficient thing: you install loop-engineering, and the rest travels inside it.
Earlier in this course you met the parts of the harness one at a time — the loop, Forge, fusion, Council, the tools, visual-teach. It is easy to picture them as a drawer of separate skills: you open the drawer, find the one you need, install it, and keep the rest in their slots. That used to be true. It is not true anymore — and this is the single most important recent change.
Today there is exactly one skill: loop-engineering. Everything else lives inside it. Each capability that was once its own skill is now an embedded module within loop-engineering. You install one thing; it carries the rest. When the harness is distributed to an AI agent, the agent registers a single skill — and the loop, Forge, fusion, Council, visual-teach, ultragoal, the web tool, the desktop tool, and the machine-readable brief all travel along with it, automatically.
That is what "monolith" means here: not big and tangled, but self-sufficient and whole. The one skill carries its own method (the loop and gates), its own teaching (this very course engine), and its own setup (a script that installs and distributes it). It depends on no other skill. Nothing it needs lives somewhere else.
Think of it like… the difference between a drawer of loose tools and a single multi-tool. With the drawer, every job means hunting for the right wrench, and any one of them can go missing or fall out of date. The multi-tool has the pliers, the blade, the screwdriver, the file — all folded into one body you slip into one pocket. You carry one object; every tool is already with you. The harness is that multi-tool: one skill, eight tools folded in.
MODULE.md, not SKILL.mdAn agent's skill loader scans for skill manifests and registers each one as a top-level, separately-invocable skill. If every embedded capability still carried a SKILL.md, the loader would register eight extra skills — exactly the drawer-of-loose-tools situation we are leaving behind. The embedded entries are therefore named MODULE.md on purpose: the loader does not register them as their own skills, so it sees precisely one skill — loop-engineering — and the modules ride along inside it.
SKILL.md states it plainly: "This skill is self-sufficient: it carries the method, the teaching, and the setup." It "depends on no other skill". The method is the loop and its gates; the teaching is the embedded visual-teach engine; the setup is setup.sh. Install loop-engineering alone and everything else comes with it — there is no second skill to keep in sync.
Here is the whole shape on one canvas. The single skill is the large container; the eight embedded modules sit inside it. One script — setup.sh — distributes that one container, by symlink, into every agent's skills directory at once. Install once; it lands everywhere, modules and all.
setup.sh symlinks the whole container into ~12 agent directories — the embedded modules ride along.Here are the eight modules folded into the one skill. Click any chip to open its detail — what it is for, what it does, where its file lives, and how the harness reaches it. (This is a live demo: the first module is open by default; clicking another swaps the panel.)
module explorer · click a chip
forge
role · the rough-idea → measurable-scope front-end
The way in when the request is a vague "I want…" rather than a spec. It runs seven steps — grill → research → prototype → PRD → issues + /goal → implement → review — turning a fuzzy idea into a finish line the loop can test against. It is the most-internalized module: native from the start, never a separate skill; its sub-methods (grill, research, prototype, and the rest) live in the harness's own words inside forge/.
fusion
role · panel → judge for hard or high-stakes forks
Fans one prompt to N models in parallel, each blind to the others; then Opus 4.8 judges their answers into consensus, contradictions, and blind-spots, plus a grounded final. For code it does run-both-and-merge — it runs both candidates and merges the verified result. Use it on a genuinely hard decision fork, or as a high-confidence Validator at the Proof Gate instead of a single check.
council
role · the heavyweight multi-model board
The configured board for doctrine-level decisions — members vote → score → synthesis → verdict. It is the heavier sibling of fusion: where fusion is a fast blind panel, Council is a defined board of members with roles and weights, used for the biggest calls or as a consensus Validator.
visual-teach
role · the course engine (the Course Gate)
The engine that built this very course. It produces self-contained interactive HTML — one byte-identical shared shell across lessons, built-in dark mode, 20 demo types, a Simple↔Technical toggle on every section — in both EN and PT-BR (prose translated; code and commands kept verbatim). It is what fires on convergence to teach the result.
ultragoal
role · the durable, verifiable-goal discipline
The discipline behind a goal that holds up over a long run: an observable finish line, a verifier that can fail at the real boundary, anti-cheating, approval gates, and a red-team pass before the goal is activated. It compiles GOAL.md — the contract the loop tests against — and Forge's /goal step applies it inline.
brightdata-cli
role · the web tool
How the harness reaches the live web: search / scrape / browser / pipelines, with 40+ structured datasets behind the pipelines. The rule is absolute — when the harness needs real, current web evidence it uses this, always; never WebSearch, WebFetch, or an MCP.
computer-use-cli
role · native macOS UI automation
How the harness drives a desktop app when a task lives in native macOS UI. It works through the accessibility tree — click, type, drag, move the cursor — and proves its actions by re-reading the app state. Reach for it when the work cannot be done over the web or a CLI.
harness-brief
role · the machine-readable twin of this course
A dense, English-only, top-to-bottom brief of the whole harness for an LLM or agent to read and get full context fast — delegation, fusion, Council, the tools, the publish gates. It is the machine counterpart to this human course: same harness, two audiences, two artifacts.
Folding everything into one skill is not tidiness for its own sake — it removes a whole class of problems that a drawer of separate skills creates. The reasons are plain:
You install one thing. The single skill is self-sufficient — it carries the method, the teaching, and the setup.sh that installs it, so there is nothing else to fetch. There is one source of truth: no per-skill copy drifting out of sync, no version mismatch between a skill and the tool it depends on. There are no inter-skill dependencies to break — the monolith depends on no other skill. And because it travels as a single unit, it arrives intact at every agent: the same capability set is everywhere, so a unit that runs on Claude Code can run identically on Codex, Kimi, or Grok. Two modules earn a special note: Forge is native — it was internalized from the start, never a separate skill — and harness-brief is the machine-readable twin of the very course you are reading.
MODULE.md rename is load-bearingIf the embedded entries kept SKILL.md names, the agent's loader would register eight extra top-level skills — re-creating the loose-tools drawer the monolith exists to remove. Naming them MODULE.md is exactly what keeps the loader from registering them as their own skills, so it sees one skill: loop-engineering.
setup.sh symlinks the one monolith skill into roughly twelve agent directories from the canonical ~/.claude/skills/. Because the modules are nested inside the skill directory, the symlink carries them automatically — distributing the skill is distributing every module. The script is idempotent (only symlinks and reads), so re-running after adding an agent or editing a module is safe.
The harness used to be a suite of separate skills. It is now one self-sufficient monolith — loop-engineering — with everything embedded inside it. You install one thing; it carries the method, the teaching, the setup, and eight modules, and it distributes as a single unit to every agent at once.
The one rule
One skill, eight embedded modules (forge · fusion · council · visual-teach · ultragoal · brightdata-cli · computer-use-cli · harness-brief), distributed as a unit. Install loop-engineering and the whole harness travels with it.
setup.sh lands all eight on your machine? Ask. Next up — the guide, and every use case mapped to its modules and commands: The guide, and every use case mapped.