Three engineers. Three copies of the same Claude Skill. None of them documented.
That's where most Australian engineering teams land within a quarter of shipping their first Skill. One engineer writes a Skill for code review. Another doesn't know it exists and writes a slightly different one. A third forks the original for their squad's specific context. By week twelve you have three Skill files, three behaviours, and nobody who can tell you which one Claude is actually running.
The Skill lifecycle loop
A Skill in production needs the same lifecycle discipline as any other piece of code. Five stages cover the ground:
Source of truth. Every Skill lives in a git repository, owned by the team that uses it. Not on someone's laptop. Not in a Slack thread. A repo, with a README, with a named owner.
Semantic versioning. Every change bumps the version: patch for corrections, minor for new capabilities, major for breaking changes. The version lives in the SKILL.md frontmatter. This sounds like overhead until two squads are running different versions of the same Skill and producing different outputs for the same input.
Distribution via a private plugin registry. A private registry pushes Skill updates to all team members on their next Claude Code launch. Engineers don't pull updates manually. They land automatically, the same way a dependency update does.
Deprecation with a grace period. Skills marked deprecated continue to work for one quarter, with a banner in the Skill output naming the replacement. Teams that remove Skills immediately break workflows nobody documented.
Telemetry. A hook reports each Skill invocation to a logging endpoint: usage count, invocation context, team. This is the data that tells you which Skills are earning their keep and which have become zombies.
This is the Skill lifecycle loop. Engineering teams that run it don't lose Skills to entropy.
The economics
A 50-engineer team running this lifecycle spends approximately 0.3 of a full-time engineer maintaining the Skill catalogue. The same team without the lifecycle wastes around 1.4 engineer-equivalents each year — spread across undocumented variations, debugging sessions for unexpected outputs, and re-implementations of Skills that already existed but nobody could find.
At $120/hr fully loaded for a mid-level engineer in Sydney or Melbourne, that difference comes to roughly $260,000 a year. The 0.3-FTE investment in lifecycle maintenance costs around $75,000. The payback is immediate.
The hardest part: deprecation
Deprecating a Skill that one team relies on is the moment that tests the lifecycle. The instinct is to move fast, get it off the catalogue, stop maintaining it. That's wrong.
The pattern that works: ship the deprecation banner first. Run it for a full quarter. Check the telemetry to see who is still invoking the deprecated Skill and how often. Contact the heaviest users directly, find out what the Skill is doing for their workflow, and make sure the replacement covers it before removing the old one.
Teams that skip the human contact step lose trust in the platform fast. Engineers who relied on that Skill start working around the system rather than with it. A Melbourne consultancy running this lifecycle across 80 engineers learned this in their first year. They now treat the contact step as non-negotiable.
Their catalogue today runs to around 35 Skills. It turns over by roughly 20 percent each year — seven or eight Skills retired, seven or eight added. That turnover is healthy. A static catalogue is almost always an underused one.
When not to run this
Not every team needs the full lifecycle. Three signals that tell you the overhead isn't worth it:
Your team is under 10 engineers. At that scale, a shared Git repo and a weekly sync is enough. A private registry is engineering cost you don't need yet.
Your Skill catalogue has fewer than five Skills. The lifecycle pays for itself when catalogue management becomes a real problem. A handful of Skills need a README, not governance.
Your Skill surface is changing every week. Early in a Claude rollout, patterns shift fast. Lock them down too soon and you'll spend more time managing deprecations than building. Wait until the patterns stabilise before adding lifecycle discipline.
The lifecycle is for teams past the experimental phase. If you're still working out which Skill patterns fit your engineering context, an AI Readiness Assessment is the better first step.
What measurement looks like
The lifecycle only holds if you measure what matters. Three numbers to add to a shared dashboard from week one:
Usage rate. Which Skills are being invoked, and how often. Low-usage Skills added in the last quarter are candidates to retire. High-usage Skills are candidates for further investment.
Acceptance rate. How often an engineer accepts Claude's output without significant edits. A Skill running below 30 percent acceptance is producing worse results than the engineer would have produced alone. Rewrite or retire.
Cost per invocation. Token cost per Skill run. One Skill burning 10x the cost of everything else at a low acceptance rate is a clear cut.
A Sydney engineering platform team running this dashboard found that two Skills were consuming 40 percent of their monthly token budget while accounting for less than 10 percent of accepted outputs. Removing them recovered around $90,000 a year in token costs. They modelled the numbers using our ROI Calculator before taking it to their engineering director.
Treat the catalogue like a product
The engineering teams getting compounding value from Claude Skills treat the catalogue as a product, not a project. Products have owners. They have release cycles. They get measured, iterated, and retired when they stop serving the people who use them.
Projects get handed over and forgotten. Nobody owns them after launch. Within a year, nobody can tell you which version is running or why Claude behaved differently last Tuesday.
The teams winning with Claude in 2026 are the ones who made that distinction early. If Skill management is becoming a real problem at your scale, our AI Automation Services team can help you build a lifecycle that fits.
There's no magic in the lifecycle itself. The discipline is the magic.
