4.2 The Skills

A method only helps while someone remembers to apply it. Left as prose in a book, it has to be re-taught to every fresh agent and every new project by hand, and a discipline that lives in memory rather than in the environment is the first thing velocity drops. So a book of method ought to ship with batteries, and this one does. There is a repository that goes with it, and it contains three Claude skills you can install and use today: self-operate, self-governance, and self-communicate. Each is the methodology of the preceding chapters, packaged as something an agent triggers and follows. This chapter walks all three.

These are an unusual kind of skill. You have probably seen plenty of tool-skills — a skill that teaches the model an interface: to do XYZ with this MCP server or CLI, here is the shape of the call. What follows is a different animal: a mastery-skill, which installs a body of knowledge and the judgment to do a whole task well — not an interface to one tool, but a way of doing the work. That is why the three below take a chapter to walk, where a tool-skill would take a paragraph.

Two kinds of skill. A tool-skill teaches an interface — the calls, flags, and shapes for operating one tool (an MCP server, a CLI, an API). A mastery-skill installs a knowledge-base and the judgment for doing a task well, independent of any single tool. This book's three skills are mastery-skills; Appendix E is the full recipe for building one.

The three are complements: one hardens the fleet, one runs it, one explains it — the same system seen from three angles, drawn in Figure 4.2-1.

4.2.1 Self-operate: the lifecycles, made runnable

Self-operate is the starting point, because it holds the lifecycles of running a repo — everything an engineering team actually does. Pull a ticket and build a feature. Pull a ticket and fix a bug. Optimize the codebase. Handle resource exhaustion. Each of those is written down as a model — I did say models everywhere, and I meant it — because that is how you constrain the agent's search and bias it toward doing the work the way you want.

Learn more about this governance mechanism: self-operate (operator runbook skill).

On top of the models sit the playbooks, and there is a playbook for everything, each with briefs for its judgment steps. This is what lets an orchestrator agent — itself running as a reactive loop — know how to respond when an event arrives. An agent finished? Reach for the next step: agent landed. Is the feature done? Open the Epic file, which lists the launches needed to complete it, and check. Not done — launch the next item. Done — run the definition-of-done audit over the whole Epic, the one that asks, among other things, whether the model drifted from the code. Passes — mark it done and move it to the closed pile. Still active — record the status and the commit that made progress, and launch the next agent from the Epic's list. The playbook keeps the loop turning on inputs from the environment, which is precisely the dispatch → work → land → tombstone lifecycle from Loops and Models, now written down for the operator to run.

That definition-of-done audit exists because of one hard-won rule.

"Done" is a claim, not a fact.

An agent reporting a task complete is describing its intent, not the state of your repository, and the two drift apart constantly — a sibling change broke a test, a marker rotted, the thing it "verified" quietly routed through a fallback. So you do not trust the claim. You re-run the gates yourself, at HEAD, and let a fact answer where a claim was offered.

That rule is one of several the skill teaches. Three worth quoting, because they show the shape of the whole:

Self-operate — three principles

• Determinize the runnable, brief the judgment. A runbook step is one of three kinds. If a machine can do it, make it a runnable line. If it needs judgment a brief can carry, write the brief. If it needs judgment no brief can carry, escalate. A runbook that blurs the three sends a human to do a machine's work, or a machine to make a human's call.
• The lifecycle is a state machine, not a habit. Dispatch, work, land, tombstone — an agent's life is a sequence of states with legal transitions, and you write it down as one. A habit lives in the operator's head and rots; a state machine names every state and the move out of it, so the loop turns on events from the environment instead of on memory.
• Orient positive before you hunt a break. Know the healthy baseline first — what "normal" looks like for each lifecycle. Most sessions are steady-state; you cannot recognize a break until you can state the shape it broke from.

4.2.2 Self-governance: the catalogue and the posture

The second skill, self-governance, triggers on a simple signal: a bad thing happened more than once — sometimes just once, if it was bad enough. Recurrence is the clue that you are either failing to detect the problem (you need a sensor) or failing to prevent it (you need a constraint, a wall). You have not put the wall in the right spot, or you have not put a badge reader on the door.

At its center is a catalogue of governance mechanisms and worked examples — around eighty at last count, and still growing as new failures surface new mechanisms. I did not know these were the mechanisms I would need until I started building and kept hitting failures; the higher the velocity rose, the more failures appeared, and new kinds of failure with them, and each mechanism I invented to kill one went into the catalogue. The hope is that this becomes ex-ante governance for you: the mistakes I made and solved, you inherit for free — install it and say "audit my codebase and help me find room for governance." You will, of course, find your own failures too, because you run a different model, different constraints, different customers, different operators, and all of it shapes your agent's behavior. So the skill ships not just the catalogue but a posture — the heuristics for minting new mechanisms well.

Where do the minted rules live? In a project's CLAUDE.md — the one document loaded into every agent's boot context, so it is where governance either binds or does not. Its structure is three parts, coarse to fine. First a Mission: what the project optimizes for, the values that break a tie. Then a portable method: the engineering principles that hold across any project of this kind, independent of the domain. Then the numbered project rules: the specific, stably-numbered guardrails this codebase enforces, each a one-line boot-context statement pointing at the deeper doc that carries it in full. Mission orients, the method teaches judgment, the rules bind — and a self-governance skill grows the third part as failures earn new rules. If you want a scaffold to start your own, the CLAUDE.md rule index appendix ships a CLAUDE-starter download built from a real, mature one.

The posture: minting new mechanisms well

The first heuristic is to avoid a teetering tower of governance. Do too much of this and you end up in trouble: so much code governing and constraining the behavior that tending the tower becomes the work itself. The failure has a specific shape. The agent starts spending its time patching and fixing the guardrails — was that even a mistake? — instead of doing the work you actually want. It side-quests off into optimizing the linter's behavior over here while the product you meant to build waits over there. So part of your judgment as the operator, as you construct the governed environment, is to watch for exactly this: are we making high-velocity progress in the direction we want, or have we wandered off to polish a guardrail nobody asked for? Finding the sweet spot is your judgment, and no mechanism makes it for you. Ask how detailed the check should really be. Is this generic or specific — do you need a lint for "never type the word X"? Almost certainly the wrong level, but a lint that blocks typing anything is worse. Decide whether false positives or false negatives hurt you more, because that governs which mechanism fits. And when you say "this must never happen," you are choosing architecture — a wall — and every wall constrains the model. A well-placed wall is pure gain. A wall across the only fire exit is a disaster the day there is a fire and no one can get to work. Because of this, the skill will not silently enforce a mechanism without checking with you — you are the engineer who knows the context. Its own trigger is a sensor at the right semantic level: a hook that fires every thirty minutes or so in the orchestrator loop and asks, "since I last checked, did we hit any recurring failure, or solve one problem several different ways?" Solving it several ways is a don't-repeat-yourself smell in the code; hitting the same process wall repeatedly — "I failed to create a VM," again — is a process smell. At agentic velocity you cover enormous ground in thirty minutes, so a repeat inside that window is the signal that a mechanism is owed.

The move generalizes. A skill on its own is passive: it sits there and waits to be invoked, and an agent heads-down in the work will not stop to invoke it. The hook is what brings it to life — kaizen on a timer, the improvement loop from The Engineer's Seat run without waiting for a human to notice the recurrence. The timer fires, the prompt lands, and the skill runs — it reaches into its catalogue of every way you might handle this class of failure and, usually, just fixes it. When it cannot decide, it surfaces the fork — "we keep hitting this; here are two ideas, which should I try?" — and waits. That hand-off is deliberate: the hook makes the reflection happen, the catalogue supplies the options, and the judgment call stays yours.

Learn more about this governance mechanism: reflection-facet substrate.

Underneath the posture sit a few reflexes the skill applies on every touch. Three of them:

Self-governance — three principles

• Convert, don't just repair — audit becomes lint. When a failure smells class-level, do not only patch the instance. Build the durable mechanism that kills the class. Today's audit finding — a thing you noticed by reading — is tomorrow's lint, a thing the machine notices for you. A bug in more than one file means "fix the sites and add the check," not "fix the sites and hope."
• Guidance aims; machinery holds. A mechanism is soft or hard. A soft one — a brief, a house-rule — can aim a probabilistic agent but cannot block it, and it rots. A hard one — a lint, a gate, a typed seam — holds the line regardless of whether the agent cooperates. Know which you are minting, and never claim a mechanism is enforced when you have only recommended it.
• Architecture before sensors. Prefer making the error impossible over catching it after. A structured model with one sanctioned seam beats a validator that scolds you for using the wrong one. Where a failure is costly, do both — belt-and-suspenders is a feature. But reach for the wall first, and remember that every wall you raise also constrains the agent, so place it with care.

4.2.3 Self-communicate: how the agent writes and draws

The third skill, self-communicate, governs how the agent explains itself — to you and to other people. Docs are a soft mechanism for an agent, but they are a genuine tool for humans, so the skill carries guidance on the kinds of technical documentation, crediting the Diátaxis project for enumerating them and the Apache Foundation for the exemplars it learns style and voice from. It targets prose that avoids imprecise claims and the grating verbal tics, and that is as terse as it can be without losing the reader. When the agent writes, it turns here. When it needs a drawing, the skill says "use me," and teaches drawing in Mermaid — dropping to HTML or SVG only when Mermaid cannot express the shape. That keeps the agent from trying to hand-generate raw PNGs, a thing it will attempt and be bad at.

The lexicon: one concept, one word

Self-communicate also owns a lexicon: the house vocabulary for your repo, so one concept gets one word, used consistently. You can bootstrap it — point the skill at existing material and have it walk the repository, surface the terms you use with specific meaning, and write down the working definitions. That walk tends to catch two failures at once: different words for the same concept, and the same word for different concepts. Both confuse any reader, human or agent, and finding them may show you mistakes in your own thinking. "There are actually two concepts here — help me name them." Now they have names, and you can retrofit structure onto the writing — which is, exactly, the code problem from Brownfield, wearing different clothes.

The lexicon is one specialization of a stance the skill carries into both legs. Three of its principles govern the whole:

Self-communicate — three principles

• Less is more — the representation must not distract from the idea. In prose that means Hemingway: cut the fluffy adjective, the qualifier, the sentence that restates the last one. In drawing it means Tufte's data-ink ratio and Picasso's Bull — strip the chartjunk, the gradients and bevels that decorate without informing, until only the marks that carry the idea remain.
• Name the concept, then use the name. A name is a handle: it carries a concept's meaning and its constraints in one token. In prose, reach for the established term — say "circuit breaker," not a fresh paragraph re-deriving one. In drawing, reach for the format's native construct — an SVG <marker> with orient="auto" is an arrowhead; it rotates to its line and pins to the endpoint, so it cannot land crooked the way a hand-stitched triangle can. Use the marker.
• Decide the doc's mode before its sentences. A doc is a tutorial, a how-to, a reference, or an explanation — the four Diátaxis shapes — and it is exactly one of them. A how-to written as an explanation confuses the reader who wanted steps. Fix the shape first; the prose follows.

Those are the three skills that ship with the book. I hope they are of use.

4.2.4 The construction recipe is a pattern of its own

The three feel of a piece because they were all built the same way. Three layers, every time. A base model of the domain at the bottom. Orthogonal models layered on top — cuts through the base along independent axes, each adding a dimension without disturbing the others. And a top-level SKILL.md of principles that ties the models together and tells the agent when to reach for which. Set the three skills side by side along those layers and the shared skeleton shows through.

self-operate — the operate leg, by layer in Table 4.2-1.

self-governance — the harden leg, by layer in Table 4.2-2.

self-communicate — the communicate leg, by layer in Table 4.2-3.

Once you see it laid out, it reads as obvious — of course that is how you build one. Figure 4.2-2 draws the shared skeleton.

Appendix E draws the recipe out step by step, with self-operate, self-governance, and self-communicate as its three worked examples — so the payoff of seeing the shape here is a working procedure there.

Left for later: the team dimension. This book is written as "you and your agents," but production software is built by teams, and the team dimension is its own chapter. A model that governs one person's work has to become a shared artifact — reviewed, owned, and defended by more than its author. Review changes shape when an agent wrote the diff: who reads it, and against what. And when a model drifts, someone has to own the reconciliation. Those are real questions with real answers, and they are not this book's. This is a field report and a method, not a survey of team practice, so I mark the boundary here rather than gesture past it.