When coding agents started adding support for Agent Skills, I wanted to experiment with them.
At the time, I was rotating between Codex, GitHub Copilot, and Claude Code. I wanted to understand how each harness behaved, so I wrote some skills myself, downloaded others from open-source repositories, and tried different setups.
At first, managing them seemed trivial: clone a repository, copy a skill into the right directory, and try it. Then I had to do the same thing for another agent, and then another skill.
I don’t like repetitive work. If I notice myself doing the same mechanical operation several times, my default reaction is to automate it or remove the need for it entirely. So copying eventually became a script.
That introduced another problem. I now had multiple versions of the same skill in different places, so I replaced the copies with symlinks.
It worked better, but it still did not solve the actual problem.
I stopped knowing what my agents could do
Over time, my setup became surprisingly difficult to reason about.
I had my own skills and skills cloned from other repositories. Some were exposed to all of my coding agents, while others existed only in one harness because I was testing something. As usually happens with experiments, I forgot about some of them.
I would clone a repository because one skill looked interesting, expose it to an agent, test it, and move on. Weeks later, it was still there.
One of those experiments was a skill that helped an agent navigate a repository using a graph representation of the codebase. It sounded useful, so I installed it.
The problem was that my agents started reaching for it much more often than I expected. It could be invoked even in small repositories where finding the relevant files directly was already trivial. Eventually, I removed it because the additional machinery was getting in the way more often than it helped.
That made me look at the rest of my setup.
I realized I could no longer easily answer a basic question:
Which skills are currently available to each of my agents?
Technically, I could inspect their directories. But doing that manually across several harnesses was exactly the sort of housekeeping I had been trying to avoid.
More importantly, I had started thinking about the problem incorrectly.
Skills were no longer just files that I copied into configuration directories. They had started behaving more like dependencies. They had sources, versions, consumers, updates, and eventually a point where they should be removed.
The copy script was solving only the least interesting part of that lifecycle.
So I built a small tool to manage the rest of it.
What I actually needed to manage
Once I looked at the problem this way, I mainly wanted to answer three questions:
- What skills do I currently have?
- Which agents have access to them?
- Where did they come from, and are they still current?
Skills Manager scans the configured skill directories for my agent harnesses and shows what is currently installed. It also tells me whether a skill is a regular copy or a symlink.
That gives me one place to see the effective setup instead of inspecting several hidden configuration directories.
The next problem was discovering where skills came from.
My development environment is roughly divided into repositories related to my daily work and repositories for personal projects. Skills Manager scans configured paths, finds repositories that actually contain Agent Skills, and presents them as potential sources.
If I add a new skill to my own skills repository, I do not have to connect it manually to every agent. It appears in the manager, I choose which harnesses should get it, and the manager creates the appropriate links.
Third-party repositories work in a similar way. I can provide a repository URL, the manager clones it into a dedicated location, discovers the skills inside, and lets me choose which ones should be exposed to which agents.
That last part turned out to matter more than I initially expected.
I do not use every coding agent in exactly the same way. Some of my own skills make sense everywhere, so I expose them to all harnesses. Others are experiments that I may want to try only in Codex or only in Claude Code.
There is no reason for every agent to have an identical toolbox.
Skills Manager demo
Installation is only half of the lifecycle
There was another small problem I kept running into.
When you clone a repository today, you get the current version. Two months later, you probably still have the version from two months ago.
This is especially easy to forget with skill repositories because they are not necessarily projects you actively work in. They become infrastructure sitting somewhere on your disk.
So Skills Manager also checks the upstream branch of imported repositories. When an update exists, I can see it and pull the newest version from the same interface.
None of these operations is difficult on its own. I could clone a repository, inspect its skills, create or remove symlinks, run git pull, and inspect each agent directory manually.
The problem was having to remember and repeat all of them.
Skills Manager does not introduce a new agent architecture. It gives me one place to manage a lifecycle that had previously been scattered across Git repositories and configuration directories.
More skills are not necessarily better
While building the tool, I started wondering whether keeping unnecessary skills installed was merely an organizational problem or whether it could also affect the agent itself.
Agent Skills are designed around progressive disclosure. An agent initially sees basic metadata such as the skill’s name and description, while the full SKILL.md is loaded only when the skill is selected.
That makes skills much cheaper than putting every instruction directly into the system prompt.
But cheap does not mean irrelevant.
Every available skill is still another option the agent may have to consider when deciding how to approach a task.
This distinction explained my earlier repository-navigation experiment better than the simplistic idea that “too many skills fill the context window.”
The problem was not that the agent had loaded thousands of tokens of documentation. The problem was that the skill was available as an option at all, and the agent sometimes decided that it was the right option when I disagreed.
Progressive disclosure helps control context usage.
It does not eliminate routing decisions.
SkillsBench found that curated skills improve performance on average, but not on every task. In some cases, a skill made the agent follow an unnecessarily heavy workflow or displaced a simpler approach. That resembles my repository-navigation experiment, though the study does not show that simply installing more skills hurts performance.
I do not take this as evidence that having 30 skills is inherently worse than having 10. The research is too early, and the answer will depend on the harness, the skills, and how they are selected.
For my own setup, the rule is much simpler:
If I am no longer using a skill, I want to know that it is there and be able to remove it easily.
Skills Manager also shows the number of active skills and an estimated number of tokens represented by their full skill definitions. I do not treat that number as context usage—the whole definition is not necessarily loaded into the agent’s context. It is simply another visibility metric that helps me understand the size of the setup I am maintaining.
The exact number matters less than knowing what is there.
You probably do not need this if your setup is simple
If you use only Codex, have a handful of stable skills, and rarely experiment with new ones, you probably do not need a manager.
Putting the skills into the expected directory is simpler.
My problem appeared because I was doing the opposite: switching between several agent harnesses, testing open-source skills, creating my own, removing experiments, and trying different combinations.
At that point, the filesystem stopped being a good interface for the workflow.
What started as a small copying annoyance had turned into a dependency-management problem. I needed to know what was installed, where it came from, which agents could use it, whether it was current, and whether I still wanted it there.
Skills Manager is simply the tool I built to answer those questions.