Skills Lifecycle

As teams we should be thinking about how layers of skills are managed over time.

If skills exist in layers including enterprise, platform, domain, team, application and individual, then they cannot be treated as static assets. They become part of the software delivery lifecycle. Some will be broad and reusable. Some will be incredibly local. Some will start local and eventually deserve to move up a layer. Some will become stale and need deleting.

That means teams need a lifecycle around skills.

When should a repeated instruction become a skill? Who owns it once it exists? How do we know whether it is being used? How do we spot overlap between two skills? When does an app specific skill become useful enough to share with other teams? And when does a shared skill become too generic to be useful?

There are big public marketplaces for skills but I believe the most mature AI-enabled teams will be those who have maturity in how they manage this type of asset. Generic marketplace skills have value, but the highest-value skills are likely to be owned close to the work. They encode the things a team has learned about how this system should be changed safely. That's not to say teams use a more generic skill as a starting point and make it theirs.

A good team skill might be around convention e.g. when you add a database field, update the migration, import/export mapping, seed data, docs and reporting transform. That is not a universal best practice, it is local. It is the kind of thing experienced team members remember without thinking, but AI won't remember consistently.

The challenge is making that knowledge visible, maintainable and measurable. For example a way to see which skills exist, which layer they belong to, where they overlap, and whether agents are actually using them, and how effectively they are used in practice so they can be continuously improved.

If skills are going to help agents behave less like generic coding assistants and more like useful members of a team, then skill maturity will matter. High-performing teams may not just have good code, tests, CI/CD and observability. They may also have well-owned, well-maintained skills.