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.
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
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.
- 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.
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.
Like, ok, I have a debugging skill, now how do I make evals except for the most trivial things?
You don't. If you're using skills to force the AI to fullfill some must criterias, it's not going to work. Must criterias need deterministic checks -> be it hooks or what not.
This is also my biggest gripe with AI. I.e. for specifications, no matter what hype machine I tried, it never fulfilled my criterias, which are: easily verifiable, concise, small specs. Hence I built https://github.com/RicardoMonteiroSimoes/Yamlet initially for claude code, but then decided to use extend it for pi.dev. I now have a dedicated docker image for pi.dev, that only contains Yamlet plugin, and whenever I work on spec I spin it up.
The end result is a .yaml file that easily works in git + git diff, so that I can then proceed with the technical specs-
There are also skills that help LLM do the thing it can do without the skill, but faster (by cutting out unnecessary discovery). I guess for such skills the fail case is "being slow"?
I imagine many fail cases can burn a lot of tokens/usage/time because failing LLMs can be very persistent. Maybe some upper bound (turn count, timeout) would help too.
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.
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 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.
I make skills for «this is how I like to do things in this company / project». Query test database, git branch names, commit message style, which cloud things can be inspected like logs etc. I don’t see the point in trying to teach the models things that is in the documentation of git, python, what have you. They already know.
I try to keep agents/Claude.md as tiny as possible. With high level "truths" that don't change. Stack used, invariants, file structure, and some scripts.
Skills are more for things you do often. I run mutation tests, type check,linting,etc. I _could_ just prompt and copy/paste the same prompt each time I need to, or I can just run /tests.
I also have skills for specialized tasks I need every once in a while, like a ux skill, a text skill optimized for xyz, etc.
Depends on how much information and details you have. 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.
Your agents.md is a good place for high level facts, but if you have something that requires a lot of info to explain (ie: if there is a complex build process, testing patterns, things like that), loading up your agents.md for every request may be a bad idea. Offloading that information to a skill ensures it's only included in the context if you're actually using it.
How about linking to a separate docs file from the Readme, same as how you'd split separate topics into different files for humans? The context cost is low and as far as I can tell it's pretty much how Claude's "memory" feature works.
That splitting is basically what a skill is, with some instructions as to when to load it. Depending on the harness used it might be quite equivalent, but not sure how easy it follows links in the readme compared to skills (which is just a glorified name of a readme anyways)
Right, it's all just text file management. My point is that if I can add a few lines of description with links in my readme/agents/etc instead of manually including skills in the prompt, without any downside, I'd rather do that.
I use skills for offloading work onto subagents. By configuring the skill to use a specific model it gets enforced at the harness instead of depending on the good will of the orchestrating model to actually delegate. This also saves context.
Today Fable had to fetch a zip file from a web page with a eula prompt, then get at a file in a disk image in the zip.
This is something that will need to happen a lot as part of this project.
I asked Fable for a skill/script combo suitable for Haiku to accomplish the task, and now that task happens at minimal cost during an analysis run.
So the term used internally is to make things "Determinishtic". I use skills extensively, combined with SOPs, scripts and MCP servers.
An example skill I have is SessionMiner, which is installed via post session hooks in Claude and Kiro, and analyzes the session, what was accomplished, and whether or not it should be turned into a skill, then when it summarizes it, the decisions it came to and either fires off a message to me for followup if it decides a new skill or tool should be built, or it catalogues the approach so that future analysis can identify trends in how I use the tools.
Over time it has built me a fairly decent stable of repeatable skills and tools, and highlighted process deficiencies and nominated process changes that I have pursued.
Another skill is a communications analysis skill; I started using it summer last year I think, and it scans my communications across a broad cross-section of my activity online. It tracks the commitments I make, ensures that I follow up with people that I might miss, ranks and scores my communication against my own personal targets that I set to make sure that I am communicating effectively. As a person who has had a decently successful career despite autism spectrum and unmedicated ADHD (I was medicated, but unfortunately each medication I tried had adverse side effects), it has made me much more effective in tracking work and following through, especially on the "boring" stuff that is actually critical to being a dependable team member, and effective partner for the teams I support.
You're putting a lot of trust into the judgement abilities of what is just a next token predictor there.
I can see what the goals are there, and they do make sense I suppose, but I'm not confident that what you're handing off there can be handed off to that degree.
But maybe that is not the point and the point instead is to see what the LLM thinks would be correct, and then think about that and collect learnings about the world from it.
It might not be right, but it still tells you how normal people think. So that's useful.
Just a very roundabout way to achieve that, but that's fine, I guess.
Well, for non-general tasks, of course. For example particular tooling that's required for the environment.
I will often make a skill out of the docs for any of the frameworks or libraries that we're using but with which I'm unfamiliar. When I'm creating that skill, I focus on idiomatic implementation and usage. It's not enough for the code to work—I want it to work "with the grain" and "through the front door", as it were.
By default, these models are just all too willing to reinvent the wheel and monkeypatch as they go.
I have a couple of skills with project-specific conventions for how to write a plan and how to write HTML-generating code. But they could probably just as well be .md files in a docs directory, linked to from the AGENTS.md file.
Claude will do this for you after a few times. But yes, I have a skill called plan-to-epic which creates a Jira epic and ticket per milestone. It helps my agents persist context and, because I’m terrible at competing with my coworkers for “visibility,” means I can point to all my work if asked.
> I don't use any skills, what kinds of skills are people finding most useful?
I create/edit/delete at least one skill per day. I can't imagine working effectively without those files.
The most common case: if I see something took AI too much time and tokens and it is done, I ask my Cursor immedietly after to save it as skill. So next time I do the same I just refer to skill. I don't need to remember the name of the skill, I just mention something like "do {explaining briefly the task}, you have done something similar in the past and it is saved as skill"
One way I use skills, which I don’t see mentioned very often, is as “shortcuts”. Imagine some frequently issued prompt like “fetch origin and rebase this branch onto origin/master and resolve conflicts”. I make that into a little skills file called “rebase” with a one sentence description, and next time just type something like “/reb-tab-enter”.
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 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 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 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)
Thats exactly how I use skills as well and I got great results with it.
I work in a proprietary codebase with a lot of niche or custom tooling, weird technical details and historical quirks.
What skills do for me, is essentially skip the "learning" phase of an agent working in the codebase.
With a fitting skill the agent does not need to read the tooling docs, look at existing repos and learn the coding style, but it can get to work immediately.
This is probably less relevant for code that exists a ton in the LLM training data already as an llm is probably competent to some degree in that anyway.
A big caveat here is though that now you need to treat your skills repo very carefully as mistakes in there can easily spread to all of the new code you write using a coding agent.
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:
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.
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.
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.
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.
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
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.
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.
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.
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.
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 believe skills are much more than a simple markdown file with instructions. They are a very powerful script engine. How I organize it is that of course there's a markdown with instructions but I split the work in a hybrid of script + instructions. So all the work that can be deterministic is a python script api surface and all the logical or thinking work is in instructions. and agent is also instructed on how to use the api of the python helper functions. This makes it almost like a normal script but the runtime is a harness and the business logic can be any combination of code + human-level intelligence.
So I like to do all the edge case handling and validation etc via a helper function, and the agent is simply instructed to call the function to do something. It is extremely powerful and a completely different way of automating things. I am constantly forced to re-think how computers are supposed to work and its limitations.
Are there any "skills" at all that have proven to be useful?
And if so, what's the context?
Because, for me anyway, LLMs usually do one thing, and that then produces a durable artifact. So the prompt that got me there by that point expired and is not really needed anymore.
I also occasionally have recurring tasks (rarely though), but there, the prompt to do stuff is embedded in code that orchestrates the doing, so I have no use-case for that either.
___
For the "add this endpoint" example you've described, I just throw commit IDs at the clanker and say "go do that again". That works, and doesn't decouple knowledge from code.
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.
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/
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.
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."
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.
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 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.
Agree here. My philosophy is the "general-purpose" coding agent will keep getting better and better, making skills less and less useful. And it will probably get better at a pace far greater than the customization folks can build around them via skills.
This of course is from my own experience writing code, where agents are already good at software engineering conventions. This probably doesn't hold as well for other tasks, say writing marketing copy with a unique voice
For now, I keep skills pretty minimal - single sentence prompts I send all the time, like "Remove all the slam poetry from the docs in this repo."
I also tend to share often. All skills go into a repo my team can access. No pressure, use them, riff on them, add your own - sharing and engaging on how we do the work is more important than making everyone do the work the same way to me.
What I meant by skills getting eating by models are the "general use" skills, like design critique, code review...ect
But, for custom use skills, ofc no model will be able to replace them and it's not efficient to try to do that as well. For this type of skills I create and maintain them by myself, my question was about "general use" skills, they are everywhere on the internet, how do you manage them?
Do you find any of the general use skills useful? I'm not sure I've ever used any of them, and when I've looked at them it's been some YouTuber trying to make money. That, and their Substack.
I know everyone's down on MCP, but custom-built client side MCP tools are what I find useful instead. But that's me.
If you can express something deterministically with code, it's better to do that rather than have an agent do it, because it's faster, cheaper, and deterministic. E.g. you regularly copy file A to file B. You can ask the agent to do it, or you can write a script and have the agent call the script via skill. That's the beginning of a harness.
Eventually you arrive at building custom software that does a lot in the traditional way, but delegates certain tasks to the model where it makes sense or it's non-trivial/impossible to express via code.
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.
I have been finding them decreasing in the effectiveness with each model release. We got rid of skills and built a determinist harness around the agent instead.
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.
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.
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.
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.
- 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...
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.
Like, ok, I have a debugging skill, now how do I make evals except for the most trivial things?
You don't. If you're using skills to force the AI to fullfill some must criterias, it's not going to work. Must criterias need deterministic checks -> be it hooks or what not.
This is also my biggest gripe with AI. I.e. for specifications, no matter what hype machine I tried, it never fulfilled my criterias, which are: easily verifiable, concise, small specs. Hence I built https://github.com/RicardoMonteiroSimoes/Yamlet initially for claude code, but then decided to use extend it for pi.dev. I now have a dedicated docker image for pi.dev, that only contains Yamlet plugin, and whenever I work on spec I spin it up.
The end result is a .yaml file that easily works in git + git diff, so that I can then proceed with the technical specs-
A skill should only document behaviour the LLM didn't/couldn't exhibit on its own.
So you take your failed case (eg. working with gdb or whatever), write a skill and then test for that failed case.
There are also skills that help LLM do the thing it can do without the skill, but faster (by cutting out unnecessary discovery). I guess for such skills the fail case is "being slow"?
I imagine many fail cases can burn a lot of tokens/usage/time because failing LLMs can be very persistent. Maybe some upper bound (turn count, timeout) would help too.
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.
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 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.
I make skills for «this is how I like to do things in this company / project». Query test database, git branch names, commit message style, which cloud things can be inspected like logs etc. I don’t see the point in trying to teach the models things that is in the documentation of git, python, what have you. They already know.
Isn’t that what the agents.md in your project is for?
Skills are evaluated by short description whether to read them into context.
Skills itself may be lengthy so...
I try to keep agents/Claude.md as tiny as possible. With high level "truths" that don't change. Stack used, invariants, file structure, and some scripts.
Skills are more for things you do often. I run mutation tests, type check,linting,etc. I _could_ just prompt and copy/paste the same prompt each time I need to, or I can just run /tests.
I also have skills for specialized tasks I need every once in a while, like a ux skill, a text skill optimized for xyz, etc.
Depends on how much information and details you have. 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.
Your agents.md is a good place for high level facts, but if you have something that requires a lot of info to explain (ie: if there is a complex build process, testing patterns, things like that), loading up your agents.md for every request may be a bad idea. Offloading that information to a skill ensures it's only included in the context if you're actually using it.
How about linking to a separate docs file from the Readme, same as how you'd split separate topics into different files for humans? The context cost is low and as far as I can tell it's pretty much how Claude's "memory" feature works.
That splitting is basically what a skill is, with some instructions as to when to load it. Depending on the harness used it might be quite equivalent, but not sure how easy it follows links in the readme compared to skills (which is just a glorified name of a readme anyways)
Right, it's all just text file management. My point is that if I can add a few lines of description with links in my readme/agents/etc instead of manually including skills in the prompt, without any downside, I'd rather do that.
I use skills for offloading work onto subagents. By configuring the skill to use a specific model it gets enforced at the harness instead of depending on the good will of the orchestrating model to actually delegate. This also saves context.
Today Fable had to fetch a zip file from a web page with a eula prompt, then get at a file in a disk image in the zip.
This is something that will need to happen a lot as part of this project.
I asked Fable for a skill/script combo suitable for Haiku to accomplish the task, and now that task happens at minimal cost during an analysis run.
Did you consider writing a small Python script for that?
So the term used internally is to make things "Determinishtic". I use skills extensively, combined with SOPs, scripts and MCP servers.
An example skill I have is SessionMiner, which is installed via post session hooks in Claude and Kiro, and analyzes the session, what was accomplished, and whether or not it should be turned into a skill, then when it summarizes it, the decisions it came to and either fires off a message to me for followup if it decides a new skill or tool should be built, or it catalogues the approach so that future analysis can identify trends in how I use the tools.
Over time it has built me a fairly decent stable of repeatable skills and tools, and highlighted process deficiencies and nominated process changes that I have pursued.
Another skill is a communications analysis skill; I started using it summer last year I think, and it scans my communications across a broad cross-section of my activity online. It tracks the commitments I make, ensures that I follow up with people that I might miss, ranks and scores my communication against my own personal targets that I set to make sure that I am communicating effectively. As a person who has had a decently successful career despite autism spectrum and unmedicated ADHD (I was medicated, but unfortunately each medication I tried had adverse side effects), it has made me much more effective in tracking work and following through, especially on the "boring" stuff that is actually critical to being a dependable team member, and effective partner for the teams I support.
Just a couple of examples.
You're putting a lot of trust into the judgement abilities of what is just a next token predictor there.
I can see what the goals are there, and they do make sense I suppose, but I'm not confident that what you're handing off there can be handed off to that degree.
But maybe that is not the point and the point instead is to see what the LLM thinks would be correct, and then think about that and collect learnings about the world from it. It might not be right, but it still tells you how normal people think. So that's useful.
Just a very roundabout way to achieve that, but that's fine, I guess.
Well, for non-general tasks, of course. For example particular tooling that's required for the environment.
I will often make a skill out of the docs for any of the frameworks or libraries that we're using but with which I'm unfamiliar. When I'm creating that skill, I focus on idiomatic implementation and usage. It's not enough for the code to work—I want it to work "with the grain" and "through the front door", as it were.
By default, these models are just all too willing to reinvent the wheel and monkeypatch as they go.
I have a couple of skills with project-specific conventions for how to write a plan and how to write HTML-generating code. But they could probably just as well be .md files in a docs directory, linked to from the AGENTS.md file.
For starters, if you repeat a specific prompt multiple times per day, you may save it as a skill.
Claude will do this for you after a few times. But yes, I have a skill called plan-to-epic which creates a Jira epic and ticket per milestone. It helps my agents persist context and, because I’m terrible at competing with my coworkers for “visibility,” means I can point to all my work if asked.
It's not that, is for: Ensuring certain vetted implementation method is used. E.g. you always want tests or docs, or always done.
Caching certain scripts so it's not reinvented each time with risk of error/need reviewing.
> I don't use any skills, what kinds of skills are people finding most useful?
I create/edit/delete at least one skill per day. I can't imagine working effectively without those files.
The most common case: if I see something took AI too much time and tokens and it is done, I ask my Cursor immedietly after to save it as skill. So next time I do the same I just refer to skill. I don't need to remember the name of the skill, I just mention something like "do {explaining briefly the task}, you have done something similar in the past and it is saved as skill"
Gateway drug is “/grilling” by Matt Pocock.
One way I use skills, which I don’t see mentioned very often, is as “shortcuts”. Imagine some frequently issued prompt like “fetch origin and rebase this branch onto origin/master and resolve conflicts”. I make that into a little skills file called “rebase” with a one sentence description, and next time just type something like “/reb-tab-enter”.
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...
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 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.
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 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)
Thats exactly how I use skills as well and I got great results with it. I work in a proprietary codebase with a lot of niche or custom tooling, weird technical details and historical quirks. What skills do for me, is essentially skip the "learning" phase of an agent working in the codebase. With a fitting skill the agent does not need to read the tooling docs, look at existing repos and learn the coding style, but it can get to work immediately.
This is probably less relevant for code that exists a ton in the LLM training data already as an llm is probably competent to some degree in that anyway.
A big caveat here is though that now you need to treat your skills repo very carefully as mistakes in there can easily spread to all of the new code you write using a coding agent.
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 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.
Codex and Claude Code both respect ~/.agents/skills; you don't need to have ~/.codex/skills and ~/.claude/skills .
Why do you use so many different agents if I may ask?
I mainly use Claude Code, but I had an idea to build an orchestrator for coding agents, so I experimented with several
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.
I create and refine my own skills and commit them to my dotfiles repository.
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.
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.
That's very cool. How does the binary keep skills updated across users?
It clones the skills repo if not present and relies on the git last commit as the "version".
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.
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.
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.
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.
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 believe skills are much more than a simple markdown file with instructions. They are a very powerful script engine. How I organize it is that of course there's a markdown with instructions but I split the work in a hybrid of script + instructions. So all the work that can be deterministic is a python script api surface and all the logical or thinking work is in instructions. and agent is also instructed on how to use the api of the python helper functions. This makes it almost like a normal script but the runtime is a harness and the business logic can be any combination of code + human-level intelligence.
So I like to do all the edge case handling and validation etc via a helper function, and the agent is simply instructed to call the function to do something. It is extremely powerful and a completely different way of automating things. I am constantly forced to re-think how computers are supposed to work and its limitations.
My genuine question is:
Are there any "skills" at all that have proven to be useful? And if so, what's the context?
Because, for me anyway, LLMs usually do one thing, and that then produces a durable artifact. So the prompt that got me there by that point expired and is not really needed anymore.
I also occasionally have recurring tasks (rarely though), but there, the prompt to do stuff is embedded in code that orchestrates the doing, so I have no use-case for that either.
___
For the "add this endpoint" example you've described, I just throw commit IDs at the clanker and say "go do that again". That works, and doesn't decouple knowledge from code.
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.
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/
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.
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."
> 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.
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 use an agent plugin spec repo. Codex is already compatible with it and it supports skills + MCP definitions.
https://agent-plugins.org/
>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.
Agree here. My philosophy is the "general-purpose" coding agent will keep getting better and better, making skills less and less useful. And it will probably get better at a pace far greater than the customization folks can build around them via skills.
This of course is from my own experience writing code, where agents are already good at software engineering conventions. This probably doesn't hold as well for other tasks, say writing marketing copy with a unique voice
For now, I keep skills pretty minimal - single sentence prompts I send all the time, like "Remove all the slam poetry from the docs in this repo."
I also tend to share often. All skills go into a repo my team can access. No pressure, use them, riff on them, add your own - sharing and engaging on how we do the work is more important than making everyone do the work the same way to me.
How do you disseminate that information to humans?
What I meant by skills getting eating by models are the "general use" skills, like design critique, code review...ect
But, for custom use skills, ofc no model will be able to replace them and it's not efficient to try to do that as well. For this type of skills I create and maintain them by myself, my question was about "general use" skills, they are everywhere on the internet, how do you manage them?
Do you find any of the general use skills useful? I'm not sure I've ever used any of them, and when I've looked at them it's been some YouTuber trying to make money. That, and their Substack.
I know everyone's down on MCP, but custom-built client side MCP tools are what I find useful instead. But that's me.
“ determinist harness around the agent ”
Can you explain what this means?
If you can express something deterministically with code, it's better to do that rather than have an agent do it, because it's faster, cheaper, and deterministic. E.g. you regularly copy file A to file B. You can ask the agent to do it, or you can write a script and have the agent call the script via skill. That's the beginning of a harness.
Eventually you arrive at building custom software that does a lot in the traditional way, but delegates certain tasks to the model where it makes sense or it's non-trivial/impossible to express via code.
Openspec has a subcommand (init) to manage them: clever because they provide also an update path.
I have a separate repo which has to be pulled locally and the skills and agents are sym linked to projects.
Any skills, I just add into the tool itself. I then have the py tools in their PWD, don’t bother with mcp.
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.
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
Skills are no longer useful.
I find them very useful.
I have been finding them decreasing in the effectiveness with each model release. We got rid of skills and built a determinist harness around the agent instead.
One of the engineers I know is building this product called SkillEd for just this. Lemme know if you need an invite