Deterministic Tool Adoption Gates: Score It, Don't Vibe It

Originally published on hexisteme notes.

A new public repo showed up on 2026-07-14: mattpocock/skills, an MIT-licensed collection of Claude Code agent skills. It's the kind of thing that's easy to fall for in the first ten minutes — skim the READMEs, install the ones that sound useful, move on. I didn't do that. I ran it through the five deterministic gates in my adoption CLI, the same gates every Swift package and npm dependency in my stack has had to clear, extended for the first time to cover a Claude skill.

The reason I bother with this at all: adoption decisions rot when they're vibes. "This looks solid" is not a claim you can revisit in six months and check whether you were right about. A score is. So is a pre-registered condition for when you'd bail on it. The rest of this post is what that machinery produced on a real decision, not a hypothetical one.

Five gates, one score

The CLI scores any candidate — package, library, or now, skill — on five gates: maturity (how long has this actually existed), dependency footprint (what does adopting it drag in), platform fit (native or third-party, and documented or not), policy and developer experience (documentation quality plus release stability), and trajectory (is it actively maintained right now). Each gate contributes points toward a 100-point total, and fixed thresholds turn that total into a verdict: ADOPT at 80 or above, TRIAL at 60 or above, HOLD at 40 or above, reject below that. No gate is a gut check — every one resolves to a number from a query I can rerun.

Here's what mattpocock/skills scored, evaluated as of 2026-07-14:

None of the six hard gates fired — the kind of automatic disqualifier that overrides the score outright — so the raw and final verdicts agree: TRIAL, no demotion.

Read as a shape instead of a table, the profile says something legible: young but alive and light. Trajectory and dependency footprint are maxed out. Maturity is on the floor, because there simply hasn't been time to accumulate any. That's not a knock on the repo — it's a public, MIT-licensed project four weeks into its first release, already on its second release. TRIAL is exactly what a shape like that should produce, and TRIAL has a specific meaning: adopt in isolation, verify, then widen. Not "good." Not "bad." An instruction about scope.

Nine facts, one assumption

The gate math only means something if the inputs feeding it are honest about how they were obtained. The CLI tags every signal as FACT, INFERENCE, or ASSUMPTION, and it computes scores only from what's tagged — nothing gets to influence a "deterministic" gate by feel.

This evaluation ran on ten signals: nine FACT, one ASSUMPTION. The nine facts — first release date, latest release, releases in the last year, last commit, major version, maintainer count, whether the project is platform-native, whether official docs exist, dependency count — all came from real queries against GitHub's API, not a recollection of what the repo probably looks like. The docs signal, for what it's worth, resolved true off an actual README fetch that came back at 14,573 bytes, not an assumption that it probably has decent docs.

The tenth signal, breaking changes per year, had no machine-checkable source at all. The honest move there isn't to guess a flattering number — it's to apply a conservative default and eat the cost. The system defaulted it to 4 breaking changes per year, and that single assumption is the entire reason G4 lost its stability half: full marks on documentation, zero on stability, net 10 out of 20. If this project accumulates enough release history that the real number becomes observable, that's a fact I can plug in and rerun the evaluation with — but I'm not going to assume stability just because assuming it would make the score prettier.

Two smaller judgment calls are worth naming, because a gate that hides them isn't trustworthy. First: the maintainer count came back as 3 from the raw API, and I filtered one of those out — a release bot that opens changeset PRs, not a person — to get 2. But 2 human accounts isn't the same as 2 active ones: it's 296 commits from the repo owner against 8 from the second contributor, a bus factor of roughly 1 in practice. The gate's hard trigger for that only fires at 1 or below, so 2 doesn't trip it. I wrote the caveat down anyway, because a gate not tripping isn't the same as the risk not existing. Second: I could have widened the list of hosts the system treats as "official docs" to upgrade a borderline signal to a stronger tag. I didn't, because that's gaming the gate, not scoring the repo — I used the path I actually queried and left the classification where the evidence put it.

Five ways this could die

The same tagged inputs that produced the score also auto-derive kill conditions — falsifiers, pre-registered before I've used the thing in anger, not written after something breaks. For this evaluation, the system produced five:

None of these required me to sit down and imagine how this could go wrong — they fell out mechanically from the same signals that produced the 64. The decision this produces isn't "adopted, done." It's "adopted until one of these five fires."

A decision that didn't need the other to agree

Separately from the gate score, I went through the repo's skill list by hand — 28 active skills once you set aside the deprecated and in-progress ones — checking each against what I already run. Twenty-six overlapped with tooling I already had: code review, TDD loops, research, spec-writing, triage. Adopting them would mean maintaining two ways to do the same job, which is its own tax. One didn't overlap with anything: a prototyping skill for building structurally different variants when a design decision won't converge in words. That's the one I adopted, installed in isolation, its two core files untouched. A second skill, an orchestration and spec-writing tool, looked appealing but duplicated ground I already cover — I held it, not rejected it, pending a case where I'm actually missing a map rather than just curious about one.

Here's the part I like: the gate score and this decision were arrived at without either one seeing the other. The five gates didn't know I was going to adopt exactly one skill in isolation. My decision to adopt exactly one skill in isolation didn't know the gates had landed on TRIAL, which by definition means the same thing. Two independent processes, same conclusion. That's not proof either one is right — but it's a much stronger signal than either alone, and a lot stronger than "this looks solid."

The table I didn't write to

The adoption ledger has an outcomes table, and it's not decorative — it's the denominator every future decision's base rate gets computed against. Log enough outcomes, and a new evaluation stops being a cold guess and starts being informed by what actually happened the last N times a repo scored like this one.

Which is exactly why I didn't write to it on day zero. Zero days had elapsed. None of the five falsifiers had had any time to fire, or not fire. Logging "success" at that point wouldn't be a measurement — it would be an opinion wearing a data structure, and it would sit in that table forever, quietly corrupting every base rate pulled from it afterward. The discipline in a system like this isn't the part where you collect the data. It's the part where you know which table you're not allowed to write to yet.

What TRIAL bought me

The skill adopted in isolation — the prototyping one — got its first real use a few days later, on a mascot redesign for one of my apps. Three structurally different variants, rendered and looked at instead of argued about, and the first render caught a bug no code review would ever have found: the arms rendered as legs because a rotation anchor was pinned to the wrong end. That's its own story, worth reading on its own — but the short version is that the one thing this evaluation said yes to earned its place inside a week.

A checklist for the next tempting repo

The mechanics generalize past this one decision:

• Score the candidate on fixed gates — maturity, dependencies, platform fit, policy and stability, trajectory — and let a threshold, not a feeling, set the verdict.
• Tag every input FACT, INFERENCE, or ASSUMPTION, and compute the score only from what's tagged.
• When an input has no real source, give it a conservative default, not an optimistic guess. Let it cost points.
• Let the same tagged inputs auto-derive kill conditions, so the falsifiers exist before you need them, not after something breaks.
• If the verdict is TRIAL, adopt the smallest useful unit, in isolation, and verify before widening.
• Don't write to the outcomes table until enough time has actually passed for a falsifier to have had a chance to fire.

None of this makes the decision faster. It makes it one I can revisit in six months and check whether I was right — about the repo, and about myself.

More notes at hexisteme.github.io/notes.