The skill your build leaves behind

Eight commits of rediscovery

The evidence that this category should exist predates it. In our PostHog benchmark, two agents deployed the same stack; the only variable was that one of them also received posthog-single-node, a second skill carrying the topology, the configuration the migrations require, and a catalogue of roughly thirty failures written as symptom → cause → fix. The baseline agent spent eight fix commits rediscovering, the expensive way, what the other agent had been handed in writing — and then shipped a deployment it never proved could store an event, because nothing had told it what a working deployment looks like. The skill-equipped agent used 4.4× fewer tool calls and spent its commits on features.

Those eight commits are the general case. An agent that converges a real stack against a real cloud buys knowledge at the price of failed converges, misleading documentation, and acceptance checks that lie — and then the session ends and the knowledge strands in a transcript nobody will read twice. How a Package Skill Gets Made ends on the step most workflows skip: distill the lessons. Context Skills are that step given a name, a standard, and a shelf.

The third kind of skill

The getcolors ecosystem now has three skill kinds, and they answer different questions. A generic Agent Skill carries a procedure — Create Package Skill is one. A Package Skill carries a program: the deterministic translator from colors.yml to a running system that Park the Stochasticity argued for. A Context Skill carries what neither can: the judgment the authoring session bought — why the program is shaped the way it is, what breaks when you deviate, and what proof of health actually looks like.

The category is defined by a normative Context Skill Standard, and its qualifying test is provenance: the knowledge must have been bought from a verified build. A well-written README, a tutorial, a summary of upstream docs — none of these qualify, however useful, because nothing was converged to earn them. Five artifacts are required: a symptom-first routing description, provenance statements for every claim, the pinned version set with the rules that generated it, a symptom-indexed failure catalogue with verbatim error text, and evals shaped as a user in trouble.

Routed by the error on your screen

A skill an agent cannot find is a skill that does not exist, so the standard treats the frontmatter description as routing text, not documentation. It names symptoms — error strings, observed behaviours, situations — rather than mechanism, because the reader who needs it is staring at one of those strings right now:

no viable challenge type found          → agent-network-single-node
events accepted but not stored          → rybbit-single-node
stale container configuration           → rybbit-single-node
is not a known catalog provider         → agent-network-single-node

The Agent Skills spec caps that description at 1,024 characters, and the cap is enforced — the highest-signal symptoms stay in the description, and the full index moves to the top of the body. The same symptoms become the catalog's search keywords, so the string on your screen finds the skill whether your agent routes by frontmatter or you search the catalog by hand.

No second copy

The standard's sharpest rule: a Context Skill carries no copies of anything a tested implementation owns. Where a companion Package Skill exists, the skill names it and points at its files; it never reproduces them. A copied config is a fork that testing cannot see — golden tests and parity checks guard the package's files, and a byte identical twin inside a skill quietly stops being identical.

We learned how quietly while migrating the two pre-standard skills into shape. One of them carried working-file copies that had all diverged from the companion package — drift in both directions. Most deltas were the package having moved ahead, which deletion resolves. But one was a verified improvement that existed only in the copy: an HTTP/3 firewall publication whose absence makes browsers attempt QUIC, get nothing, and fall back to TCP — intermittent slowness you can carry for months. It went upstream first, through the package's own tests, golden fixtures, and pin, and only then was the copy deleted. That is the rule's argument made flesh: knowledge stranded in a copy is invisible exactly when it matters.

The link runs both ways in the catalog: a Context Skill names its companion, and the companion's product and Package Skill pages link back to the Context Skill.

Knowledge that admits it decays

A Context Skill's claims were true against specific versions on a specific day, and the standard makes it say so. Every claim either names what verified it or is labelled unverified. The pinned version set records the rules that generated it, and a pin bump starts the decay clock: the standard defines which claims survive a bump and which need retesting. Evals — written as the support message a user in trouble would actually send — are the category's regression net, testing routing and diagnosis together. The most valuable entries in the failure catalogues are the ones conventional documentation refuses to write: the gate that passed while the thing it guarded was broken, and what the passing actually meant.

Three today, and the two workflows

The catalog's Context Skills tab lists three, each distilled from a live, adversarially reviewed build and each conforming to the standard: agent-network-single-node, posthog-single-node, and rybbit-single-node. Loading one is one command; they are used, never installed:

npx skills use getcolors/skills@rybbit-single-node     # load one for this request
npx skills use getcolors/skills@create-context-skill   # distill your own verified build
npx skills add getcolors/skills@submit-context-skill   # submit yours to the catalog

The second command is the distillation workflow — five phases from harvesting verbatim failures while the session still holds them to proving the result with skills-ref validate and evals. It has already been field-tested: the two migrations above ran under it, and what they taught was folded back in the same day. The third is the admission funnel, and before inviting anyone into it we replayed a complete submission end-to-end — validation, recipe, build gates — and fixed the two gaps the dry run exposed. The catalog adds discoverability only: GitHub remains the source, and admission validates the artifacts your verification left behind, not the verification itself.

If your agent has ever spent an afternoon rediscovering something your last build already knew, that afternoon is the product this category replaces. Finish your next verified build with the distillation step, and leave behind the skill your next agent gets to start from.