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

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

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.

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.

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?

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?

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

> the thing I most need are context-management helpers like "start a claude with this set of MCPs, then that set, and so on".

Isn’t that sub agents?

The developer page uses a better example, a PDF processing skill: https://github.com/anthropics/skills/tree/main/document-skil...

I've been emulating this in claude code by manually @tagging markdown files containing guides for common tasks in our repository. Nice to see that this step is now automatic as well.

You'd think so, eh ? https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

this is the best example I found

https://github.com/anthropics/skills/blob/main/document-skil...

I was dealing with 2 issues this morning getting Claude to produce a .xlsx that are covered in the doc above

Dog photo >> informing the consumer

Delegation is super cool. I can sometimes end up having too much Linear issue context coming in. IE frequently I want a Linear issue description and last comment retrieved. Linear MCP grabs all comments which pollutes the context and fills it up too much.

Claude Skills just seem to be the same as MCP prompts: https://modelcontextprotocol.io/specification/2025-06-18/ser...

I don't really see why they had to create a different concept. Maybe makes sense "marketing-wise" for their chat UI, but in Claude Code? Especially when CLAUDE.md is a thing?

I think those three concepts complement each other quite neatly.

MCPs can wrap APIs to make them usable by an LLM agent.

Skills offer a context-efficient way to make extra instructions available to the agent only when it needs them. Some of those instructions might involve telling it how best to use the MCPs.

Sub-agents are another context management pattern, this time allowing a parent agent to send a sub-agent off on a mission - optimally involving both skills and MCPs - while saving on tokens in that parent agent.

"So I fired up a fresh Claude instance (fun fact: Code Interpreter also works in the Claude iOS app now, which it didn't when they first launched) and prompted:

Create a zip file of everything in your /mnt/skills folder"

It's a fun, terrifying world that this kind of "hack" to exfiltrate data is possible! I hope it does not have full filesystem/bin access, lol. Can it SSH?...

Woah, Jesse's blog has really come alive lately. Thanks for highlighting this post.

> Contrast with the way a human learns skills - as we gain experience with a skill, we get better at understanding when it's the right tool for the job.

Which is precisely why Richard Sutton doesn't think LLMs will evolve to AGI[0]. LLMs are based on mimicry, not experience, so it's more likely (according to Sutton) that AGI will be based on some form of RL (reinforcement learning) and not neural networks (LLMs).

More specifically, LLMs don't have goals and consequences of actions, which is the foundation for intelligence. So, to your point, the idea of a "skill" is more akin to a reference manual, than it is a skill building exercise that can be applied to developing an instrument, task, solution, etc.

[0] https://www.youtube.com/watch?v=21EYKqUsPfg

IMO this is a context window issue. Humans are pretty good are memorizing super broad context without great accuracy. Sometimes our "recall" function doesn't even work right ("How do you say 'blah' in German again?"), so the more you specialize (say, 10k hours / mastery), the better you are at recalling a specific set of "skills", but perhaps not other skills.

On the other hand, LLMs have a programatic context with consistent storage and the ability to have perfect recall, they just don't always generate the expected output in practice as the cost to go through ALL context is prohibitive in terms of power and time.

Skills.. or really just context insertion is simply a way to prioritize their output generation manually. LLM "thinking mode" is the same, for what it's worth - it really is just reprioritizing context - so not "starting from scratch" per se.

When you start thinking about it that way, it makes sense - and it helps using these tools more effectively too.

Would this requirement to start from ground zero in current LLMs be an artefact of the requirement to have a "multi-tenant" infrastructure?

Of course OpenAI and Anthropic want to be able to reuse the same servers/memory for multiple users, otherwise it would be too expensive.

Could we have "personal" single-tenant setups? Where the LLM incorporates every previous conversation?

This is the crux of knowledge/tool enrichment in LLMs. The idea that we can have knowledge bases and LLMs will know WHEN to use them is a bit of a pipe dream right now.

Skills are literally technical documentation for your project it seems. So now we can finally argue for time to write doc, just name it "AI enhancing skill definitions"

> starting from ground zero

You probably mean "starting from square one" but yeah I get you

Most of the experience is general information not specific to project/discussion. LLM starts with all that knowledge. Next it needs a memory and lookup system for project specific information. Lookup in humans is amazingly fast, but even with a slow lookup, LLMs can refer to it in near real-time.

Excellent point, put simply building those preferences and lessons would demand a layer of latent memory, personal models, maybe now is a good time to revisit this idea...

The blurbs can be improved if they aren't effective. You can also invoke skills directly.

The description is equivalent to your short term memory.

The skill is like your long term memory which is retrieved if needed.

These should both be considered as part of the AI agent. Not external things.

Humans dont need a skill to know that they need a skill

LLMs are a probability based calculation, so it will always skim to some degree, and always guess to some degree, and often pick the best choice available to it even though it might not be the best.

For folks who this seems elusive for, it's worth learning how the internals actually work, helps a great deal in how to structure things in general, and then over time as the parent comment said, specifically for individual cases.

IMHO, don't, don't keep up. Just like "best practices in prompt engineering", these are just temporary workaround for current limitations, and they're bound to disappear quickly. Unless you really need the extra performance right now, just wait until models get you this performance out of the box instead of investing into learning something that'll be obsolete in months.

Well, have some understanding: the good folks need to produce something, since their main product is not delivering the much yearned for era of joblessness yet. It's not for you, it's signalling their investors - see, we're not burning your cash paying a bunch of PhDs to tweak the model weights without visible results. We are actually building products. With a huge and willing A/B testing base.

Agree — it's a big downside as a user to have more and more of these provider-specific features. More to learn, more to configure, more to get locked into.

Of course this is why the model providers keep shipping new ones; without them their product is a commodity.

Features will be added until morale improves

Agreed, but I think it's actually simple.

Plugins include: * Commands * MCPs * Subagents * Now, Skills

Marketplaces aggregate plugins.

All these things are designed to create lock in for companies. They don’t really fundamentally add to the functionality of LLMs. Devs should focus on working directly with model generate apis and not using all the decoration.

All of it is ultimately managing the context for a model. Just different methods

Yep. Now I need an AI to help me use AI

If I were to say "Claude Skills can be seen as a particular productization of a system prompt" would I be wrong?

From a technical perspective, it seems like unnecessary complexity in a way. Of course I recognize there are lot of product decisions that seem to layer on 'unnecessary' abstractions but still have utility.

In terms of connecting with customers, it seems sensible, under the assumption that Anthropic is triaging customer feedback well and leading to where they want to go (even if they don't know it yet).

Update: a sibling comment just wrote something quite similar: "All these things are designed to create lock in for companies. They don’t really fundamentally add to the functionality of LLMs." I think I agree.

Thats the start of the singularity. The changes will keep accelerating and less and less people will be able to keep up until only the AIs themselves know how to use.

You forgot mcp-everything!

Yes, it's a mess, and there will be a lot of churn, you're not wrong, but there are foundational concepts underneath it all that you can learn and then it's easy to fit insert-new-feature into your mental model. (Or you can just ignore the new features, and roll your own tools. Some people here do that with a lot of success.)

The foundational mental model to get the hang of is really just:

* An LLM

* ...called in a loop

* ...maintaining a history of stuff it's done in the session (the "context")

* ...with access to tool calls to do things. Like, read files, write files, call bash, etc.

Some people call this "the agentic loop." Call it what you want, you can write it in 100 lines of Python. I encourage every programmer I talk to who is remotely curious about LLMs to try that. It is a lightbulb moment.

Once you've written your own basic agent, if a new tool comes along, you can easily demystify it by thinking about how you'd implement it yourself. For example, Claude Skills are really just:

1) Skills are just a bunch of files with instructions for the LLM in them.

2) Search for the available "skills" on startup and put all the short descriptions into the context so the LLM knows about them.

3) Also tell the LLM how to "use" a skill. Claude just uses the `bash` tool for that.

4) When Claude wants to use a skill, it uses the "call bash" tool to read in the skill files, then does the thing described in them.

and that's more or less it, glossing over a lot of things that are important but not foundational like ensuring granular tool permissions, etc.

Yep, the ecosystem is well on its way to collapsing under its own weight.

You have to remember, every system or platform has a total complexity budget that effectively sits at the limit of what a broad spectrum of people can effectively incorporate into their day to day working memory. How it gets spent is absolutely crucial. When a platform vendor adds a new piece of complexity, it comes from the same budget that could have been devoted to things built on the platform. But unlike things built on the platform, it's there whether developers like it and use it or not. It's common these days that providers binge on ecosystem complexity because they think it's building differentiation, when in fact it's building huge barriers to the exact audience they need to attract to scale up their customer base, and subtracting from the value of what can actually be built on their platform.

Here you have a highly overlapping duplicative concept that's taking a solid chunk of new complexity budget but not really adding a lot of new capability in return. I am sure the people who designed it think they are reducing complexity by adding a "simple" new feature that does what people would otherwise have to learn themselves. It's far more likely they are at break even for how many people they deter vs attract from using their platform by doing this.

There's so much white space - this is the cost of a brand new technology. Similar issues with figuring out what cloud tools to use, or what python libraries are most relevant.

This is also why not everyone is an early adopter. There are mental costs involved in staying on top of everything.

There are several useful ways of engineering the context used by LLMs for different use cases.

MCP allows anybody to extend their own LLM application's context and capabilities using pre-built *third party* tools.

Agent Skills allows you to let the LLM enrich and narrow down it's own context based on the nature of the task it's doing.

I have been using a home grown version of Agent Skills for months now with Claude in VSCode, using skill files and extra tools in folders for the LLM to use. Once you have enough experience writing code with LLMs, you will realize this is a natural direction to take for engineering the context of LLMs. Very helpful in pruning unnecessary parts from "general instruction files" when working on specific tasks - all orchestrated by the LLM itself. And external tools for specific tasks (such as finding out which cell in a jupyter notebook contains the code that the LLM is trying to edit, for example) make LLMs a lot more accurate and efficient, efficient because they are not burning through precious tokens to do the same and accurate because the tools are not stochastic.

With Claude Skills now I don't need to maintain my home grown contraption. This is a welcome addition!

Metastasizing is such an excellent way to describe this phenomenon. They grow on top of each other.

i’m letting the smarter folks figure all this out and just picking the tools i like every now and then. i like just using claude code with vscode and still doing some things manually

Hopefully there’s a similar “don’t make me think” mantra that comes to AI product design.

I like the trend where the agent decides what models, tooling and thought process to use. That seems to me far more powerful than asking users to create solutions for each discreet problem space.

That is why a minimal framework[1] that allows me to understand the core immutable loop, but to quickly experiment with all these imperative concepts is invaluable.

I was able to try Beads[1] quickly with my framework and decided I like it enough to keep it. If I don't like it, just drop it, they're composable.

[0]: https://github.com/aperoc/toolkami.git [1]: https://github.com/steveyegge/beads

On the other hand, this complexity represents a new niche that, for a while at least, will present job and business opportunities.

The cool part is that none of any of this is actually that big or difficult. You can master it on-demand, or build your own substitutes if necessary.

Yeah, if you chase buzzword compliance and try to learn all these things outside of a particular use case you're going to burn out and have a bad time. So... don't?

I found that the way that Claude now handle tools on my sistema simplifies stuff, with its cli usage, I find the Claude skills model better than mcp

These companies are also biased towards solutions that will more-or-less trap you in a heavily agent-based workflow.

I’m surprised/disappointed that I haven’t seen any papers out of the programming languages community about how to integrate agentic coding with compilers/type system features/etc. They really need to step up, otherwise there’s going to be a lot of unnecessary CO2 produced by tools like this.

AI tools can help you with the churn.

AI will help you solve problems you wouldn't have without AI.

Not to mention GANs, RAGs, context decoupling, prompt matrices, NAGGLs, first-class keywords, reverse token interrupts, agentic singletons, parallel context bridges…

… jk… I’ll bet at least one person was like “ah, damnit, what did I miss…” for a second.

It feels like every week these companies release some new product that feels very similar to what they released a week before. Can the employees at Anthropic even tell themselves what the difference is?

Right.

I focus on building projects delivering some specific business value and pick the tools that gets me there.

There is zero value in spending cycles by engaging in new tools hype.

It's fine, just use an AI to organise it all. Soon enough, nobody will need to know anything.

For Cursor: cursorrules, mdc rules, user rules, team rules.

Just wait until I can pull in just the concepts I want with "GPT Package Manager." I can simply call `gptpm add skills` and the LLM package manager will add the Skills package to my GPT. What could go wrong?

Just need to add some use cases

As usual, stick with the basic 20% which give 80% of the value.

All of these things seem unnecessary. You can just ask the general prompt any of these things. I don’t really understand what exactly an agent adds on since it feel like the only thing about an agent is a restricted output.

The same thing will happen: skilled people will do one thing well. I've zero interest in anything but Claude code in a dev container and, while mindful of the lethal trifecta, will give Claude as much access to a local dev environment and it's associated tooling as I would give to a junior developer.

Except in reality it's ALL marketing terms for 2 things: additional prompt sections, and APIs.

Langchain was the original sin of thin framework bullshit

You can just ask an LLM to set it up for you. Slop in, slop out.

Also the post does not contain a single word how it relates to the very similar agents in claude code. Capabilities, connectors, tasks, apps, custom-gpts, ... the space needs some serious consolidation and standardization!

I noticed the general tendency for overlap also when trying to update claude since 3+ methods conflicted with each other (brew, curl, npm, bun, vscode).

Might this be the handwriting of AI? ;)

My agent has handlebars system prompts that you can pass variables at orchestration time. You can cascade imports and such, it's really quite powerful; a few variables can result in radically different system prompt.

LLMs reward developers who can write. Maybe that's one of the reasons so many developers are pushing back against them!

>and if you’re training an agent for this specific task anyway, you’re effectively locking yourself to that specific LLM in perpetuity rather than a replaceable or promotable worker.

That's ONE of the long games that are currently played, and is arguably their fallback strategy: The equivalent of vendor lock-in but for LLM providers.

I always find it hilarious and painfully ironic that Anthropic can't even keep Claude Code's docs up to date. I don't know how much to read into it, but it is a modern marvel of process failure.

The team is obviously doing a lot of cool things very rapidly, so I don't want to be too negative, but ... please just ask Claude to review your own docs before you merge a change.

When decent docs (and various other kinds of pro-developer infrastructure listed by simonw here https://simonwillison.net/2025/Oct/7/vibe-engineering/) are required for LLMs to work well, it's a very tangible incentive to do them better and ironically makes for an easier sell to management.

Just went to the comments searching for a comment like yours and I'm surprised it seems to be the only one calling this out. My take on this is also that "Skills" is just detailed documentation, which like you correctly point out, basically never exist for any project. Maybe LLM skills will be the thing that finally makes us all write detailed documentation but I kind of doubt it.

You can achieve exactly that with a Skill. Call it "refactoring" and drop in a few paragraphs and explanations of how to use a tool like ast-grep.

My team and I have done a lot of research on this. In essence, what’s missing is MCP-type access to the language servers. There’s a couple of people doing this but nobody’s really building on top of this because the current janky way works, it’s a hard problem, and it’s not easily monetizable. But yes, it’s definitely the correct thing that needs to happen at some point. Unlikely to get popular until coding agents natively support it.

“Skills are a simple concept with a correspondingly simple format.”

From the Anthropic Engineering blog.

I think Skills will be useful in helping regular AI users and non-technical people fall into better patterns.

Many power users of AI were already doing the things it encourages.

What’s next, capabilities? Talents? Hypothalamus.md?

How this reads to me is that a skill is "just" a bundle of prompts, scripts, and files that can be read into context as a unit.

Having a sub-agent "execute" a skill makes a lot of sense from a context management, perspective, but I think the way to think about it is that a sub-agent is an "execution-level" construct, whereas a skill is a "data-level" construct.

This is definitely a problem. Skills require a very strong model - one with a longer context (32,000 tokens minimum at a guess) that can reliably drive Unix CLI tools over a multiple step conversation.

I haven't yet run a local model that feels strong enough at these things for skills to make sense. Really I think the unlock for skills was o3/Claude 4/GPT-5 - prior to those the models weren't capable enough for something like skills to work well.

That said, the rate of improvement of local models has been impressive over the past 18 months. It's possible we have a 70B local model that's capable enough to run skills now and I've not yet used it with the right harness.

OpenAI and Anthropic's real moat is hardware. For local LLMs, context length and hardware performance are the limiting factors. Qwen3 4B with a 32,768 context window is great. Until it begins filling up and performance drops quickly.

I use local models when possible. MCPs work well, but their large context injection makes switching to an online provider the no-brainer.

If so it would be most welcome since LLMs doesn't always consistently follow the folder full of MD files to the same depth and consistency.

They already have the Plugin Marketplace [1]. It's all too much of a fast moving target for something as rigid as a package manager I think. Open source projects for now will be limited to Awesome-* collections [2]

[1] https://docs.claude.com/en/docs/claude-code/plugin-marketpla...

[2] https://github.com/hesreallyhim/awesome-claude-code

It's the fact that a collection of files are tied to a specific task or action. Prompts are only injected context, whereas files can be more selectively loaded into context.

What they're trying to do here is translate MCP servers to something more broadly useable by the population. They cannot differentiate themselves with model training anymore, so they have been focusing more and more on tooling development to grow revenue.

That’s pretty much all it is. If you look at the docs it even uses a bash script to read the skill markdown files into the context.

I think the big difference is that now you can include scripts in these skills that can be executed as part of the skill, in a VM on their servers.

Download the godot docs and tell the skill to use them. It won’t be able to fit the entire docs in the context but that’s not the point. Depending on the task it will search for what it needs

I think skills and subagents are entirely complementary to each other.

A subagent can use a skill.

A skill can encourage the agent to run a subagent.

These are good points and I generally agree with you.

My guess is that, as I understand it, Anthropic’s belief is that subagents are usually not the proper tool for most tasks. In their guides and videos about proper use of subagents, they seem to really try to steer you toward “workflows” rather than subagents.

Maybe it’s time they rethink the overall strategy so that each new concept doesn’t have to be its own distinct feature (skills, plugins, marketplaces, subagents, etc).

https://www.anthropic.com/engineering/building-effective-age...

I wonder how much this affects the model's performance. I imagine Anthropic trains its models to use a generic set of tools, but they can also lean on their specific tool definitions to save the agent from having to guess which tool for what.

Thanks for sharing goose.

This phase of LLM product development feels a bit like the Tower of Babel days with Cloud services before wrapper tools became popular and more standardization happened.

One difference I see is that with tool calls the LLM doesn’t see the actual code. It delegates the task to the LLM. With scripts in an agent, I think the agent can see the code being run and can decide to run something different. I may be wrong about this. The documentation says that assets aren’t read into context. It doesn’t say the same about scripts, which is what makes me think the LLM can read them.

Cheaper, not free. Also, no training to learn a new skill.

Building a new one that works well is a project, but then it will scale up as much as you like.

This is bringing some of the advantages of software development to office tasks, but you give up some things like reliable, deterministic results.

It helps that you can have the "free" labor document the processes and build the plan.

If you want to generate images, use Midjourney or whatever. It’s almost like you’ve deliberately missed the point of the feature.

It's interesting (to me) visualizing all of these techniques as efforts to replicate A* pathfinding through the model's vector space "maze" to find the desired outcome. The potential to "one shot" any request is plausible with the right context.

Yeah my first thought was, oh it sounds like a bunch of CLAUDE.md's under the surface :P

it also may point out that the solution for context rot may not be coming in the foreseeable future

If so, it would be a better way than encapsulating functionality in markdown.

I have been using claude code to create some and organize them but they can have diminishing return.

Yes and fantastically executed, consistently through all their products and website - desktop, command line, third parties and more.

I agree 100%, except for the logo, which persistently looks like something they... probably did not intend.

We also have the same issues with our fellow humans. LLMs do not replace the need for imperative programs that reliably execute well-defined steps. Turn it inside out. Use the LLM to write the imperative program to execute the workflow. Where necessary, insert the LLM into the workflow to perform the task(s) that can't be done imperatively.

The Tao of Physics itself explains and clarifies why IIH fundamentally works along with many other things.

We could also go as far as this being racial, religious or political biggotry hard codes into claude. Look at the responses then dive into the realities of Yoga, Qi Gong and Kabbalah and what it takes to get results (ie. Personal property exercise).

This extrapolated across industries, children's minds and the future is very serious.

Alexa skills are 3rd party add-ons/plugins. Want to control your hue lights? add the phillips hue skill. I think claude skills in an alexa world would be like having to seed alexa with a bunch of context for it to remember how to turn my lights on and off or it will randomly attempt a bunch of incorrect ways of doing it until it gets lucky.

And how many of those Alexa Skills are still being updated...

This is where waiting for this stuff to stablize/standardize, and then writing a "skill" based on an actual RFC or standard protocol makes more sense, IMO. I've been burned too many times building vendor-locked chatbot extensions.

Seems to be a bit more than that.

I'm super confused as well. This seems like exactly that, just some default prompt injections to chose from. I guess I kinda understand them in the context of their claude chat UI product.

By I don't understand why it's a thing in Claude Code tho when we already have Claude.md? Could also just point to any .md file in the prompt as preamble but not even needed. https://www.anthropic.com/engineering/claude-code-best-pract...

That concept is also already perfectly specd in the MCP standard right? (Although not super used I think?) https://modelcontextprotocol.io/specification/2025-06-18/ser...

Plus executable.xode snippets. I think their actual source code doesn't use context. But feels like function calling packaged.

Right, that's my interpretation as well.

"AI" companies have reached the end of the road when it comes to throwing more data and compute at the problem. The only way now for charts to go up and to the right is to deliver value-added services.

And, to be fair, there's a potentially long and profitable road by doing good engineering work that was needed anyways.

But it should be obvious to anyone within this bubble that this is not the road to "superintelligence" or "AGI". I hope that the hype and false advertising stops soon, so that we can focus on practical applications of this technology, which are numerous.

Anthropic is making more money from enterprise while ChatGpt's target market is the consumer.

Anthropic talks about ‘progressive disclosure’.

If you have a large number of skills, you could group them into a smaller number of skills each with subskills. That way not all the (sub)skill descriptions need to be loaded into context.

For example, instead of having a ‘PDF editing’ skill, you can have a ‘file editing’ skill that, when loaded into context, tells the LLM what type of files it can operate on. And then the LLM can ask for the info about how to do stuff with PDF files.

I know I'm replying to a shitpost. But I had a realisation, and I'm probably not the only one.

If you can manage to keep structuring slightly intelligent tools so that they compound, seems like AGI is achievable.

That's why the thing everyone is after right now is new ways to make those slight intelligences keep compounding.

Just like repeated multiplication of 1.001 grows indefinitely.

Subagents have their own context. Skills do not.

Skills might be used by Agents.

Skills can merge together like lego.

Agents might be more separated.

Looks like they do:

> You can also manually install skills by adding them to ~/.claude/skills.

I've had this experience too. I like doing the work. Claude is good and I do find it useful for brainstorming and some other things, but... I still like doing the work.

More like they can better react to user input within their context window. With older models, the value of that additional user input would have been much more limited.

This is just a formalization of an existing pattern many people were already using.

Putting a list of short blurbs pointing Claude Code at a set of extra, longer sets of CLAUDE.md style information was being used to prevent auto loading that context until it was needed.

Instead of assuming this is just change for the sake of change, it’s actually a nice way to support a usage pattern that many of us found works well already

12 months ago we didn't have Claude Code or Codex CLI - in fact the whole category of "coding agents" was very thin.

The only "reasoning" model was the o1 preview.

We didn't have MCP, but that wasn't a big deal because the models were mostly pretty weak at tool calling anyway.

The DeepSeek moment hadn't happened yet - the best available open weights models were from Mistral and Llama and were nowhere close to the frontier hosted models.

The LLM landscape feels radically different to me now compared to October last year.

I wrote a thing about that here: https://simonwillison.net/2025/Oct/16/claude-skills/#skills-...

It’s much more focused on devs I feel like. Less fluff

Thanks, we'll put that link in the toptext as well