Governing skills at scale: progressive disclosure and software as memory

A frontier model knows how to write code in general. It doesn't know your deploy process, your naming conventions, the three libraries you've banned, or why that one service must never be touched on a Friday. Skills — task-specific instructions the agent loads on demand — are how you encode that. Done well, they're institutional memory that compounds. Done badly, they're a sprawl of stale prompts nobody owns.

Skills, and why they beat a giant system prompt

A skill is a small, named bundle of instructions for a specific task — "how we write migrations," "our PR description format," "how to debug the payments service." The mechanism that matters is progressive disclosure:

• The skill's short description sits in context always — cheap, a line or two.
• The full instructions load only when the agent judges the task relevant.

This is the opposite of the tempting anti-pattern: stuffing every convention into one enormous system prompt. That bloats every request, poisons the context with mostly-irrelevant text, and — because it's a fixed prefix — is the thing most likely to break your prompt cache. Progressive disclosure keeps the always-on context tiny and pulls detail in only when it earns its tokens.

Don't pay to tell the model how you write migrations on every request that isn't about migrations. Load the skill when the task is a migration, and not before.

Software as memory

The deeper idea: your conventions, runbooks, and hard-won decisions are knowledge, and knowledge should be encoded where the agent can consult it, not re-explained in every chat. A skill that captures "here's how we handle idempotency in this codebase" is institutional memory the next task inherits for free. Pair it with a memory file the agent writes to as it learns, and the system gets better the more it's used — the corrections you make today become context tomorrow. This is the same lever as a good CLAUDE.md/AGENTS.md, formalized.

The scaling problem nobody warns you about

This works beautifully for one developer. Across a team it rots, fast:

• Drift. Everyone has their own CLAUDE.md and a private folder of skills. Three people, three conflicting versions of "how we write tests."
• Staleness. A skill encodes a convention that changed six months ago; the agent confidently follows the old rule.
• No ownership. When a skill is wrong, who fixes it? When the deploy process changes, who updates the skill? If the answer is "nobody," your skills are a liability.

Governing skills like the code they are

The fix is to treat skills as versioned, owned, reviewed artifacts — because that's what they are:

• Central, shared repository. Skills live in one place, version-controlled, distributed to the team — not copied around laptops. One source of truth for "how we do X."
• Ownership and review. Each skill has an owner; changes go through review, like code. A wrong skill ships wrong behavior to everyone who uses it, so it deserves the same gate.
• An audit trail. Know which skills exist, who changed them, and when. When an agent does something surprising, you can trace it to the instruction that caused it (the observability principle, applied to context).
• Lifecycle. Skills get deprecated and deleted, not just added. A skill graveyard is as dangerous as dead code — delete the ones that are wrong.

The lazy first version

You don't need a "skill governance platform" on day one:

• Put shared skills in one git repo the team's agents read. Versioned, reviewed via normal PRs. That's 90% of governance for 10% of the effort.
• Keep each skill small and single-purpose so progressive disclosure actually works.
• Delete aggressively. A short, current set of skills beats an exhaustive, half-stale one.

Skills are the cheapest way to turn a general agent into one that knows your shop — and the fastest thing to rot if you treat them as throwaway prompts instead of the shared, governed memory they actually are.

Inspired by the skills-governance and "software as memory" writing at tomaskubica.cz.