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.
>but with good repos and good prompts
I think waaay more people struggle with this than HN would have you believe. In the real world, not everyone is a software dev with a developer mindset to using these tools. Normal people essentially type the equivalent of "Make me X!" and complain when the model assumes anything in their underspecified mess of a prompt. There are skills like grill-me that can potentially help these people a lot, but in the end I believe models will just be smart enough to understand your level of knowledge and intent to do this stuff on their own. They are getting much better on pushing back on poor user input already. The problem is that when they double down on hallucinations (very rare nowadays but I still see it happen in enterprise projects with the latest models). So you kind of need to know when to push back on the model as well. But for that you have to be really good at the subject.
I tend to agree. Skill files become less useful as developer skill increases.
As a skilled developer my repetitive instructions are mostly one or two sentence phrases for staring something like a highly-interactive planning session, or a self-supervised implementation session with my preferred setup of implementation and review subagents. I can specify those out by hand, or save a couple keystrokes with a tiny skill file.
But if you are not a software dev you might lack the vocabulary to tell the agent what you want. If you don't know what tenant isolation is, chances are your app will have a broken security model because you can't ask for it, and probably won't think to ask the agent for a security review either. Skills can mitigate a lot here
It's not about giving hints to agents because they wouldn't find it out otherwise. It's about saving the work of them having to find out. Good skills files save tokens.
Having too many skills files increase tokens even when they don't get fully read. It's a fine line.
That's why you need to curate and adapt the skills for your specific project. That is, don't blindly accumulate skills downloaded from the web
> "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 have three development machines. You kinda need something like git to keep everyone in sync!
And there's still value in encoding a process in a skill - it's way more token efficient to tell the model what but also HOW to do something. Otherwise, it just spends a lot of tokens figuring out something that they previously did already.
Yes, skills as a "portable power" isn't really the use case for me unless it's entirely generic and even then sparingly.
I've mostly followed what anthropic suggests, which is putting less into context and more into skills, to keep the "how" out of context until it is needed to reduce context bloat.
Skills have some instructions but are primarily informed repo specific instructions and keep their context away from the rest of the repo to keep things sanitised for me.
I've found it to be useful in that context.
> Skills have some instructions but are primarily informed repo specific instructions and keep their context away from the rest of the repo to keep things sanitised for me.
Skills and agents in the Claude world can also be extended and evolved over time, as they are committed "code".
For example, we have an agent which can take a statement or a support ticket and identifies the services, tenants and infrastructure components likely meant in the ticket or request. Similar to a skill, Claude can invoke this on demand in a conversation.
This started very simple, but various people spent time tuning it over the last 4-6 months. They have "taught" it to pick up on jargon from different departments, writing style of different departments, how they think about their systems.
With all of that tuning over time it has become quite "clever" in identifying the mentioned systems and - if requested - the train of thought leading to this conclusion.
Similar things are happening with skills for various task, be it Ansible integration tests, upgrade chores and so on. The first version can be fairly underwhelming, but continuously improving it after each usage can make them very powerful.
Where they are very useful is as a documentation source for LLMs. For example, I work in infosec and often have to reference DSLs (Cobalt Strike aggressor script for example). Having a skill which is an offline index to carved up function docs, which an LLM can use without having to think, then search for, then download huge 1 page documents with all function documentation, and pollute the context… very useful.
Depends on what you do. If you work with proprietary tech that is not in LLM training data and can't easily be found on the internet, you're cooked without good skill files.
I agree it depends, but I can offer another angle: By writing a few py tools and creating skills around them I was able to save tokens, so these skills were cost-effective in my case, they lowered the cost of the tasks I execute.
If you are spending time on all text forums like this, you are likely a person whose skill set skews towards the verbalization of abstract concepts. This is also the exact skill set needed to use LLMs well. If you are able to articulate exactly what you want in a concise prompt, little else is needed.
I think we tend to overlook the fact that LLMs have tilted the scales heavily in favor of those with good verbal skills. A huge portion of the population (including a portion of highly skilled software engineers) is not great at doing this. For them, harness skills still act as a kind of scaffolding; they support automated work on a project in cases where insufficient details is given in the prompt.
The closest I get to finding skills useful is when I find myself repeating myself to an LLM. This tends to happen most when I am starting new projects and want to communicate basic design principles and patterns to follow and libraries to use. What I did was to factor and store these "chunks" of instruction in some text files. I then made a little script that can list what chunks are available and when given a subset will essentially `cat` the selected files to emit AGENTS.md content which I save into the new project or append to shore up an existing one.
Your observation on the readership bias of HN is a good one for people to add to their HUMANS.md before reading and commenting. :)
This could be better summed up to the misuse of skills. Skills were not designed to be a way to make an agent more intelligent. Instead, skills are designed to allow agents to have certain tasks that are repeatable and predictable. It’s a misnomer really.
I find them useful for deploying task specific agents, like reviewing Jira tickets, or otherwise ensuring compliance in open format submissions.
Otherwise I agree, and you don't even have to be that verbose with prompt engineering these days as LLMs have gotten increasingly good at figuring out what you want.
100% - influencers pretend they know something and produce all in one skills pack - that doesn't make sense
i agree, skills downloaded from the internet are all snake oil.
creating your own skills however good for both reducing the token usage & increasing reliability. those damn llms are not deterministic, asking same thing twice produces 2 different results.
Woaaah buddy this is such a wrong statement that I’d delete it if I were you.
Can’t believe that people confidently spew blatantly false statements like this.
Skills matter, a lot, to every action that requires the AI to find stuff out, so that it doesn’t have to find the same stuff out again. Operating a website, building PowerPoints the way you like them, operating across different surfaces like APIs + GUIs…otherwise the AI has to relearn how to do it every time.
Be confident about things you know. Study about things you don’t.
Not everyone use AI only for coding, for “code smell” being even applicable here. Many of my skills are just processes distilled from actual sessions doing odd tasks and coordinating different tools. It’s pretty reasonable to assume that it saves the agent from repeating that first time exploration fumbling