>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.

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.

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.

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.

100% - influencers pretend they know something and produce all in one skills pack - that doesn't make sense

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?

Big yes on this. I do not understand the appeal of skill shopping. The one exception I have is things like the Axiom Apple development skills and e.g. the official Flutter skills. At that point the skills are just docs though. It's either I remember to paste a URL to the official docs or I just install the skill. But shopping around for random skills just sounds extremely unappealing.

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.

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.

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.

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.

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.

For starters, if you repeat a specific prompt multiple times per day, you may save it as a skill.

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.

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”.

[flagged]