Adopt, adapt, skip

The last post ended with me deciding to move our proven protocols into version-controlled skills. This one is about the opposite direction: deciding which of somebody else’s skills to move in.

Addy Osmani’s agent-skills repo holds twenty-four of them, each one a senior engineer’s workflow written down as a procedure an agent can follow. Debugging, code review, TDD, security, shipping, planning. It is good material, distilled from someone who has clearly watched agents fail in all the ways I have watched agents fail. The tempting move is obvious: install all twenty-four, congratulate yourself on your new senior engineering department, move on.

We adopted five, adapted six, and skipped thirteen. The interesting part is not the tally. It is the reasoning, because it turned out this was not really a post about someone else’s library. It is a post about knowing what your own system already does.

The triage rule

Going skill by skill, a rule emerged, and once it emerged the sorting got fast. Three buckets.

Adopt where we have no protocol at all. Five skills went straight in, close to verbatim: debugging and error recovery, planning and task breakdown, code review (which our prod-gate review board needed a written procedure for anyway), context engineering, and documentation with ADRs. That last one stung a little. Every architectural decision we have made this quarter was made carefully, in chat, and lives nowhere. Decisions currently made in conversation should land in the repo, and now there is a procedure whose job is to make that happen. Where you have nothing, someone else’s good default beats your empty file.

Adapt where we already run a stronger, house-specific version. Six skills covered ground we had already built on, and built harder. The shipping and CI skill gives an agent good advice about merging safely; our version is not advice, it is an enforced merge script that physically refuses to merge red. The git workflow skill teaches branch hygiene; ours is isolated worktrees with written ownership contracts, which is what lets five agents ship in parallel without touching each other. The TDD skill assumes a test layout we do not have, so it got rewritten for our colocated-test reality. The security skill is a generic checklist; ours got rebuilt around our actual attack surface — the paid dataset, row-level security, and the grant matrices our permission gate already snapshots. Observability got rewritten around our typed event registry. In every one of these, the skeleton of the skill was worth taking. The muscles were ours already, and swapping them out would have been a downgrade wearing an upgrade’s name.

Skip where a gate already enforces what the skill would teach. Thirteen did not come in, and the biggest reason is the one I want to dwell on. The code simplification skill teaches an agent to avoid duplication; our duplication ratchet fails the build when duplication rises, whether or not anyone was taught anything. The frontend and browser-testing skills teach visual care; our design-system lint and the screenshot loopback pipeline check the pixels themselves. The performance skills are genuinely good and genuinely premature at our traffic; I would like the problem they solve, eventually. And several methodology flavours — plan before you build, check before you create — are already load-bearing house rules here, ticket-first and discover-first, enforced by process rather than by an installed reminder.

The principle

When you read anyone’s best-practice library, the reflex question is “is this good advice?” It almost always is, which is why the question is useless for triage. The question that actually sorts the pile is: does my machine already make this advice unnecessary? An agent that cannot merge red does not need a paragraph encouraging it to merge carefully. An agent whose duplication is blocked by CI does not need to be taught to feel bad about copy-paste. Installing advice your gates already enforce adds context weight without adding safety. You pay tokens on every dispatch for a behaviour the pipeline guarantees for free.

This is the same economics as the last post, run in reverse. Skills compress protocol; gates delete the need for it. Given the choice, deletion beats compression every time.

What the adopt list is actually telling me

Look back at the five we took verbatim: debugging, planning, review, context engineering, documentation. Notice what they have in common. Every one is a judgment-heavy activity. There is no lint rule for “you decomposed this task badly,” no CI check for “this ADR fails to mention the alternative we rejected,” no ratchet for “you gave up on the root cause and patched the symptom.” Enforcement cannot replace thinking in those places, so a written procedure for how to think is the strongest tool available.

Which means the adopt list is not just a shopping outcome. It is a map of exactly where our machine is still thin. Everything mechanical, we have gated over the past months: merges, permissions, duplication, routes, honest data, deploys. What we could not gate is the judgment work, and that is precisely where someone else’s distilled judgment is worth importing.

Gates for the mechanical, skills for the judgment, and knowing which is which is the whole game. Get it backwards in either direction and you lose: gate the judgment work and you get a machine confidently enforcing the wrong thing; teach the mechanical work and you get an agent politely advised not to do what it should be physically unable to do.

The context bill, again

Post eight argued that skills save context: hold a table of contents, load the chapter you need. This post is the second half of that argument. The cheapest skill is the one you never install, because your machine already made it redundant. Twenty-four skills at a name and a description each is a small tax, but it is a tax on every single dispatch, forever, and thirteen of the entries would have been advice our gates already enforce, rules our process already carries, or problems we do not yet have.