Live data from Hacker News

Claude Skills are awesome, maybe a bigger deal than MCP

simonwillison.net

211–220 of 383 posts

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#211
post #170

Earlier quoted context omitted.

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 to…

How is it different from subagents?

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.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#212
post #187

Earlier quoted context omitted.

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.

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 "ca…

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.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#213

Earlier quoted context omitted.

> MCP, Apps, Skills, Gems - all this stuff seems to be tackling the wrong problem My fairly negative take on all of this has been that we’re writing more docs, creating more apis and generally doing a lot of work to make the AI work, that would’ve yielded the same results if we did it for people in the first place. Half my life has been spent trying to debug issues in complex systems that do not have those available.

I am also struck by how much these kinds of context documents resemble normal developer documentation, but actually good. What was the barrier to creating these documents before?

They're much more useful when an LLM stands between them and users - because LLMs can (re)process much more of them, and much faster, than any human could ever hope to.

One way (and one use case) of looking at it is, LLM agents with access ("tools") to semantic search[0] are basically a search engine that understands the text it's searching through... and then can do a hundred different things with it. I found myself writing better notes at work for this very reason - because I know the LLM can see them, and can do anything from surfacing obscure insights from the past, to writing code to solve an issue I documented earlier.

It makes notes no longer be write-only.

--

[0] - Which, incidentally, is itself enabled by LLM embeddings.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#214

Earlier quoted context omitted.

> MCP, Apps, Skills, Gems - all this stuff seems to be tackling the wrong problem My fairly negative take on all of this has been that we’re writing more docs, creating more apis and generally doing a lot of work to make the AI work, that would’ve yielded the same results if we did it for people in the first place. Half my life has been spent trying to debug issues in complex systems that do not have those available.

What if the great boon of AI is to get us to do all the thinking and writing we should have been doing all along? What if the next group of technologists to end up on top are... the technical writers ? Haha, just kidding you tech bros, AI's still for you, and this time you'll get to shove the nerds into a locker for sure. ;-)

This is actually my theory of the future. Basically, the ability to multiply your own effectiveness is now directly dependent on your ability to express ideas in simple plain English very quickly and precisely.

I’m attracted to this theory in part because it applies to me. I’m a below average coder (mostly due to inability to focus on it full time) and I’m exceptionally good at clear technical writing, having made a living off it much of my life.

The present moment has been utterly life changing.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#215
Skills again seem more like making MCPs more accessible for everyday users. It will again need to see evolution - things that are missing - containers for skills (you will need beyond a folder for sharing a toolchain with skills) - the orchestration and picking up of the skill is left to the LLM (the synthesis is done via the context shared in the skill - this feels a very sub-optimal pattern at the moment - low control)

Few others like versioning, access control for tools which are missing.

Real world skills come not just from practice but are opionated workflows built with specific toolchains too.

IMO, this is half-ass engineered at the moment

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#216

Earlier quoted context omitted.

MCP seems valuable in that it teaches the llm about oauth. So you can do server based tool calls. Before that you had to install each cli you wanted and it would invariably be doing some auth thing under the covers. Took calling was certainly the big llm advantage but “hey tools should probably auth correctly” is pretty valuable.

I would argue MCP is technically a "tool calling" approach, albeit more specific.

It is, it's just a very specific approach, and it's simultaneously a bit underspecified and a bit too prescriptive.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#217

We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…

onboarding devs won’t risk looking dumb to complain about the bad docs, the authors already have a mental model, and writing them out fully helped others at expense of job security.

When doling bad docs to a stupid robot, you only have yourself to blame for the bad docs. So I think it’s #2 + #3. The big change is replacability going from bad to desirable (replace yourself with agents before you are replaced with a cheaper seat)

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#218

I've been able to build the equivalent of skills with a few markdown files. I need to remind my agent every so often to use a skill but usually once per session at most. I don't get what's so special about Claude doing this?

It feels like it's taking a solved problem and formalizing it, with a bit of automation. I've used MCPs that were just fancy document search, and this should replace those.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#219

We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…

Probably all the same reasons tech debt exists in the first place: business pressure, poor design, lack of resources. It used to be expensive to keep good documentation up to date as the code changes.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#220
post #108

Earlier quoted context omitted.

tbh wolfram alpha was the craziest thing ever. haven't done much research on how this was implemented back in the day but to achieve what they did for such complex mathematical problems without AI was kind of nuts

Would really like something selfhosted that does the basic Wolfram Alpha math things. Doesn't need the craziest math capability but standard symbolic math stuff like expression reduction, differentiation and integration of common equations, plotting, unit wrangling. All with an easy to use text interface that doesn't require learning.

Personal faves:

- Mathematica

- Maple

- MathStudio (mobile)

- Ti-89 calculator (high school favorite)

Others:

- SageMath

- GNU Octave

- SymPy

- Maxima

- Mathcad

Post reply on HN