Start with the names of the parts.
Harnesses, agents, skills— and the rest.

Harness — the tack fitted to the machine

GLOSSARY · 2026

A harness was originally tack fitted to a horse. It does not destroy the horse’s strength; it connects that strength to a carriage and gives it direction. An AI harness does the same: a framework of rules, permissions, validation and records surrounding the model’s capabilities. Here is the equation used earlier in the Lubyanka series: agent = model + harness. The model is a borrowed brain I cannot change, but the harness is entirely in my hands.

The developer who coined the term gives a surprisingly modest definition: whenever the machine makes a mistake, build one more device that prevents it from making that mistake again. Those devices fall into four groups: reduce what it can do (restriction), tell it what it must do (information), check whether it did it correctly (validation), and correct it when wrong (correction). Every part in this manual belongs under one of those four pillars.

The physical form is modest: a folder in the repository and a few documents. Conventionally, the root holds a constitution document, CLAUDE.md—a rulebook read automatically every session. Inside the hidden .claude/ folder are worker definitions in agents/, procedures in skills/, automatic scripts in scripts/, and a wiring map, settings.json. They are all text files. You can open, read, edit and delete them.

Why files? Chat instructions evaporate when a session ends, while files remain. The constitution document is placed before the machine automatically whenever a new session opens. The same rules recur a hundred times across a hundred sessions, without a person typing them a hundred times. The first principle of harness engineering follows: if you want to say something only once, do not say it. Write it down.

Agent — a worker with a distinct role and permissions

GLOSSARY · 2026

An agent is a separate worker assigned a particular role. Again, it takes the form of a file: one Markdown document is one worker. Put four things in its frontmatter: its name (name), when to call it (description), the tools it may use (tools), and the model it will run (model). Write its role and prohibitions in the body.

If that feels abstract, try a thought experiment. An iPhone app, an Android app, a website and a server: suppose you conduct all four strands of a service through one chat. I guarantee the machine will do one of three things: forget work, edit the wrong place, or make a false report. Underneath lies its disposition to act like a competent assistant. Admitting failure at the outset would make it an incompetent assistant, so it chooses to lie. We therefore do what human organizations do. Apart from street vendors and one-person businesses, no company gives every job to one person. It hires staff, divides the work and assigns inspection to another department. Creating an agent is that hiring.

The most important of the four fields is the tool list, because the tool list is its authority. This was where I found the most beautiful design in the workshops examined: removing editing tools—Edit and Write—entirely from a worker dedicated to validation. An inspector limited to reading and execution cannot cheat by secretly fixing a problem and reporting that it passed, even if it wants to. Do not merely prohibit it with rules; make it structurally impossible. That principle runs through this entire manual.

The same staffing pattern also recurs in the observations: a planner who writes specifications but cannot code; an implementer who works only from approved specifications; a validator who cannot change code and only reports; and domain guardians, such as a keeper of the visual canon or a cost accountant. The key is separation, not headcount: the hands that plan, build and inspect reside in different files with different permissions.

Skill — a procedure fixed in a file

GLOSSARY · 2026

A skill fixes a recurring procedure in a document. One folder, one SKILL.md: put its name and activation condition at the top, then the step-by-step procedure and prohibitions in the body. If the agent answers “who does it,” the skill answers “in what order.”

Continue the company analogy. If an agent is a hire, a skill is the company’s operating handbook. A company whose report quality survives new hires relies on procedures rather than individuals. Here is what activation looks like: the moment the machine types “All done,” that verbal habit becomes the trigger for the procedure to intervene. Did you run the build? Attach the output? Avoid using yesterday’s result as today’s evidence? Until those three boxes are filled, it cannot finish saying “complete.” That behavioral correction is the essence of a skill. The machine has been trained to answer that it is done. Since the verbal habit itself cannot be repaired, place a checkpoint on its route.

If you think it should know to do that on its own, picture a cockpit. Even a captain with 20,000 flight hours reads the preflight checklist aloud. The checklist exists not because expertise is doubted, but because even experts omit things on some days. A skill is the same. And this procedure is physically just a ten-line text file: one name, a few trigger phrases such as “All done” and “Everything passed,” and three checks. That is all.

The four most frequently transplanted skills in the nine workshops form a de facto standard. First, the completion gate activates immediately before “All done” and demands observed evidence. Second, systematic debugging prohibits speculative patches and enforces reproduction, isolation and hypothesis testing. Third, orchestration judgment uses criteria to decide whether to work directly or delegate. Fourth, domain inspection measures the screens, policies and consistency specific to that workshop.

Open the actual workshops and you will also see departments named on the handbooks. The completion gate’s cover says “Owner: inspector”; the deployment procedure says “Owner: infrastructure worker.” Some handbooks are shared, but most sit on the desk of the worker responsible for that procedure. If agents are hires and skills are procedures, a good harness is a company where every procedure has an owner.

The remaining parts — hooks, sensors, gates, memory and the canon

GLOSSARY · 2026

A hook is a script that runs automatically at a defined moment: when a session opens, when a user sends a prompt, immediately after the machine edits a file, or when the session closes. Scripts wired to those moments run without human intervention. The overwhelming majority of observed hooks do not block anything. They merely feed warnings onto the screen. The next two parts do the biting.

A sensor measures state. It actually runs type checks, tests and builds and produces numbers instead of words: exit code 0 means pass; anything else means failure. A gate is a checkpoint that uses those numbers to block the path. Git hooks are a typical example: sensors run just before a commit or push, and a failure rejects the commit itself. However often the machine says “No problems,” the gate does not read sentences. It reads numbers.

Memory is recollection between sessions. At the end of a session, record the day’s work and decisions in a file; the next session reads it and takes over. The canon follows one rule: record each fact in only one place. Put the same fact in three documents and they inevitably begin to diverge—decay confirmed in the observations—and divergent documents mislead the machine. Parts 02 and 04 show how to build these components.

Why everything is not loaded at once

GLOSSARY · 2026

One misconception before closing this glossary: it is easy to imagine that assigning work loads every agent and every skill into the machine’s head. It does not, and should not. Normally the machine sees only a list: workers’ names and one-line descriptions; procedures’ names and one-line descriptions. The full body opens only when that worker is actually summoned or that procedure actually activates. Picture a library: the books stay on the shelves, and only the book being read sits on the desk.

Why? First, attention. There is a limit to the instructions a machine can digest at once. It has already been measured: with ten rules it follows most of them; with a hundred it loses track of what matters. If deployment procedures, debugging rules and visual checklists are all open during an unrelated translation task, that pile buries the one crucial line. The more books on the desk, the harder it is to focus on the current sentence.

Second, cost. Every character placed before the machine is charged for—again, every time. Reloading thirty entire unused procedures on every session turn is like copying and distributing every employee’s manual at every meeting. Third, isolation. The tens of thousands of lines of intermediate output a worker generates while searching materials stay at that worker’s desk; only a one-page summary returns to the main conversation. Put everyone at one desk and that firewall disappears.

There are two practical consequences. First, the one-line description on the list is effectively the call button. The machine decides whether to summon a worker from that line alone, so it must state an activation condition, such as “Validate a completion claim; judge only, do not edit code,” rather than empty praise like “a useful helper.” Second, do not leave mandatory procedures such as the completion gate entirely to the machine’s judgment. A structure that lets it choose what to read also lets it choose not to read. Give procedures that cannot be missed the separate trigger from Part 04: a hook that catches the verbal habit.