Agent Skills
by mooreds on 2/3/2026, 2:09:54 PM
Comments
by: iainmerrick
This stuff smells like maybe the bitter lesson isn't fully appreciated.<p>You might as well just write instructions in English in any old format, as long as it's comprehensible. Exactly as you'd do for human readers! Nothing has really changed about what constitutes good documentation. <i>(Edit to add: my parochialism is showing there, it doesn't have to be English)</i><p>Is any of this standardization really needed? Who does it benefit, except the people who enjoy writing specs and establishing standards like this? If it really is a productivity win, it ought to be possible to run a comparison study and prove it. Even then, it might not be worthwhile in the longer run.
2/3/2026, 3:09:04 PM
by: CuriouslyC
Pro tip: create README.md files in subfolders with helpful content that you might put in an AGENTS.md file (but, ya know, for humans too), and *link relevant skills there*. You don't even have to call them skills or use the skills format. It works for everything (including humans!).<p>I wrote a rant about skills a while ago that's still relevant in some ways: <a href="https://sibylline.dev/articles/2025-10-20-claude-skills-considered-harmful/" rel="nofollow">https://sibylline.dev/articles/2025-10-20-claude-skills-cons...</a>
2/3/2026, 4:13:13 PM
by: davidkunz
Please standardize the folder.<p><pre><code> .claude/skills .codex/skills .opencode/skills .github/skills</code></pre>
2/3/2026, 2:45:42 PM
by: jgmedr
Our team has found success in treating skills more like re-usable semi-deterministic functions and less like fingers-crossed prompts for random edge-cases.<p>For example, we have a skill to /create-new-endpoint. The skill contains a detailed checklist of all the boilerplate tasks that an engineer needs to do in addition to implementing the logic (e.g. update OpenAPI spec, add integration tests, endpoint boilerplate, etc.). The engineer manually invokes the skill from the CLI via slash commands, provides a JIRA ticket number, and engages in some brief design discussion. The LLM is consistently able to one-shot these tickets in a way that matches our existing application architecture.
2/3/2026, 2:59:39 PM
by: ef2k
I'm not disagreeing with standards but instead of creating adapters, can't we prompt the agent to create its own version of a skill using its preferred guidelines? I don't think machines care about standards in the way that humans do. If we maintain pure knowledge in markdown, the agents can extract what they need on demand.
2/3/2026, 4:12:20 PM
by: thisisthenewme
My unproven theory is that agent skills are just a good way to 'acquire' unspoken domain rules. A lot of things that developers do are just in their heads, and using 'skills' forces them to write these down. Then you feed this back to the LLM company for them to train on.
2/3/2026, 4:06:22 PM
by: time0ut
I am working on a domain specific agent that includes the concept of skills. I only allow one to be active at a time to reduce the chances for conflicting instructions. I use a small sub-agent to select/maintain/change the active skill at the start of each turn. It uses a small fast model to match the recent conversation to a skill (or none). I tried other approaches, but for my use case this was worked well.<p>My model for skills is similar to this, but I extended it to have explicit use when and don’t use when examples and counter examples. This helped the small model which tended to not get the nuances of a free form text description.
2/3/2026, 3:31:57 PM
by: Soerensen
The observation about agents not using skills without being explicitly asked resonates. In practice, I've found success treating skills as explicit "workflows" rather than background context.<p>The pattern that works: skills that represent complete, self-contained sequences - "do X, then Y, then Z, then verify" - with clear trigger conditions. The agent recognizes these as distinct modes of operation rather than optional reference material.<p>What doesn't work: skills as general guidelines or "best practices" documents. These get lost in context or ignored entirely because the agent has no clear signal for when to apply them.<p>The mental model shift: think of skills less like documentation and more like subroutines you'd explicitly invoke. If you wouldn't write a function for it, it probably shouldn't be a skill.
2/3/2026, 3:10:01 PM
by: esafak
Does anyone find that agents just don't use them without being asked?
2/3/2026, 2:23:33 PM
by: nstfn
Started to work on a tool to synchronize all skills with symlinks. Its ok for my needs at the moment but feel free to improve it its on GH: <a href="https://github.com/Alpha-Coders/agent-loom" rel="nofollow">https://github.com/Alpha-Coders/agent-loom</a>
2/3/2026, 3:51:04 PM
by: Frannky
I started playing with skills yesterday. I'm not sure if it's just easier for the LLM to call APIs inside the skill — and then move the heavier code behind an endpoint that the agent can call instead.<p>I have a feeling that otherwise it becomes too messy for agents to reliably handle a lot of complex stuff.<p>For example, I have OpenClaw automatically looking for trending papers, turning them into fun stories, and then sending me the text via Telegram so I can listen to it in the ElevenLabs app.<p>I'm not sure whether it's better to have the story-generating system behind an API or to code it as a skill — especially since OpenClaw already does a lot of other stuff for me.
2/3/2026, 2:43:56 PM
by: falloutx
All these sites just look exactly like claude code skills doc.
2/3/2026, 4:08:38 PM
by: appsoftware
I use a common README_AI.md file, and use CLAUDE.md and AGENTS.md to direct the agent to that common file. From README_AI.md, I make specific references to skills. This works pretty well - it's become pretty rare that the agent behaves in a way contrary to my instructions. More info on my approach here: <a href="https://www.appsoftware.com/blog/a-centralised-approach-to-ai-llm-agent-instruction-using-git-submodules" rel="nofollow">https://www.appsoftware.com/blog/a-centralised-approach-to-a...</a> ... There was a post on here a couple of days ago referring to a paper that said that the AGENTS file alone worked better than agent skills, but a single agents file doesn't scale. For me, a combination where I use a brief reference to the skill in the main agents file seems like the best approach.
2/3/2026, 3:08:02 PM
by: alsetmusic
A link from a couple weeks back suggests that putting them in first-person makes them get adopted reliably. Something like, "If this is available, I will read it," vs "Always read this." Haven't tried it myself, but plan to.
2/3/2026, 3:14:56 PM
by: baalimago
Please help me understand. Is a "skill" the prompt instructing the LLM how to do something? For example, I give it the "skill" of writing a fantasy story, by describing how the hero's journey works. Or I give it the "curl" skill by outputting curl's man page.
2/3/2026, 3:39:34 PM
by:
2/3/2026, 3:34:02 PM
by: Sherveen
I think skills are probably a net positive for the general population, but for power users, I do recommend moving one meta layer up --<p>Whenever there's an agent best practice (skill) or 'pre-prompt' that you want to use all the time, turn it into a text expansion snippet so that it works no matter where you are.<p>As an example, I have a design 'pre-prompt' that dictates a bunch of steering for agents re: how to pick style components, typography, layout, etc. It's a few paragraphs long and I always send it alongside requests for design implementation to get way-better-than-average output.<p>I could turn it into a skill, but then I'd have to make sure whatever I'm using supported skills -- and install it every time or in a way that was universally seen on my system (no, symlinking doesn't really solve this).<p>So I use AutoHotkey (you might use Raycast, Espanso, etc) to config that every time I type '/dsn', it auto-expands into my pre-prompt snippet.<p>Now, no matter whether I'm using an agent on the web/cloud, in my terminal window, or in an IDE, I've memorized my most important 'pre-prompts' and they're a few seconds away.<p>It's anti-fragile steering by design. Call it universal skill injection.
2/3/2026, 2:59:48 PM
by: dk8996
Is there a skill directory that can be browsed by a human?
2/3/2026, 3:13:29 PM
by: tallesborges92
I realized that amp uses ~/.agents/skills<p>I liked that idea to have something more CLI agnostic
2/3/2026, 2:48:31 PM
by: JulianHart
Interesting format, but skills feel like optimizing the wrong layer. The agents usually don't fail because of bad instructions — they fail because external systems treat them like bots.<p>You can have the perfect scraping skill, but if the target blocks your requests, you're stuck. The hard problems are downstream.
2/3/2026, 3:20:36 PM
by: onurkanbkrc
If u wanna browse, search and download AI agent skills, use openskills.space
2/3/2026, 3:23:26 PM
by: empath75
Experimenting with skills over the last few months has completely changed the way I think about using LLMs. It's not so much that it's a really important technology or super brilliant, but I have gone from thinking of LLMs and agents as a _feature_ of what we are building and thinking of them as a _user_ of what we are building.<p>I have been trying to build skills to do various things on our internal tools, and more often then not, when it doesn't work, it is as much a problem with _our tools_ as it is with the LLM. You can't do obvious things, the documentation sucks, api's return opaque error messages. These are problems that humans can work around because of tribal knowledge, but LLMs absolutely cannot, and fixing it for LLM's also improves it for your human users, who probably have been quietly dealing with friction and bullshit without complaining -- or not dealing with it and going elsewhere.<p>If you are building a product today, the feature you are working on _is not done_ until Claude Code can use it. A skill and an MCP isn't a "nice to have", it is going to be as important as SEO and accessibility, with extremely similar work to do to enable it.<p>Your product might as well not exist in a few years if it isn't discoverable by agents and usable by agents.
2/3/2026, 2:21:42 PM
by: nzoschke
Are there good techniques for testing / benchmarking skills effectiveness?
2/3/2026, 2:26:29 PM
by: orliesaurus
one good thing vercel did, was indexing skills.md under a site skills.sh - and yes there are now 100s of these sites, but I like the speedy/lite approach from vercel's DX, despite me not liking vercel a whole lot
2/3/2026, 2:22:53 PM
by: noodletheworld
Is it just me, or do skills seem enormously similar to MCP?<p>…including, apparently, the clueless enthusiasm for people to “share” skills.<p>MCP is also perfectly fine when you run your own MCP locally. It’s bad when you install some arbitrary MCP from some random person. It fails when you have too many installed.<p>Same for skills.<p>It’s only a matter of time (maybe it already exists?) until someone makes a “package manager” for skills that has all of the stupid of MCP.
2/3/2026, 2:47:35 PM
by: sergiotapia
Sounds like a bunch of bullshit to me. A simple markdown file with whatever and a directory will do the same. This is just packaging, selling and marketing.
2/3/2026, 3:59:54 PM
by: voidhorse
It's hilarious that after all those years of resistance to technical writing and formal specification engineers and programmers have suddenly been reduced to nothing more than technical writers and specification designers. Funny that I somehow don't foresee technical writing pay bumps happening as a consequence of this sudden surge in importance.
2/3/2026, 2:39:40 PM
by:
2/3/2026, 2:11:32 PM
by: maximgeorge
[dead]
2/3/2026, 3:57:42 PM