Hacker News Reader

Comment by simonw | Hacker News Reader

Just published this about skills: "Claude Skills are awesome, maybe a bigger deal than MCP"

https://simonwillison.net/2025/Oct/16/claude-skills/

Skills are cool, but to me it's more of a design pattern / prompt engineering trick than something in need of a hard spec. You can even implement it in an MCP - I've been doing it for a while: "Before doing anything, search the skills MCP and read any relevant guides."

I get this sentiment, but I think it is why it is so powerful actually. It would be like calling Docker/containers just some shell scripts for a kernel feature. It may be conceptually simple, but that doesn't mean it isn't novel and could transform things.

I highly doubt we'll be talking about MCP next year. It is a pretty bad spec but we had to start somewhere.

I agree with you, but also I want to ask if I do understand this correctly: there was a paradigm in which we were aiming for Small Language Models to perform specific types of tasks, orchestrated by the LLM. That is what I perceived the MCP architecture came to standardize.

But here, it seems more like a diamond shape of information flow: the LLM processes the big task, then prompts are customized (not via LLM) with reference to the Skills, and then the customized prompt is fed yet again to the LLM.

Is that the case?

I disagree. You wrap this up in a container / runtime spec. + package index and suddenly you’ve got an agent that can dynamically extend its capabilities based upon any skill that anybody has shared. Instead of `uv add foo` for Python packages you’ve got `skill add foo` for agent skills that the agent can run whenever they have a matching need.

Exactly! I don't think Skills is a new algorithm but it's definitely a new paradigm of organizing your prompt. Essentially, dynamic context assembling with stuff crossing user boundaries which. They even mention that they are working on skill sharing across teams in an organization. You can take this expand to global user base sharing things with each other in an agent.

Fundamentally you're getting hyped over a framework to append text to your prompt ?

that's pretty reductive. it's an interesting shift in thinking how to work with these tools.

whether there's some skillhub somewhere like there are MCP registries... you could totally see it happening.

It is exactly that. The same like slash-commands for CC: it’s just convenience.

Do you reckon Skills overlap with AGENTS.md?

VSCode recently introduced support nested AGENTS.md which albeit less formal, might overlap:

https://code.visualstudio.com/updates/v1_105#_support-for-ne...

Yeah, AGENTS.md that can point to other files for the LLM to read only if it needs them is effectively the exact same pattern as skills.

It also means that any tool that knows how to read AGENTS.md could start using skills today.

"if you need to create a PDF file first read the file in skills/pdfs/SKILL.md"

That's where my confusion is. How is this pattern similar to MCP? Can it also authenticate against 3rd party apis, similar to MCP?

If you want to call a third party API from a skill you can use instructions like this:

  To access the GitHub API, use curl 
  to make requests to api.GitHub.com
  and pass the GITHUB_API_KEY
  environment variable in the
  Authorization: Bearer header

The "everything is a prompt" thing is interesting, but do we lose some deterministic behavior of MCP plumbing and execution for when the LLM simply doesn't want to follow the 'rules' and possibly hallucinates while processing the skill prompt? How do we make it consistent?

Simon, this won't work, will it? The code execution environment can reach the internet?

It can if you are running it through Claude Code on your own machine.

The https://claude.ai environment has very limited network access - it can install packages from PyPI and NPM and clone repositories from github.com but it can't access any other domain, including api.github.com.

;-) Confirmed by trying. I'm working on an AI-frontend "documents-as-code" tool, and having this as a skill that works across all Claude surfaces would be a huge win. Unfortunately it looks like that's not gonna happen today because ^^ ...

Looks like Claude Desktop and/or Claude Code + a non-big-fat-pig MCP (aka "not GitHub's official version") will be needed.

Here's hoping that Anthropic solves "safe external access / auth from code execution tool" soon.

EDIT - add last sentence

I NOW UNDERSTAND

Finally a good replacement for MCP. MCP was a horrible idea executed even worse and they hide the complexity under a dangerous "just paste this one liner into your mcpServers config!" together with wasting tens of thousands of tokens.

Isn't this the same as Cursor Rules ?

MCP is a protocol meant for general use for clients, which Claude Skills seems more proprietary. To what extent is Skills expected to be something that other clients, such as web based clients could adopt? To some extent it would probably make sense to expose through the MCP SDK?

Context overload is definitely a problem with MCP, but its plug-and-play nature and discoverability are solid. Pasting a URL (or just using a button or other UX element) to link an MCP server presents a much lower barrier to entry than having the LLM run `cli-tool --help`, which assumes the CLI tool is already installed and the LLM has to know about it.

I think "Skill" is a subset of developer instruction, in which translates to AGENTS.md (or Claude.md). Today to add capability to an AI, all we need a good set of .md files and a AGENTS.md as the base.

when do you need to make a skill vs a project?

In Claude and ChatGPT a project is really just a custom system prompt and an optional bunch of files. Those files are both searchable via tools and get made available in the Code Interpreter container.

I see skills as something you might use inside of a project. You could have a project called "data analyst" with a bunch of skills for different aspects of that task - how to run a regression, how to export data from MySQL, etc.

They're effectively custom instructions that are unlimited in size and that don't cause performance problems by clogging up the context - since the whole point of skills is they're only read into the context when the LLM needs them.

Skills can be toggled on and off, which is good for context management, especially on larger / less frequently needed skills

Currently if a project is 5% or less capacity, it will auto-load all files, so skills also give you a way to avoid that capacity limit. For larger projects, Claude has to search files, which can be unreliable, so skills will again be useful for an explicit "always load this"

then submit it, you don't need to post here about it

i found it useful and coinstructive to post it here also.

no reason not to.

In my opinion because this is a discussion about this announcement, and it kinda feels like with not one but _two_ top-level posts, Simon is just kinda trying to hijack this conversation and turn it into a conversation about his posts. I'm not saying Simon is spamming, because there's definitely some relevance here. But I am saying Simon is attention-seeking in an unbecoming manner. Simon's posts make the homepage regularly anyway, he doesn't need to post them in other threads.

See https://news.ycombinator.com/item?id=45619537 ?

Love your work but Pretty sure you got paid to endorse them

I didn't. That would be both grossly unethical and, in the USA, illegal if I didn't disclose it.

See comment here: https://news.ycombinator.com/item?id=45624613

I'm getting accused of paid shilling a lot right now.

(If Anthropic had paid me to write this they would probably have asked me NOT to spend a section of the article pointing out flaws in their MCP specification!)

Fair enough, didn't know that it was illegal. The accusation was based on the fact that u released the same day as their release (natural to do so) and with high praise. Thx for the reply I retract my accusation.

Reply on news.ycombinator.com