A harness is ultimately files and scripts, so Claude can build it. But there is an order: have it measure, propose, receive approval, and only then build. With example instructions you can use immediately.
§ 00 · A harness is code too
You need not create Part 02’s five files by hand. Harness components are text files and shell scripts, and producing those is precisely what the machine does well. Most harnesses in the workshops examined were made that way: a human set the direction, the machine built the files, and a human inspected them.
But order is everything. Simply say “Build me a harness” and the machine invents a plausible framework from things it has seen elsewhere. A harness made of conjecture is more dangerous than conjectural code: a code bug breaks one feature, but a rule bug misleads every future session. There is quantitative evidence too. One measurement found that fully machine-generated rulebooks reduced performance by 3%, because they contained only generalities such as “Keep the code clean”—taking up space without providing a signal. Good rules come from failures in this repository. The order must therefore be: measure what is in the repository; propose a plan in a table without creating files; obtain human approval; only then build.
§ 01 · Example instructions
Initial setup: “Measure this repository’s structure and risk points. Based on that evidence, propose ① a sixty-line draft of the constitution document, CLAUDE.md, and ② an agent roster with roles, tools to grant, tools to withhold and model tiers. Do not create files yet. Show tables only.” The final sentence is the key. Separating proposals from execution creates room for review.
Validation gate: “Create a skill requiring type checks, tests and a build before any completion claim, and a Git hook running the same three stages immediately before a push and blocking on failure. After creating them, deliberately introduce one type error, measure whether the hook actually rejects the push, and show the output.” Test-fire the new safeguard on the spot. This discipline arose after several workshops were found to contain devices that had been built but never once fired.
Transplantation: “Adapt that project’s completion-validation skill to this repository. Record the original source and your changes in a comment at the top of the file.” Scripts in the examined workshops really do have such source notes at their tops. That is how the lineage of tested parts continues.
And the common ending to every instruction: “Do not report that you built it. Attach output from measuring it in operation.” That sentence is half the instruction.
§ 02 · Do not delegate approval
Even when harness construction is delegated, one thing must remain with you: approval. The largest workshop examined encodes this structurally. A hook blocks the machine from directly editing the harness folder and forces delegation to a dedicated worker; updates to rule documents must pass through a proposals folder and cannot be applied without user approval. The beast may build the cage. A human keeps the key.
Review for a beginner is not elaborate. Open the files yourself. Read them from beginning to end. If a line is unclear, paste it and ask: “What does this line do? What happens without it?” If the answer is unsatisfactory, have it removed. Only rules you have read and understood are yours. Rules you do not understand belong to the machine. They are decoration, not a harness.
Volume also requires approval. A machine can easily bloat a harness: producing ten workers and thirty skills in a day is trivial. The observations point the other way. Start small and add one part whenever an incident occurs. As Part 04 will show, most parts of a good harness are scars from actual incidents. A harness grown without scars does not fit the body.
§ 03 · Size it to the risk — absence is also a design choice
The harnesses in the nine workshops follow the scale of their risks. A payment-service workshop moving real money has fifty-seven sensors alone, covering payment idempotency, refund atomicity and secret leakage. A static promotional site has only one hook: a type check immediately after editing a file. Both are right. Harnesses have real costs; more checkpoints slow every commit. Excess harnessing in a low-risk project is friction, not safety.
The most striking observation was a line in one internal-tool workshop’s documentation: “Zero agents, zero hooks. Deliberately removed. User decision.” Having no components and deciding to have none and recording that decision are entirely different. The latter even prevents the next session’s machine from wrongly deciding, “Why are there no agents here? I should create some.” Documenting absence is harnessing too.
So choose your initial size this way: what is the most expensive thing this repository can damage? Money, reputation or your evening? Build only to the scale of that answer, and extend the rest when an incident arrives carrying the bill.
Read this note at sass.studio.