Ask HN: How do you manage skills files?
TL;DR
Someone asks how people find, organize and test the skill files they give coding agents. They also ask whether models will make skills obsolete. Most answers say to stop downloading skill packs. Instead, write a few of your own for repeated, project-specific work. The most common setup keeps them in a git repo, symlinked into each agent's skills folder.
The discussion
The top comment calls downloaded skill packs snake oil, and much of the thread argues over that before getting to logistics. Past the argument it turns practical, with dozens of setups for syncing skills across machines and agents. A long tail of people plug their own skill managers. A loud minority thinks skills are hype and a README or AGENTS.md does the same job.
Write your own, skip the packs
Most commenters dropped skill packs from influencers and marketplaces, which mostly restate what the model knows and fill the context with descriptions. The skills that last come from your own repeated work. Ask the agent to save a good session as a skill, then retest it in fresh sessions until it works on the first try. A few still browse public repos for ideas, and Matt Pocock's skills and obra's superpowers came up as exceptions worth reading.
I feel like downloading a bunch of skills is another one of those useless collections people make purely because they have infinite options. It’s like those collections of thousands of bookmarks you’re never going to click or pirated ebooks you’re never going to read.
When it does it correctly, ask it to make a skill for it. Clear the session, try to use the skill, fix any problems found, modify your repo and harness if necessary. Repeat until skill works 0-shot.
Where skills pay off
Defenders say a skill carries knowledge the model can't infer, like which key connects to which server or how a proprietary XML format looks. Without it the agent spends tokens rediscovering the same facts every session, and one company measured 2-4x less token output with skills. Several people push the deterministic parts into scripts the skill calls, so the model only handles judgment. Others want a stricter cut, with skills only for behavior the model got wrong on its own.
a concise information dense skill is going to always dominate on tokens-burnt for any given task that requires insider knowledge. it simply gets rid of the entire investigative phase of work.
My company ran a test and found that they reduce token output on flagship model by something like 2-4x, and that number has been *increasing* with newer models.
Isn't this just AGENTS.md?
Many asked how a skill differs from a docs file linked from AGENTS.md, and the answer is loading. AGENTS.md is always in context, while the model sees only a skill's one-line description until it decides to read the rest. Several people built that same router by hand before skills existed and see no real difference. One commenter keeps gotchas in AGENTS.md because the model reliably reads it, and treats skills as optional reference.
The agents.md always goes into context. Detailed testing or process information might be excessive, when agent is working on UI. Skills are pulled when needed.
skills are just an agents.md broken up into chunks so you can manage and share them separately.
Git, symlinks and plugins
The most common setup is a git repo of skills, often in dotfiles, symlinked into ~/.claude/skills, ~/.codex/skills and the rest by a script. Others note that Codex and Claude Code both read ~/.agents/skills, and project-specific skills stay in the project repo. Teams use plugin marketplaces, startup hooks that refresh shared skills, or tools that pin a content hash so a skill can't change silently. At least fifteen commenters linked a sync tool or registry they wrote, and one person said the question looked like a setup for exactly that.
There is an installer script that symlinks to the skills. Updating the skills on a machine is then just a matter of advancing the git repo.
We keep the skills in a repo, where an agentic workflow runs biweekly to check if their content drifted compared to the docs and opens PRs if they did.
Testing and pruning
One camp writes evals, regression tests that assert a skill still produces the expected behavior. Skeptics reply that evals for anything beyond trivial cases take far longer than the skill did. Most people test by use, and some keep a skill that diagnoses a failure and rewrites the offending skill. Others prune on a schedule, deleting skills to see whether the model does fine without them.
People always say this about the evals, but I find it hard to have a practical implementation of such a thing where you won’t end up spending 100x the amount of time on the evals than building the skill itself.
Consensus
Downloaded skill packs rarely help. Write a handful yourself for workflows specific to your team or project, keep them in version control, and delete the ones you stop using.
Dissent
A vocal group says skills are a marketing name for a markdown file. To them a README, AGENTS.md or plain prompting does the job, and each model release makes skills less useful. One team dropped skills for code that drives the agent deterministically.