A model upgrade changes program behaviour without changing a byte of the program. The skill still lints and the front matter is still valid; the agent just answers differently, because the component interpreting the skill was replaced underneath it. Git blame has nothing to say about that, which is why the failure the piece puts first, a skill that works on one model version and breaks on the next [11], arrives as a developer noticing weird output and complaining on Slack [3].
That makes the unit under test a pair: skill version and model version. Only one phase produces that pair. Evaluate, in Patrick's description at The New Stack [4], is where you load a skill, ask a specific question, check the expected result, and repeat across models and versions [6]. The rest of that list is cheaper and buys less. Front matter linting and syntax length are static checks on a file [6]; what breaks in this failure mode is the model interpreting the file, not the file itself.
One item on the evaluate list has no static implementation at all. Checking whether you are writing context the model already knows, which wastes tokens [6], cannot be answered by reading the skill. You need the scenario run twice, once with the skill loaded and once without, and a diff of the outputs. That is the same harness as the regression check, which is an argument for building the harness before writing the next twelve skills.
The activation check has a mirror the piece implies without spelling out. If a skill triggering on the wrong question yields confidently wrong instructions [11], then verifying that it fires on the right trigger words [6] is only half a test. Each skill also needs an adjacent question it must stay silent on, or false positives ship green.
Distribution and observation are where the bill lands. The mature end of distribute is an installable registry with versioning, discoverability and access controls [8]; the cheap end is a commit, and the author's framing of the middle is worth keeping: distribution means something more than pasting a skill into a Slack channel, just as dependency management means something more than emailing a .jar file [8]. Observe asks how many turns the agent takes before a developer intervenes and where developers override or correct its output [9]. That is client telemetry on the moments a developer decided the agent was wrong, not a routine config edit, and someone has to own collecting it.
Note what the maturity story actually covers. Organisations generate and distribute first and skip evaluate [10], which accounts for three of the four phases and leaves observe unclaimed in either direction [15]. The load-bearing support is an analogy: that this curve is identical to what happened to software practice over the past two decades [14]. For the analogy to pay in your repo, you have to be able to attribute a bad answer to a version bump, and that needs either the previous model still reachable or a recorded baseline output you trust. Without one of those, "the model changed" is an untestable hypothesis.
In my context I would take evaluate and defer the registry. Two scenarios per skill, pinned to an explicit model string in CI: the question it should answer, and the adjacent one it should ignore. Aviator's slop register is the same instrument at the other end of the pipeline, a catalog of patterns the model consistently gets wrong in your codebase feeding automated checks at review [12], and the reason both ends need a catalog is the sentence the piece builds to, that you cannot scale code quality by asking humans to review more carefully [13].
