Production skills: a real library

Everything so far has been principle. This part is evidence. The patterns that make skills worth relying on are not theoretical — they are visible in a skill library that runs every day in production. We will walk through that library (core-skills) and pull out the patterns worth copying.

The point is not the specific skills. It is what makes them production-grade rather than merely functional.

Single-purpose, and you can prove it

The library is a set of focused skills — transcript extraction, change-request lifecycle, standup processing, dashboard generation, the tooling that maintains the library itself. Each does one job you can state in a sentence. None tries to be a platform.

That is the first production discipline, and it is the one from Part 1 made real: if you cannot describe a skill in a sentence and validate it on its own, it is doing too much. A library of single-purpose skills is one you can trust piece by piece. A library of sprawling skills is one you hope about.

An explicit "never do this" contract

The strongest skill in the library — the one that manages the other skills, with the power to pull and link and modify — opens with a set of safety rules that are always enforced. Things like: never remove anything without asking, never act on a dirty working tree, never force a destructive operation, skip what is unreachable rather than failing loudly.

This is a pattern worth copying directly. A skill that can change things should state, up front and as standing instructions, the things it must never do. The prohibitions catch the failure modes you already know about, every time the skill runs, without you having to be watching. The more power a skill has, the more it needs an explicit floor under it.

Verify before you mutate

The same skill does something subtle before it changes anything: it checks whether the change is safe to make at all. Concretely, before pulling updates it verifies the commit history is a clean fast-forward and interprets the result precisely — safe, behind, or unreachable — and only then proceeds.

Generalised, the pattern is verify-before-mutate: a production skill confirms the state is what it expects before it acts, rather than acting and hoping. Build the check in as a standing step, not as something you remember to do.

Self-auditing: confirm the result, do not assume it

The change-request skill has an audit operation that scans for integrity problems, reports them by severity, fixes what it can — and then re-runs the audit to confirm the result is clean. It does not assume the fix worked. It checks.

That re-run is idempotency in practice, and it is the difference between "the skill did something" and "the skill verified the outcome." A production skill that touches important state should be able to check its own work and tell you, honestly, whether the result is clean. Combined with strict invariants — sequential identifiers never skipped or reused, consistent naming, one record per file — the skill polices itself so you do not have to.

Inheritance and config: do not repeat the standards

The library shares standards — priorities, statuses, meeting formats, an archive policy — across many skills. It does not copy them into each one. A base skill holds the shared vocabulary, and the domain skills inherit it, adding only what is unique to them. The base skill is marked as background knowledge rather than a command, so it informs the others without being something you invoke directly.

Environment-specific values sit in layered configuration: a project layer overrides an organisation layer, which falls back to base defaults. And the local facts that are specific to one setup stay in CLAUDE.md, the single source of truth, while the skills supply generic procedure. The result is a library where a shared standard changes in exactly one place, and each skill states only what makes it different.

When flat is right, and when to split out files

A fair question after Part 3: that guide said push detail into separate reference files, yet this library keeps each skill's instructions inside its own body, flat, with no bundled files. Both are correct, and the reconciliation is the lesson.

Reference files are the tool for when a skill's material outgrows a lean body — a long lookup table, a large example set, detailed documentation. This library does not need them because each skill is genuinely lean and single-purpose; the instructions fit comfortably in the body. Judge by size and clarity, not by dogma. Keep it flat while it stays lean; split out reference files when staying lean would otherwise force you to cut real content. The goal is the same either way: a body that does not carry more than it needs.

What this proves

This is the "built in production" claim made tangible. The skills are not demos. They run, they guard themselves, they audit their own work, and they inherit shared standards instead of duplicating them. Every pattern here is one you can apply to your own library — and together they are what separates a skill that impresses once from one you can hand the keys to.

Where this goes next

Production-grade single skills are one thing. Running a shared skill library across a team — safely, with versioning, review, and clear ownership — is another. That is Track 4: skills as governance.

This completes Skills in Production. Continue with Skills as Governance to take a skill library team-wide.