[simonw]

Part of it is that they gave a name to a useful pattern that people had already been discovering independently. Names are important, because they mean we can start having higher quality conversations about the pattern.

Anthropic also realized that this pattern solves one of the persistent problems with coding agents: context pollution. You need to stuff as little material as possible into the context to enable the tool to get things done. AGENTS.md and MCP both put too much stuff in there - the skills pattern is a much better fit.

[behnamoh]

I think you're overly enthusiastic about what's going on here (which is surprising because you've seen the trend in AI seems to be re-inventing the wheel every other year...)

[simonw]

I'm more excited about this than I was about MCP.

MCP was conceptually quite complicated, and a pretty big lift in terms of implementation for both servers and clients.

Skills are conceptially trivial, and implementing them is easy... provided you have a full Linux-style sandbox environment up and running already. That's a big dependency but it's also an astonishingly powerful way to use LLMs based on my past 6 months of exploration.

[carlgreene]

I’m curious some of the things you’re having the LLM/agents do with a full Linux sandbox that you wouldn’t allow on your local machine

[simonw]

I remain afraid of prompt injection. If I'm telling Claude Code to retrieve data from issues in public repos there's a risk someone might have left a comment that causes it to steal API keys or delete files or similar.

I'm also worried about Claude Code making a mistake and doing something like deleting stuff that I didn't want deleted from folders outside of my direct project.

[ajtejankar]

With so many code sandbox providers coming out I would go further than you say that this is almost a non-problem.

[causal]

Strong disagreement on the helpfulness of the name- if anything calling a context file a skill is really misleading. It evokes something like a LoRA or pluggable modality. Skill is the wrong name imo

[simonw]

I think skill is the perfect name for this. You provide the LLM with a new skill by telling it how to do a thing and providing supporting scripts to help it do that thing.

[ajtejankar]

Yup! I fully agree. It also taps into the ability of LLMs to write code given good prompts. All you need is for the LLM to recognize that it needs something, fetch it into the context, and write exactly the code that is needed in the current combination of skill + previous context.

[causal]

You've described instructions. It already had a name.

[simonw]

"Instructions" doesn't cover the bit where you have a folder with markdown with YAML frontmatter metadata plus additional executable scripts - which can then be shared with others.

[ajtejankar]

IMO LoRAs are no different from context tokens. In fact, before LoRAs tuned prompt vectors were a popular adapter architecture. Conceptually, the only difference is that prompt adapters only interact with other tokens through the attention mechanism while LoRAs allow you to directly modify any linear layer in the model. Essentially, you can think of your KV cache as dynamically generated model weights. Moreover, I can't find the paper, but there is some evidence that in-context learning is powered by some version of gradient descent inside the model.

[causal]

LoRA's are more robust than context tokens - their influence remains strong over long contexts and do a much better job of actually changing behavior rather than mimicking a desired behavior via instruction.

But even if LoRA isn't it - the point is that "skill" seems like the wrong term for something that already has a name: instructions. These are instruct-tuned models. Given instructions they can do new things; this push to rebrand it as a "skill" just seems like marketing.

[f38zf5vdt]

It's baffling to me. I was already making API calls and embedding context and various instructions precisely using backticks with "md". Is this really all this is? What am I missing? I don't even understand how this "feature" merits a press release from Anthropic, let alone a blog post extolling it.

[simonw]

A few things:

1. By giving this name a pattern, people can have higher level conversations about it.

2. There is a small amount of new software here. Claude Code and https://claude.ai/ both now scan their skills/ folders on startup and extract a short piece of metadata about each skill from the YAML at the top of those markdown files. They then know that if the user e.g. says they want to create a PDF they should "cat skills/pdf/skill.md" first before proceeding with the task.

3. This is a new standard for distributing skills, which are sometimes just a markdown file but can also be a folder with a markdown file and one or more additional scripts or reference documents. The example skills here should help illustrate that: https://github.com/anthropics/skills/tree/main/document-skil... and https://github.com/anthropics/skills/tree/main/artifacts-bui...

I think the pattern itself is really neat, because it's an acknowledgement that a great way to give an LLM system additional "skills" is to describe them in a markdown file packaged alongside some relevant scripts.

It's also pleasantly vendor-neutral: other tools like Codex CLI can use these skills already (just tell them to go read skills/pdfs/skill.md and follow those instructions) and I expect they may well add formal support in the future, if this takes off as I expect it will.

[ajtejankar]

I have been independently thinking about a lot of this for some time now. So this is so exciting for me. Concretizing _skills_ allows, as you said, a common pattern for people to rally around. Like you, I have been going dizzy about its possibilities, specially when you realize that a single agent can be modified with skills from all its users. Imagine an app with just enough backbone to support any kind of skill. From here, different groups of users can collaborate and share skills with each other to customize it exactly to their specific niche skills. You could design Reddit like community moderation techniques to decide which skills get accepted into the common repo, which ones to prioritize, how to filter the duplicates, etc.

[causal]

I was puzzled by the announcement and remain puzzled after this blog post. I thought everyone knew you could keep use case specific context files handy.

[cma]

If also seems to be the same thing as subagents, but without clearing context, right?

[greymalik]

How is it different from subagents?

[simonw]

They complement each other.

Subagents are mainly a token context optimization hack. They're a way for Claude Code to run a bunch of extra tools calls (e.g. to investigate the source of a bug) without consuming many tokens in the parent agent loop - the subagent gets its own loop, can use up to ~240,000 tokens exploring a problem and can then reply back up to the parent agent with a short description of what it did or what it figured out.

A subagent might use one or more skills as part of running.

A skill might advise Claude Code on how best to use subagents to solve a problem.

[SafeDusk]

I like to think of subagents as “OS threads” with its own context and designed to hand off task to.

A good use case is Cognition/Windsurf swe-grep which has its own model to grep code fast.

I was inspired by it but too bad it’s closed for now, so I’m taking a stab with an open version https://github.com/aperoc/op-grep.