Recently, I have been watching the ecosystem around Agent Skills grow very quickly.
Skills are appearing in more tools.
More repositories are starting to contain them.
Organizations are beginning to think about how to share them across teams.
And the format itself is becoming more familiar.
I think this is a good thing.
But it also makes me think that the interesting problem around Skills is starting to change.
At first, the question was:
How should we write a good Skill?
Increasingly, I think another question matters just as much.
How should we maintain a Skill after people start depending on it?
Creating a Skill is getting easier
The basic Agent Skills format is intentionally simple.
A Skill can be a directory with a SKILL.md, together with optional scripts, references, and other resources. The format is designed to package knowledge and workflows into something agents can load when needed. citeturn478068search2turn478068search5
This simplicity is useful.
It also means creating a Skill is becoming easier.
An LLM can help write one.
A developer can create one for a repository.
A team can package an existing workflow into one.
A tool or plugin can ship one as part of its own project.
I expect authoring to become even easier as tools improve.
But creating an artifact and maintaining an artifact are different problems.
A useful Skill becomes a dependency
Imagine a team creates a Skill describing how to release its software.
At first, it works well.
Then the release process changes.
A new validation step is added.
A command is renamed.
A security requirement changes.
A repository is reorganized.
The Skill still exists.
The agent can still load it.
It may even look completely valid.
But the knowledge inside it is no longer correct.
This is where Skills start looking less like prompts and more like software dependencies.
Once people rely on them, their lifecycle matters.
Someone has to notice when they become outdated.
Someone has to review changes.
Someone has to know what the Skill depends on.
Someone has to decide which version is the current one.
The difficult part is no longer only writing the Skill.
It is keeping the Skill trustworthy.
Installation is not maintenance
Distribution makes this more interesting.
A Skill may come from another repository.
It may be installed by a tool.
It may be bundled with a plugin.
It may be copied into an organization and customized.
All of these are reasonable ways to distribute knowledge.
But distribution does not automatically define ownership.
Suppose a plugin ships a Skill.
If the Skill continues to live inside the plugin, it makes sense for the plugin project to maintain that asset together with the functionality it describes.
But an organization may decide to copy it and modify it for its own workflow.
Now there are two related Skills.
Who maintains each one?
Which one is the source of truth?
Should changes from upstream be incorporated?
Has the local copy intentionally diverged?
These are not really installation questions.
They are maintenance questions.
The important question is not only where a Skill came from.
It is who is responsible for keeping it current.
Scale changes the problem
With a few Skills, this may not seem important.
A team can remember what exists.
People know who wrote each file.
They can manually update things when necessary.
That becomes harder when there are tens or hundreds of Skills.
A recent dataset called GitSkills found about 3.8 million SKILL.md file occurrences across more than 282,000 public GitHub repositories collected in July 2026. It also found many identical Skill contents appearing in multiple locations. citeturn478068search3
That number is interesting to me not only because Skills are becoming popular.
It shows how quickly reusable knowledge can spread.
And once knowledge spreads, maintenance becomes harder.
We start asking questions like:
Who owns this?
Where did it come from?
Is this still the latest version?
Is another copy newer?
What depends on it?
Has its source material changed?
Was this revision reviewed?
Is this Skill still used?
These questions feel familiar.
Software teams already ask similar questions about code and dependencies.
I think we will increasingly need to ask them about agent knowledge as well.
Enterprise guidance is starting to look familiar
I found Anthropic’s enterprise guidance for Agent Skills particularly interesting.
It recommends maintaining information such as a Skill’s purpose, owner, version, dependencies, and evaluation status.
It also recommends keeping Skill source files in Git as the single source of truth and managing synchronization when Skills are deployed across different surfaces. citeturn478068search0
I don’t think this means every organization needs a new platform for Skills.
And it certainly does not mean there is only one correct way to manage them.
What I find interesting is the shape of the problem.
Ownership.
Versioning.
Dependencies.
Review.
Evaluation.
Source of truth.
These are software engineering concerns.
GitHub is moving in a similar direction from another angle. Copilot code review can now consume repository- or organization-specific Agent Skills from .github/skills, allowing teams to bring their own standards and context into reviews. citeturn478068search1
Skills are becoming more than personal instructions for an individual agent.
They are starting to become shared organizational assets.
And shared assets need maintenance.
Standardizing the format does not standardize the knowledge
I hope Agent Skills continue becoming more portable.
A common format is useful.
It allows tools to share the same basic structure instead of inventing a new representation for every agent.
But even if the format becomes completely standardized, the knowledge inside it will not be.
Every organization has different:
- architecture
- terminology
- policies
- workflows
- ownership
- sources of truth
- review requirements
A standard SKILL.md format cannot tell us whether the knowledge is still correct.
It cannot know which internal document just changed.
It cannot decide whether a local modification should follow upstream.
It cannot know which team is responsible for a particular workflow.
The format can become standard.
The maintenance responsibility cannot be standardized away.
This is where I see a Context Repository
This is also changing how I think about Context Repositories.
A Context Repository does not need to invent another Skill format.
If the ecosystem converges on a common format, that is good.
It does not need to become the agent runtime either.
Agents already know how to consume Skills.
Instead, I think a Context Repository can focus on the lifecycle around those assets.
What exists?
Who owns it?
Where does the knowledge come from?
What does it depend on?
What changed?
Has it been reviewed?
Is it still current?
Which copy is canonical?
This is the area I have been exploring with Renma.
Renma is only one implementation of the idea, and I don’t think a Context Repository needs to own every part of the Skills ecosystem.
Actually, I think the opposite is healthier.
Skill formats can belong to the ecosystem.
Plugins can maintain the Skills they ship.
Security tools can inspect them.
Agents can execute them.
A Context Repository can concentrate on making maintained knowledge understandable and governable.
The next problem
Authoring good Skills will remain important.
Security will remain important.
Evaluation will remain important.
Distribution will remain important.
But as Skills become easier to create and more common to reuse, I think maintenance will become increasingly visible.
A Skill that was correct when it was written may not be correct six months later.
A Skill that works well in one repository may become a confusing copy somewhere else.
A Skill without a clear owner may quietly survive long after the knowledge it represents has changed.
This is why I think the next stage of the Agent Skills ecosystem will not only be about creating more Skills.
It will be about learning how to maintain the ones we already depend on.
Maybe that is another way to think about Context Engineering.
Not only teaching agents what we know.
But maintaining what we teach them.
~ my tech diary ~ 