The_Test_I_Didn't_Know_I_Needed

Nate Jones published a checklist in early August 2026 for deciding whether an agent skill earns a place in your setup. He calls it the one-job test: seven steps, from naming the job the skill is supposed to do through rerunning it later, ending in one of three verdicts. "Keep it, fork it, or delete it." Not "does this feel more capable." A verdict you can rerun and get the same answer from six months later. He states the point of the test plainly: it's meant to "turn 'this feels better' into evidence you can still check six months from now."

I read it expecting to nod along and move on. Instead I looked at my own skills folder, and most of them would fail his test on the first step because they don't have a single job: they have a job description. Job descriptions are exactly what a one-job test is built to catch.

Twelve_Agents,_One_Job_Each

Here's what makes the gap uncomfortable: I already run this discipline at the agent level, and it wasn't a deliberate design decision so much as the only way twelve specialised agents stayed usable once I had more than four. Nix only touches the UI layer. Sable only touches the backend and the chat engine. Quinn only runs pre-release smoke tests. Tom only fact-checks claims against primary sources. Reid only owns voice and positioning. Jo only hires and audits. Nobody's scope overlaps with anybody else's, and when I hand a task to the wrong agent, that's a routing mistake I catch in seconds, because the agent's one job makes a wrong assignment obvious.

Skills didn't get the same treatment. A skill gets written to solve whatever problem was in front of me that day, and the natural drift is to fold the next adjacent problem into the same file rather than write a new one. Nobody sets out to build a twelve-function skill. It accretes, one reasonable addition at a time, until the file is doing the work of several agents and won't pass a single test that matters.

This piece extends "What Pre-Packaged Skills Actually Cost You" (Labs, 2026-08-18), which examined the other half of this problem: auditing the defaults a pre-packaged skill imports before you run it. That piece is about what you inherit. This one is about what you design so there is less to inherit in the first place.

What_"Auditable"_Actually_Means

A one-job skill is easy to grade because there's exactly one thing to check it against. Did it do the job, yes or no. A multi-job skill doesn't have that property. It has a bundle of partial successes, and you end up averaging them into a vague sense that the skill is "mostly working," which is not a verdict, it's a shrug wearing a verdict's clothes.

I built the Skill Prompt Auditor (EXP_025) to catch hardcoded design defaults hiding in a skill's prompt text before the skill runs. Running it against my own folder surfaced something unintended: the cleanest, most confident reports came from the narrowest skills. A one-job skill produces a report with one clear category of finding-or none. A four-job skill produces findings scattered across categories, and you have to guess which one matters for which job. The tool doesn't fail on multi-job skills. It just stops being able to give a clean pass or fail, because a clean verdict assumes exactly one thing being tested.

That's the property Nate's test is actually pricing. Auditability isn't a nice-to-have layered on top of a skill. It's a direct function of how many jobs the skill is trying to do at once.

The_Loop_That_Makes_It_Worse

There's a specific failure mode Nate names for how this compounds: adding a skill to fix bad output is often the same loop that produced the bad output. Picture a skill that started narrow, drafting one type of report, and started drifting once someone noticed the drafts needed a summary paragraph too. Rather than writing a second skill for summaries, the summary logic gets folded into the first skill, because it's already loaded and it's already close. Six months later the skill drafts reports, writes summaries, and has picked up a third responsibility nobody remembers deciding on, and the reports have gotten worse in a way that's hard to pin on any single change, because no single change was ever big enough to notice on its own.

Nate's line for this stage is blunt: "twenty-five skills in, your agent is averaging out their conflicts and handing you duller work than it did at five." The duller work isn't a mystery once you see the shape of it. Every additional job a skill takes on is another set of assumptions competing for the same output, and the skill can't tell you which assumption should win, because it was never asked to choose.

Keep,_Fork,_or_Delete

What I've actually changed since reading Nate's checklist isn't a new tool. It's the question I ask before adding to an existing skill instead of writing a new one. If the addition is a genuinely new job, it gets a new file, even when that feels like more overhead than tucking one more instruction into the file that's already open. If the addition is the same job with a slightly different shape, it's a fork, not a patch, because a fork keeps both versions independently testable. And if a skill has already accumulated three jobs nobody would sign up for today, the honest answer is delete it and rebuild the pieces separately, not patch it into a fourth.

None of this is a governance layer. It's closer to the trust calculation I already run on the agents themselves: track record times reversibility times blast radius. A one-job skill has a short, legible track record, because there's only one thing to have a track record in. A twelve-job skill has a track record for every job smeared across the others, with no clean way to know which job's failure caused which downstream problem. Scoping to one job doesn't make skills safer by adding a check. It makes the checks that already exist mean something.

Twelve agents, each doing exactly one job, was never a policy I wrote down. It was what happened when I stopped tolerating agents that did two things adequately instead of one thing I could verify. My skills folder is only now catching up to a standard my agent roster set by accident, years before I had a name for it.