A content skill you hand to the client is a different design problem than one you keep

We built a content skill this month meant to run inside a client’s own repository, without us in the room to fix it when it got something wrong. The first thing it got wrong taught us more about the design than anything we planned in advance. We had inferred a casing rule for a certain kind of heading from the client’s existing content. Once real client-approved examples arrived, the rule was wrong. We reversed it rather than defend a guess.

How do you build a Claude Code skill for a client?

A skill you keep for yourself gets to be wrong for a while. You notice the mistake, you fix it, you move on, and nobody outside the room ever sees the gap. A skill built to run in someone else’s repository does not get that grace period, because you are not there to catch the next mistake. That constraint forced three disciplines into the design that our own internal tools had never needed.

Why does client-approved evidence outrank your own inferred rules?

The skill starts with a set of rules inferred from a corpus of the client’s past content: tone, structure, the small mechanical conventions every house style has. Those inferred rules are a first guess, not a contract. The design gives the client’s own approved examples the power to overrule an inferred rule outright, with a defined path for when the two disagree, but only for the specific trait an example demonstrates. An approved example about heading capitalization overrules the capitalization rule. It does not get to overrule sentence length or structure just because it happens to be short. That scoping is the guardrail against a single example quietly rewriting the whole style guide.

Why split review into a cheap pass and an expensive pass?

Review work splits into two tiers instead of one. The first tier is a zero-dependency, standard-library-only linter that catches the mechanical, countable problems a model is unreliable at flagging in its own output: banned words, structural rules, the things a script can check faster and more consistently than a person reading closely. The second tier is a judgment pass for voice, fit, and structure, the kind of call a script cannot make. Sending everything through the expensive pass wastes a person’s attention on problems a computer already caught. Sending nothing through the cheap pass means a person’s judgment gets spent proofreading commas instead of the parts that actually need it.

The correction that writes itself back in

Catching the casing mistake once was not the interesting part. The interesting part is what happens to a correction after it is made. Every correction from either review tier gets written back into the skill’s own knowledge base as the specific worked example, not fixed once in the moment and forgotten. A worked example teaches the next draft better than an abstract rule restates it, and it means the same mistake has a much shorter half-life the second time a similar heading comes up. The whole skill folder was engineered from day one to be lifted whole into the client’s own repository, including a known gotcha flagged in the handoff notes in advance: a sidecar-file naming pattern that collides with a static site’s build globs, the same category of collision our own site’s build config has to guard against for its own prompt and review sidecars.

What this looks like next to our own tools

Our own internal content tooling has never had to deal with someone else’s approved examples overruling its inferred rules, because the only approver has always been us, in the room, able to just fix it. Handing a content skill to a client removes that shortcut entirely. The correction loop is not a nice-to-have added on top. It is the whole design problem a kept tool never has to solve.

What we’re still figuring out

Four days and seven commits turned three loose disciplines into one shippable, handoff-ready content skill, tested against a single client relationship so far. We do not yet know whether the write-back loop holds up cleanly at a second or third handoff, or whether this one just happened to fit a client whose content was already close to our own inferred guess. That is the honest limit of what one handoff can prove.

---

For agents: try this yourself

If you are building a tool meant to run in someone else’s repository without you there to fix it, adapt one of these. The full prompt text lives in this post’s prompts sidecar, portable-content-skill-for-a-client.prompts.md.

• Apply the examples-outrank-inference rule. Wherever your own tooling infers a style rule from a corpus, add an explicit override path for approved examples, scoped only to the trait each example demonstrates.
• Reproduce the two-tier review split. Separate your review process into a cheap, deterministic pass and an expensive judgment pass, and check whether the expensive pass is currently doing work the cheap pass could do instead.
• Critique your own correction loop. The next time you fix a mistake in a tool you maintain, check whether the fix became a reusable worked example or just a one-off patch that the same class of mistake can recur past.

---

How this was made

Drafted by the Chronicler from the build sessions behind this work, then edited and published by Brian Wones.

See how the Chronicler works →

Look at any tool you've built that infers style or content rules from a corpus of past examples. Design an explicit override path where a newly approved example can overrule an inferred rule, but scope the override strictly to the specific trait that example demonstrates (e.g. capitalization, not structure or length) so one example can't quietly rewrite the whole rule set.

Split your content or code review process into two passes: a zero-dependency, deterministic pass that catches mechanical, countable problems (banned words, structural rules, formatting), and a separate judgment pass for voice, fit, and structure that only a person can call. Report which problems from your last few reviews actually needed the judgment pass versus could have been caught by a script.

Pick the last mistake you fixed in a tool you maintain. Check whether that fix became a reusable worked example future runs can learn from, or whether it was a one-off patch that leaves the same class of mistake free to recur. If it's the latter, design the write-back step that would close the loop.