Ask HN: How do you manage skills files?

Get them under version control. I have a git repo with my skills for software development [1]. 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. One of the skills comes with some bash scripts, but the rest are effectively just prompts. Putting project specific skills in projects works well.

I make sure they work by understanding every skill, reviewing pull requests, and testing the end product. The result is rarely perfect, so I am constantly tweaking the skills and how I use AI.

[1] https://github.com/gregwebs/skills-sdlc/

Skills are mostly snake oil, the way people use them (the aspiration to download kung foo from a celebrity).

There was a time when maybe it mattered (last year), but with good repos and good prompts today's agents can find exactly what they need without any skills.

"Skills" as developer macros can be useful, but at most those are things shared with the team (in the repo), not something you download from the internet. If you have so many skills that you feel the need to manage them, that's a code smell.

- I don't find skills, I create them

- Keep them organised in software repos that you install with symlinks for all coding harnesses that you have. Progressive disclosure based on the frontmatter does the rest.

- I make sure they work with AI evals. Think of them like integration tests to prove behaviour. They're useful to optimize your flows. I try to make my skills be mostly a translation between natural language and good small fast tools that they call.

- I change them as a new problem arises. Not just because.

Skills can't be eaten by model capabilities if skills represent a workflow that is custom to my team or my person.

I wrote about a good mental model in the past:

https://alexhans.github.io/posts/series/evals/building-agent...

I basically create a skill when I'm tired of always writing the same prompts, and then I adapt it over time.

I have like 3 skills, and so far so good, most of my recent changes have been asking Claude to please stop using metaphors and creative figures of speech that make the documents so much harder to read and understand (maybe it's only annoying to non-native speakers, I don't know)

Surprised it has not been mentioned, but I think relying on https://github.com/vercel-labs/skills is sound. It handles global installs for a wide range of coding agents. If I was working on an internal only skill I'd probably still use the same foundation.

I don't use any skills, what kinds of skills are people finding most useful?

For general tasks, the model seems perfectly capable of figuring out things itself, for project or environment specific tasks, I just put that information in the readme or agents.md file.

Last week I had to reuse homemade skills on different project. I very much liked the AI proposed solution and it works quite well: ship as a plugin and add your git repo as a marketplace.

The installation is effortless and I don't have to mess with symlinks as I may be working with same codebase on different platforms which would make things.. different.

  codex plugin marketplace add "https://path-to-my-git-repo"
  codex plugin add agent-tools@mycompany

  claude plugin marketplace add "https://path-to-my-git-repo"
  claude plugin install agent-tools@mycompany

Let the AI generate .json files for marketplace.

Haven't got to these bits yet, but I'm sure they will work as easy as install does.

  claude plugin marketplace update mycompany
  claude plugin update agent-tools@mycompany

for skills related to specific cli tools, i just wrote a standard for this! it's obviously not widely used yet, but since mise will support installing the skills alongside the tool, i suspect it will have decent adoption

i used to be a bit bearish on skills—thinking that llms should just use --help, but i've come around on that. i think skills are a great way to describe higher level workflows that use multiple commands.

https://jdx.dev/posts/2026-09-05-introducing-packslip/

Personally I have found "meta-prompting" to be much more useful than any pre-canned set of skills. Simply ask the AI (inside of a workspace already set up):

Create a standalone prompt to <xyz>

The latest AIs will print out a long prompt with all of the assumptions, tools, and general files it plans to use. Review that, and then run the whole prompt in a new context.

Here's how I do it:

- Explanation: https://www.minid.net/2026/7/14/how-to-automatise-with-ai

- Git source: https://github.com/meerita/monorepo-nextjs-golang-rust-pytho...

I commit them to git(so complete team leverages them)., each repo has kind of different skills and the skills are the ones which I update at least twice a week. I’ve skills on how to add instrumentation , debug, code, code review, tech design review etc. I found most of the skills I find on skills.sh are not very useful for me., but I browse occasionally to get some inspiration. One more paradigm I’m seeing good results on adding new skills is ‘how to do X’, for instance ‘how to add logs’., “how to review code” etc., if i’m not able to frame it that way I don’t think it’s a good use case for me to add that skill to the llm arsenal.

Another thing i discovered is less is more (in case of skills as well)., don’t add lots of skills., keep them very handful - I’ve got 9 skills so far (many people have 100s installed from marketplaces and plugins)

I don't like skills. It's a really annoying form of technical debt, especially when people try to fill up company repos with random skills they think are so cool. Same goes for polluting a repo with custom instructions.

I only want the model to have the tools it needs to get the job I ask of it done.

5 Stages using local GIT (no remote, don't need it) to prevent preloading in the prompt:

1. A single Skill finder skill, loaded in the prompt, prevents having to import all the summaries in the prompt the harness would add. Uses git's own search.

2. Private repo, per agent, contains main (production) and draft-<name of skill> branches.

3. Shared repo, like 2, but general access for all group agents.

4. Fallback mode, search the harness for skills using the harness mechanism when a relevant skill cannot be found.

5. Skill audit cron. Identify junk skills / drafts that have never changed / not in any recent sessions history, and categorise monthly for me to decide.

This means it's compatible with existing skill folders, removal of git and the finder skill is non destructive and critically debloats the prompt of skills that aren't used and lazy loads them when needed.

To the extent that skills are contextual guidance (for this author, this project, etc) and not just (raw) capabilities they are unlikely to be eaten by models.

I maintain all my skill files in a central location (like dotfile management) and have guix home sync it to the skill folders of various harnesses that I'm playing with (codex, pi, antigravity, Claude Code, Deepseek harness, etc). They're set up to be bidirectional links rather than read-only like the default configuration, so I can keep editing them / adding to the corpus from any harness.

This works well for skills since all harnesses expect the same format, but is more annoying for other features.

EDIT: This is actually an example of a potentially useful skill. You might choose to manage your skills slightly differently. All you need to do is write a skill-management skill for your agents to be able to wire things up correctly / access them for edits.

Some other nifty skills/plugins in my experience: render latex equations, cetz diagrams inline, jujutsu, guix, code reviewer, writing feedback.

When I work on a new problem and the agent struggles with it, I will ask the agent to distill the knowledge and experiences it gained during the session into a skill file. Then I review and publish it depends on the assistant system. I find this is an effective way for the agents to learn new skills, both from its own discoveries but also from my steering and the mistakes it made.

If you work in a niche or on special problems, this template could be useful.

I've got a skill repository on github, and I got a hermes automation to sync skills repo - this hermes automation is on every device. Any skills I make on the fly - my global AGENTS.md has instructions to update the skills repo path and place them appropriately in there.

I don’t seem much point to intentionally curating a set of skills, and specifically invoking them by name, only to watch the ai skip them all and do better by just reading code and internal/external websites.

We have an ongoing discussion and some fans of https://microsoft.github.io/apm/

Because it's from Microsoft and sounds sufficiently enterprisey probably.

Nowadays I often create skills myself (or with the aid of coding assisants) for any repeating tasks. For example, I use my own skill to make Claude CLI send the worktree to codex cli for the review, then read the verdict and make changes

I have created a little system for this, placed directly in the ~.<youragent>/skills folder.

I have a configuration file of marketplaces and other skills to fetch, it can look like. I have my own marketplaces as well, including ones from my company. I use vercel's tool for managing skills with npx, but to easily handle specifically _which_ skills to fetch, the config file is set up as follows:

  SOURCES = {
    'some-marketplace-name': [
        'some-skill',
        'another-skill',
        'yet-another',
    ],
    'https://designsystem.yourcompany.com': [], (empty list: fetch all skills)
  }

from there I simply run "skills.py" (a single helper) to clean/fetch updated versions of the skills.

I don't use skills unless I have something specific to tell the agent. For example, if I want the agent to use Tailwind V3 instead of V4, I'll have a skill for that. Or, if I want the agent to always use the repository pattern for database access, I'll create a skill for that.

I don't need to manage skills files because I have so few of them and they're only a couple lines long.

I manage them as part of my dotfiles using chezmoi. A `.agents/skills/` directory + a symlink to there from `.claude/skills/`.

> Do you keep improving them over time?

In my global AGENTS.md I have a note to agents to explain any frustrations they had doing a task, and to suggest any skill/tool/AGENTS.md improvements. I am trying to keep AGENTS.md files small but still finding the balance.

Lookup the Claude managed agents architecture for skills, they have a kind of progressive exposure where skills have a title that triggers the skill, an index file that is loaded when triggered, and additional files and scripts that are available once triggered but not loaded by default.

The main problem I encountered around this is that skills need to be edited across projects and across team members in a controlled way. Git is of course required for this but is not enough so I built a tool to do just that:

https://github.com/genged/capshelf

Using capshelf I manage my skills across projects. When I start a new project I can just:

$ capshelf add security-review

From the skill repo.

And if I create a new skill I can promote it to the repo so everyone can install it:

$ capshelf promote security-review

It pins the skill content hash so there are no unexpected edits that can break your flow. It also supports MCP configs and agent configs.

Skills that are so generic that you can find them on the internet, and which you think can be replaced by model improvements, are useless, possibly even harmful, considering how much the models get clingy to the context. Useful skills describe workflows specific to your project, and they can live in the project repo for everyone to use and improve.

I'm on mobile but the first skill I made was a skill improvement skill. This is basically stating that if the AI struggles in another skill but finds a way that the skill it used needs reworking and it needs to do so.

There is a rule to always use this skill and then track notes in a version file. Then back it up in a share folder or external drive.

Skills have made my tools immensely better, cheaper to use and faster. I've also added to it that it should write scripts it can just use in the future to do tasks like query information it needs to answer questions.

I wish there was a better way to share these over a team but I haven't taken that time yet.

Skills live in two source-of-truth git repos (private and public). Agents edit skills by my request, and syncs to all coding agents ~/.claude/skills/, ~/.codex/skills, ~/.pi/agent/skills, ~/.config/opencode/skills etc. with agent written sync-agent-skill script. script ensures that no local changes was made in-place.

Never understood the “skills” part tbh. Thse models are being trained in trillions of texts. Adding something small and particular about my codebase doesn’t really move the needle

If I have a session with something that I expect to do it again, I ask Claude to make a skill out of it and store at user level somewhere at ~./claude/skills I think, so next time I can do just "/xyreport from-to" for example and dont have worry about leaving out things from the prompt or to rediscover some gotchas the agent ran into.

I don't use them.

Everything is organised into repos, i select the directories with the context the agent needs for the task. If I want it to adjust something in my homelab, I drop it into the homelab repo. Stuff agents need to do commonly has shell scripts to speed it up.

I do however have some system prompts. I pick the prompt based on the goal, whether I want to implement something, or just web search, or just need a short one-off command to be done.

I’ve tried to keep up with “best practices” around AI use, but things are improving so quickly that I’ve largely given up. The vanilla agents are just fine for my needs as they come.

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. The repo is also a Claude plugin. The biggest problem is keeping skills up to date across users, so I developed a small Go binary that takes care of that across harnesses.

I run AI on my server. All skills and relevant info is saved to a Wiki. Agent only has an instruction to check the wiki (MCP) at the beginning and get the necessary context.

I create and refine my own skills and commit them to my dotfiles repository.

Disclaimer: I hand curate them in the end

I keep most of my sessions in Zed (you can import them there anyway). After some big feature I let a frontier agent go over these sessions and suggest improvements. Typically I use gemini for this because it's really good at pruning text. Claude/GPT really wants to append more text for some reason.

I end up with smaller skills but more "actioned" skills. They kind of force the agent to do things the way that works well.

I am testing out Skillshare https://skillshare.runkids.cc and I am using skills.sh to find skills.

You can have your own skill repository with Skillshare and sync across agents (symlinks or copys).

For the my branch of the Norwegian Government we have a public skill registry and a tool to sync them locally according to what «profile» you select, https://ki-utvikling.nav.no/verktoy

Source at navikt/copilot

I keep my skills in a Home Manager repo and install them into my .claude / .codex / whathaveyou directory through the home manager config. I'll know if they don't work because they are specific instructions on how to git commit, how to merge code, how to author text (without the typical AI tells), or API usage documentation for specific libraries, etc. If they didn't work the agent would do things incorrectly and I'd notice.

And sometimes it doesn't follow the instructions well. I have a skill for that too: it tells the agent, given what it knows about attention and LLM:s in general, to evaluate the instructions and the mistake the LLM made, try to diagnose why it didn't follow the instructions as expected, and come up with an improvement of the skill based on that diagnosis.

by not having them at all.

The internet has broken me. Whenever I see a question like this i now automatically expect it to be some marketing attempt. There will be a product/service/blog post somewhere in the comments.

I have a repo/project called Loadouts & Summons. It has a primary skill, `capsule`.

All skills, MCPs, CLIs, etc. live inside of it. I have it symlinked to all my dev machines so that it doesn't have to be an MCP.

`capsule` is then progressive to dozens of skills/tools thru `capsule` -- ex. `$capsule plannotator [args]`.

In some harnesses, I make it human-invoke only, and call it directly. In others, I let the model invoke it, and it has a top-level description that hints at what's inside.

Maximal context/session start control and capability extension.

We have some company-managed skills, that help coding agents find the relationships between our repos, and our conventions, architecture, and other high-level decisions. These are supposed to be portable between agents, and so distributing them is currently awkward.

We have a bootstrap script to deploy company-managed skills to each developer's "personal" skills. Hooks for codex and claude code try to refresh the skills on each startup.

I recently completely overhauled repo’s skill setup.

I tried to control the execution of tasks performed by each project using claude.md within the project, but claude.md is only read at the beginning of each session, so it felt like the instructions weren’t being properly reflected.

So I revised the strategy to manage frequently used features in skill units. In doing so, instead of organizing skills by project, it was structured to be integrated into the general skills of the individual repo.

When skills are spread out across multiple projects and the number increases, it becomes impossible to keep track of which skills are available, so they end up not being used.

I also think that eventually, once Claude(model) advances, it will be able to replace most of the skills, so I believe registering and managing countless skills actually degrades performance.

the only ones {i use,claude decides to use} regularly come with claude code plugins so they automatically update. i just define the marketplaces and plugins in my .claude/settings.json for the project.

My agents use https://rcarmo.github.io/projects/memento/ to manage shared skills and propose changes. But I also have template projects with skills baked in for some scenarios.

>I believe skills will eventually be eating by model capabilities

a model capability is never going to fill in an unknowable blank that a custom skill (or whatever equivalent your paradigm supports) can.

a model might have the cleverness to whoami and look through the .ssh folder for keys and evidence of past connections when asked to connect to bob, but a skills file can just easily say "We connect to bob using key Z and user X." so that the operation gets done without all this nonsense needless inference as far into the future as the information is valid for.

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.

Instead of managing skills as files, I have been using a simple utility which helps me create, update/attach skills and finally search it across sessions https://github.com/viggy28/recall/

> How do you find skills

I try to keep my collection of community skills short, usually a few established names (mattpocock, mcollina, trailsofbit). And then I check new releases (or when mattpocock published a youtube video for instance :D)

> keep them organized

For skills I wrote myself, I have my own private github repo. I use skills like /commands most of the time, so I can tell if they work straight away.

For community skills, a package manager really helps. vercel-labs/skills and withastro/rosie are good options. I also built one myself: https://github.com/osrim/ski. It has some cool features like an update command and a security scan.

Why do you think like that? "I believe skills will eventually be eating by model capabilities, but until then I'm just looking for a better way to manage things."

Skills is just a tech bro word for a simple markdown file with instructions.

No need to over complicate it. Write down things you feel like re-using. Like how to specifically implement something in your system ("when adding a new API endpoint we need to do x y and z", or "when making a github PR we tag Æ and Å") so you don't have to repeat it. And I mostly add it in cases where it didn't infer it itself. So very reactive, not proactive.

Most public skills are useless and over complicated. Lots of people are spending too much time on their harness, than actually making stuff.

Edit: but do get inspired by public ones. For instance a "grill me" skill can ve be useful, but I find the public one very mumbo-jumbo. But the idea of forcing the agent to ask clarifying questions is good.

I use an agent plugin spec repo. Codex is already compatible with it and it supports skills + MCP definitions.

https://agent-plugins.org/

Don't find them. Ask the AI to do something. 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. Improve with the same process.

This largely works with a specific model, specific harness, specific prompt, specific context. You may need to modify your agent harness to manage skills depending on runtime parameters. Pi is a great general purpose agent for the these modifications.

If you do find other skills and want to use them, put them through the loop above. But keep in mind that since they were created in their own circumstances, they may not work in yours.

Also separate rules from skills. Rules tell AI when to do things, skills tell AI how to do things. Tool call/MCP limitations, agent configurations, and harness extensions, can help it stay on track.

I have my skills in my dotfiles repo, then symlink them to my home directory and/or projects where I want to use them. Project specific ones go into the project.

I have a separate repo which has to be pulled locally and the skills and agents are sym linked to projects.

Openspec has a subcommand (init) to manage them: clever because they provide also an update path.

Any skills, I just add into the tool itself. I then have the py tools in their PWD, don’t bother with mcp.

Not really related but I wonder how people benchmark the effectiveness of skills/agents?

I'm seeing the agent working quite fine with just direct prompting and the agent doing things by itself rather than using skills. Is it better for certain task size?

With a custom skills workspace in mininote

https://mininote.ink/docs/mcp-docs

Agent can use mcp to update its own skills, or I can copy template skills into local dorectories via the api. Very useful, like notion on steroids but is completely free.

i have a docs/

it has all the skills/docs my particular application needs

i treat it as ADRs as it helps the AI understand the parts of the system it is working on

I wrote a small command-line tool that installs skill packs into agent-specific project folders. It works pretty much like `brew` (or any package manager, really). The skills are compiled into the binary so that I don't have to worry about where they're located and can quickly move the skills between machines by copying the tool.

Making sure they actually work? Trial and error, mostly. I know some folks have tried auto-researcher approaches, but I haven't found that to be the best use of time in my work.

how did stupid markdown file become a thing, this industry really went to shit.

[dead]

[dead]

[dead]

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[dead]

[flagged]

[dead]

[flagged]

[dead]

[dead]

Skills are no longer useful.

One of the engineers I know is building this product called SkillEd for just this. Lemme know if you need an invite

WTF is a "skill"? I really think people are getting ahead of themselves here.

You wrote some bullet points so your agent harness doesn't keep making builds in the wrong environment? You have a very specific debugging setup? Your agent doesn't understand when to rebase?

README is where you should be writing anything specific to your project, and if you're worried about context size then your README is too long, it should be just enough information for any competent dev or agent to get the gist of how you do things around here and where to look for deeper answers.

If your particular harness / orchestrator is just not pushing back enough or can't seem to solve certain problems then thats a tool issue, either edit the tool system prompts or move to better tools or models.

Calling this 'skills' is disingenuous, this word was chosen by marketers and implies some kind of deeper learning. I'm not saying there's no value in tuning prompts, but your 'skills' should be managed in only 2 ways: 1. It's specific to your project, it's a README, or 2. It's specific to your tooling, it's part of config, system prompts etc.