On Terminal Bench 2.0, Claude Opus 4.6 running inside Claude Code scored far lower than the exact same model running in a custom harness. Viv Trivedy's team took a coding agent from Top 30 to Top 5 by changing nothing but the scaffolding around the model.
Same weights. Same task. Different craft.
That number is the whole argument. If model quality were the bottleneck, it could not move that far without touching the model. So something else is.
If model quality were the bottleneck, it could not move that far without touching the model. So something else is.
Last week we looked at DESIGN.md and the discipline of authoring a single file of context well — how much behavior you can steer with one carefully written document. This week the file becomes a fleet, and the failure modes get structural.
Angie Jones gave a talk called "Skill Issue: Why Your AI Agent Still Sucks." Treat the title as a diagnosis, not a joke. "Skill issue" is a gamer's taunt — you lost because you're bad, not because the game is broken — and the harness crowd appears to have turned it into a technical claim.
The claim is this: the fault is in the authoring, not the weights. HumanLayer puts it flatly — "it's not a model problem. It's a configuration problem." The failure is legible, and it's yours.
Addy Osmani calls the delta between what models can do and what you see them doing "the harness gap." The Terminal Bench number is what that gap looks like when you measure it.
So the interesting question stops being "which model" and becomes "what did you build around it." And once you accept that, a set of craft rules comes into focus — each one a deliberate structural decision, not a plea for a smarter model.
Start with the most counterintuitive. Jones: "Your description is the bait. An agent won't load a skill until it needs it to not pollute the context window. You have to be very thoughtful about the description."
Read that carefully, because it inverts how most people think about documentation. The description is not a summary of the skill. It is a gating mechanism.
The agent decides whether to pull a skill into context based on the description alone. Write it badly and the skill never loads — not because the skill is wrong, but because the bait didn't catch. Write it too broadly and you pollute the context window with things the agent didn't need.
This is a decision about when knowledge loads. The Colombia developer at the Node stage said the same thing from the failure side: "The tools aren't going to read your docs unless they're told to." Presence is not activation. A skill that exists but never triggers is a skill that does nothing.
Next rule: "Don't use a skill where you should be writing a script. Especially for repeatable tasks that you need to be deterministic."
This is a decision about what must be deterministic. A skill is instruction the model interprets; a script is code that runs the same way twice. If you need the same output every time, you don't hand it to a probabilistic system and hope. You take it out of the model's discretion entirely and put it in code.
The craft rule is knowing where that line sits. Skills for judgment, scripts for repeatability. Confuse the two and you either get drift where you needed certainty, or rigidity where you needed adaptation.
Third rule, and the sharpest: code review skills should be codified locally, because they have to reflect how that team works and how the codebase is set up — and you need a separate, adversarial code review agent, because the agent that wrote the code is biased toward it.
This is a decision about who is biased. The authoring agent is not a neutral judge of its own output; it will defend what it made. So you don't ask it to review itself. You stand up a second agent whose only job is to attack the first one's work.
Adversarial structure over trusting the author. That is not a prompt tweak. It is an org chart for machines, and it exists because the model's self-assessment is, reportedly, biased toward its own output.
Notice what these three rules have in common. None of them asks for a better model. Each encodes a non-obvious constraint about the system: when context loads, what stays out of the model's hands, who gets to grade the work.
And each one rhymes with a discipline designers already know.
The description-as-gate resembles what could be called progressive disclosure — you don't show everything at once, you reveal on demand, and the trigger has to be designed. The script-not-skill rule is the contract: a defined interface that behaves identically every call, versus a suggestion the system interprets.
The versioned skill registry is, per reporting on skills engineering, the design system move. Osmani's framing is that skills encode the workflows and quality gates senior engineers already use, packaged so agents follow them consistently. That is exactly what a component library does for interface decisions — it takes hard-won judgment and makes it portable.
The instinct across the industry is the same. Stop writing skills inside feature branches. Move them to a shared, versioned, evaluated registry every team can pull from. The earlier you make that move, the cheaper it is to roll back a bad one.
Philipp Schmid of Google DeepMind reportedly adds the operational half, per reporting on the talk: skills reduce the need for orchestration code, but only if you ship them with evals. Without evals, he says, you have shipped a vibe.
The eval is the contract. If you can't write a test for a skill's expected behavior, you don't yet understand the skill well enough to ship it. That is the same discipline as a test suite, arriving at agent authoring the same way it arrived everywhere else — the moment the work got too painful to repeat by hand.
So the craft is real. It has rules, it has analogues, it has a name — Paul Bacchus argued at AI Engineer World's Fair that skill engineering is becoming its own discipline, and, per reporting on the talk, the programs that pretend it's just prompt writing are already falling behind.
But here is the sharp edge, and it's two-sided.
First, this craft has a shelf life. Tyler Brown's caveat: skills need re-implementation every model release. He compares it to parenting a kid who grows from middle school to high school — you have to change the curriculum. Models get post-trained coupled to the harness they were trained against, which is part of why the same weights behave so differently across harnesses.
So a skill is not an asset you write once. It's an operating cost. Budget the refresh, calendar it, treat it as a program milestone rather than a fire drill — or your skills rot on the next release.
Second, and more serious: the craft has a governance ceiling. A well-authored skill that encodes bad judgment ships that bad behavior at agent speed. Skills make judgment portable — including the wrong judgment, faster than any human could deploy it.
This is where "we wrote skills" and "our agent is reliable" separate into two very different claims. Skills are one layer of the harness. Permissions, retries, fallback models, observability, recovery paths — all of that still has to be engineered, and none of it is fixed by writing a better description.
New APIs are starting to close pieces of the gap. shadcn's @shadcn/helpers package now lets you script human-in-the-loop flows with approve/deny and dynamic tool calls that pause for user input, threaded through the useChat lifecycle. That puts a real seam where a human can catch a bad action before it lands.
But an approval hook only helps if the human catches the mistake, and only for the actions you thought to gate. It's a control surface, not a guarantee. It narrows the gap; it does not erase it.
The honest position is the uncomfortable one. Agent reliability is a design-and-authoring discipline with its own hard-won rules, and every rule is a structural decision about when knowledge loads, who is biased, and what must be deterministic — not a wish for smarter weights.
The Terminal Bench number proves the leverage is there. Top 30 to Top 5, model untouched. That's the promise.
The shelf life and the governance ceiling are the price. A discipline you have to re-earn every release, that will faithfully ship your bad judgment at speed if you author it well.
Skill issue, then — in the most literal sense. The skill is the bottleneck. Which means the skill is also the fix, and the liability, and the recurring bill.