Ask most teams where their AI instructions live and you get a shrug. A prompt in someone's head. A paragraph pasted into a config file last quarter. A rules document nobody has opened since it was written.
That is the tell. These teams ship code written by agents, and then treat the thing steering those agents as a sticky note.
I run a 16-person engineering team at Circo, across backend, web, mobile, ML and data, and I build Dino with coding agents inside rules I set. In both, I reached the same conclusion: the agents' instructions and skills are production software. The moment they influence what ships, they inherit every obligation real software has. Version them. Review them. Test them. Roll them out. Keep a human on the hook for the review.
An instruction that writes code is code
A skill is a reusable instruction: how to review a change, how to write a test first, how to close out a task. When an agent follows it, the skill changes the diff. It is no less causal than a library function; it just executes in a model instead of a CPU.
We do not let a shared utility function drift as untracked text. We version it, we review changes to it, we notice when its behaviour shifts. A skill earns exactly the same treatment, because a bad skill does not throw an exception. It ships plausible, confident, wrong code: the characteristic failure of agents, and the one that costs you in review and in production rather than at compile time.
Once you accept that framing, the rest follows mechanically.
Version it like you mean it
Every skill carries a version, and the version has rules. A wording fix that changes nothing about behaviour is a patch. A new check or a new gate is a minor bump. A change to what the skill outputs (its shape, its contract with everything downstream) is a major bump.
This is not ceremony. Semantic versioning on a skill tells a reviewer, at a glance, whether a change is cosmetic or whether it moves the line of what gets caught. A changelog entry on each skill records why a gate exists, which is the thing you desperately want six months later when someone asks whether they can relax it. Without the history, every rule looks arbitrary and someone deletes it. With the history, the rule defends itself.
Review and test the instructions, not just the output
Here is where "skills are software" stops being a slogan.
You review changes to a skill before they take effect. A new gate is a pull request against the behaviour of your whole agent fleet, and it gets read by a person the same way a change to CI config would. One careless edit to a shared rule set reaches every repository the agents touch; that blast radius demands a reviewer, not a quiet save.
And you test them. The honest way to know whether a skill works is to measure it against real work: did it catch the bugs it was supposed to catch, did it flag things that were actually fine? That turns a skill from an opinion into something with a track record, and it tells you when a skill has decayed and needs a targeted patch rather than a hopeful rewrite.
The metric has to match the role, which is the part teams get wrong. A reviewing skill's job is to miss nothing; its failure mode is the bug that slips through, so you measure recall. An adversarial, bug-hunting skill's job is to not cry wolf; its failure mode is noise that burns human review time, so you measure precision. Hold both to the same number and you optimise neither. Choose the metric by how the skill fails, not by convention.
Roll it out across every repository
A skill that lives in one repository and nowhere else is a note, not a standard. The value shows up when the same operating model runs everywhere.
At Circo the codebase is polyglot (TypeScript, Java, Go, Python, Swift, Kotlin), and agents work across all of it. So there is one shared base set of rules that applies everywhere, and each team layers on rules for its own languages and repositories. The base keeps the floor consistent; the local layer keeps it relevant. Team leads own and review their rule sets the way they own code, which means an agent is a contributor with clear boundaries, not an exception carved out of the process.
Rolling out across repositories also means knowing what is actually deployed. Agent tooling tends to install skills into opaque, machine-generated locations you cannot reliably inspect. So you do not inspect the files; you keep a manifest that records the version last shipped, and you check the source of truth against the manifest. When the canonical skill has moved ahead of what is installed, the drift is visible and someone reconciles it. A standard you cannot confirm is deployed is not a standard.
Keep a human accountable for the review
Automate the volume. Do not automate the accountability.
This is the line I hold hardest. At Dino, agents do the bulk of the work inside rules that are deliberately hard to weaken: the enforcement is sealed, and loosening a check takes a written spec, a review and a deliberate human action, not a quiet edit in a hurry. I set the architecture, I own the rules, and I approve every release. The agents are fast; the judgement is mine. Same model at Circo, where leads carry the review for their teams.
A self-improving loop makes this more important, not less. The point of versioning, measuring and patching skills is that the agents you work with get better over time: the version on day thirty should be better than the version on day one, because every miss fed back into a sharper rule. But "better" is a claim, and a claim needs an owner. A skill that proposes its own improvements still passes through a person who decides whether the improvement is real. Compounding quality without human accountability is just drift with good PR.
So treat the instructions as what they are. Not prompt-craft. Not folklore. Production software, with versions, reviews, tests and an owner, because the agents reading them are writing the code you ship.