The build script that packed twenty-two agent skills into one installable plugin stopped on a file it could not decode. EBZ-SKILL_exact-math-verification_v1.2.md was not valid UTF-8. Four bytes — EF B7 9D E5, a Unicode noncharacter followed by a loose continuation byte — sat where the arrow in symbolic↔numeric checks should have been. They had been sitting there since 24 July.
That file had already been through the judge, an independent QA reader, a systematic second pass, and live execution against real input. Four control layers, six weeks, and the file would have crashed any parser that read it strictly.
What we thought a set of agent skills was
We thought the work lived in the individual files. Each one answers a single concrete question, states the conditions under which it must not fire, and ends in a checkpoint a third party can re-derive. Write twenty-two of those and you have a library. That was the assumption, and it is only half true.
A standalone procedure for an agent is easy to write and easy to ignore. It sits in a folder being correct. What decides whether it ever runs is not its quality but three things outside it: whether it obeys the same rules as everything around it, whether it knows where its neighbours end, and whether its description is sharp enough that the right file fires at the right moment. Twenty-two good files with twenty-two private conventions is a folder, not a set.
The four rules that repeat in all twenty-two
The rules are not style guidance. They are the reason a reader who has used one file can predict what the next one will do, and the reason the set can be reasoned about as a single thing.
- A success status is not evidence. Any step claiming something landed reads the state back from the place that owns it.
- Guards detect on form or size — a count, a byte range, a computed style, a difference in whole minor units — never on a green check.
- Loops carry a budget and an exit. A recovery path with no maximum is a hang wearing a recovery’s clothes.
- Done means validated, not produced.
Each of those was bought with an incident. A write that returned 200 and destroyed a published article body. A judge that scored a truncated file five out of five. A factory that published 270 pages and earned four clicks. Repeating them across the set is what turns one expensive lesson into a property of every file.
Seven pairs sit close enough to fire on each other
Skills load on demand, which means the description is the dispatcher. Nothing else decides. And several of these agent skills live near enough to their neighbours that a vague description makes both of them useless.
Consider the difference between review this finished change and decide whether this content goes live. Or between tighten this one draft without changing its meaning and audit everything already published. Those are different jobs with different exits, and a model reading two soft descriptions will pick the wrong one roughly half the time — then produce something plausible, because the wrong procedure still runs to completion. There are seven such pairs in this set. Every boundary is written into the descriptions deliberately, in both directions, so each file says what it is not as clearly as what it is.
This is the part that does not survive being written once and left alone. Add a twenty-third file and you have created new adjacencies you did not measure.
Why four gates never saw four bytes
Which brings the packaging defect back into focus. The judge read form: headings, section order, register. The QA reader read logic and contradictions. The second pass read what the first pass had introduced. Live execution read behaviour against real input. Every one of those layers received the file as text that some tool had already decoded, quietly substituting a replacement character and moving on. None of them ever held the file as bytes, so none of them could see a byte problem. The defect was not subtle. It was outside the question every gate was asking.
Packaging was simply the first operation that had to open the file in a mode where those four bytes mattered. It found the defect immediately — not because packaging is a better check, but because it was a different one.
What this means for anyone assembling agent skills
A gate finds only what it looks for. That sounds obvious and is routinely priced wrong: when something slips through, the reflex is to add another reviewer of the same kind, which buys nothing. Coverage comes from changing the mode of inspection, not the number of inspectors. Each genuinely new way of handling an artifact — decoding it, packing it, shipping it, unpacking it somewhere else, installing it into a runtime that was not yours — exposes a class of defect the previous handling was structurally unable to see.
So the packaging step is a control layer, and we now treat it as one. It also forces an uncomfortable disclosure: the earlier builds of this plugin, before the file was repaired, most likely carry the same corruption. We only know the current one is clean because it was unpacked into an empty tree and validated again after the fact rather than trusted on the strength of a successful build.
The runnable package — all twenty-two files, their disambiguated descriptions and the checkpoints each one ends in — lives in the member library.
How we know
Grounded in: our own packaging run for ebz-verified-ops v0.3.0, 4 September 2026, when 22 canonical skill files were converted into one installable plugin. Verified: EBZ-SKILL_exact-math-verification_v1.2.md failed a strict UTF-8 decode on four bytes present since 24 July and was repaired to v1.3; the built package was then unpacked into an empty tree and re-validated at 22 skills and 325,042 characters with no frontmatter deviations, 0 errors and 0 warnings. The runnable procedure lives in the member library.
Leave a Reply