Everyone is creating their own Claude Skills.
On top of that, teams are building additional skills for their workflows. Each person finds a useful way to automate something, packages it, and keeps going.
I've noticed this across several companies. What starts as a productivity improvement for individual developers turns into duplicated functionality, inconsistent standards, and fragmented workflows.
Then someone wants to automate a process across teams.
Which skills should that workflow use?
Everyone solves the same problem differently
A developer builds a skill to investigate a pipeline failure. Another developer builds something similar. A team creates its own version because it needs a different report or works with a different set of repositories.
Each version may be useful. But now several people are maintaining variations of the same capability, often without knowing the others exist.
When one person improves their version, that improvement doesn't automatically reach everyone else. When a process changes, every copy needs updating. Some get updated. Others keep following the old instructions.
The company has more skills. It hasn't necessarily gained a capability that everyone can reuse.
A personal workflow doesn't automatically become a shared one
Imagine one team produces an investigation report and another team needs to use it to create a ticket.
The first team's skill returns a written summary. A different version returns a list of suspected causes. Another includes the affected job and links to logs. All three are described as investigating the failure.
Which output can the ticket-creation step depend on?
Someone has to reconcile the differences, add missing information, or write another skill to connect them. The process still depends on a person understanding how each piece behaves.
Repeat that across several teams and the automation becomes a collection of exceptions. It works as long as the right people know which version to run and what to do with the result.
That's a difficult foundation for a reliable, reusable workflow.
The standards are fragmented too
The differences extend beyond the format of a report.
One skill may require evidence before recommending a fix. Another may move straight to changing code. One team expects a review before an action. Another has built its workflow around doing that action immediately.
Individually, those choices may reflect how each team works. Once the skills are connected, the differences become dependencies that somebody has to manage.
If every developer defines those expectations independently, a shared workflow has no consistent behaviour to rely on.
Build something other teams can depend on
There is value in people experimenting and finding better ways to work. But when several workflows need the same capability, that capability needs a shared home and agreed expectations.
Teams should know what a skill does, what information it needs, what it produces, and who maintains it. Improvements should reach the people depending on it. Changes should be checked against the workflows that already use it.
Teams will still need their own domain-specific instructions. They shouldn't have to recreate the same underlying functionality every time.
The number of skills people have created tells you very little about how much of the company's work can run reliably across teams.
If every developer has their own set of skills, how do you build automation that anyone else can trust and reuse?
Comments