Yeah, after reading this I was thinking, "how is this different from agents using a combination of tools, resources, and prompts?" They do surprising things sometimes but it's not particularly novel of Claude Code.
i see it as skills being logical grouping of a set of prompts, which achieve a goal. Like my optimize-critical-path skill.
It's more than a single prompt, but less than an entire agent. I find skills to be the tools you use on the fly. Like how I might have a wrench,screw-driver, hammer in my tool box.
tools vs skills is all about context efficiency from what I see. and yes, this isn't novel of claude. but they are the first to offer this abstraction.
My point is that Skills are not the first to do this. Well written MCPs are dynamic workflow engines. Skills are like a more user focused and slimmed down version of MCPs.
It'd be interesting to see a comparison of a well written MCP compared to a skill in terms of task competency.
Now that you mention it, i can see a future where claude may offer a "skills" feature and codex offers a "talent" feature. where they are essentially the same things, but specific to that vendor.
reminds me how each cloud has the same offerings but different products.
My big gripe with skills is getting claude webapp and claude code to get them to invoke them in the right situations (often unexpected situations) without explicitly telling it directly to use skill x + skill y.
Ideally I would build a bunch of atomic skills that combine well and claude just uses them naturally when the situation arises.
Edit: I realise it might look kind of weird I posted this link in 2 comments on this thread - disclaimer I am not the author of that random blog post, just sharing what I found!
Regardless of title, it’s a good little reminder that I hadn’t thought of - skills can use skills. This makes sense - a skill is just a pre-loaded context Claude instance, so why not? But I also tend to think of one skill at a time. Thanks for the write up.
You can make a router skill that describes how to use the other skills together. I'm experimenting with this now but my core problem is still How to Make Claude Code Skills Activate Reliably.
During testing today I asked a task I knew should have activated a skill and claude just did it without the skill instead.
(I've rephrased the sentence by removing "just" -- the novel thought here is that the agent's use of a skill can automatically trigger another skill, which is somewhat emergent.)
The activation reliability issue kingkongjaffa mentions is the real challenge here. It's the same problem you hit building any pattern-based system - getting it to recognise when a pattern applies vs when it should improvise.
I've been building transaction categorisation tools and the parallel is striking. You can have perfect pattern logic, but the model still needs to correctly identify "this situation matches pattern X" first. Sometimes it just... doesn't, even when it clearly should.
The router skill idea is interesting. Feels like pushing the meta-matching problem up a level though - now you need the router to activate reliably. Turtles all the way down.
I wonder how complex we can make skills if claude code was able to read them dynamically. I am envisioning one session generates the skill.md while other session works on it and then I envision they both editing each other's skill.md. just a little dream I have, sorry for yapping.
That's what I have been doing as I'm building these skills out. There is a really fun testing/tdd loop that runs these skills through multiple prompts with baselines and tests it all out.
Getting a 404 Not Found for this post - is the blog down?
I was really curious to read it given the comments + full disclosure my co-founder recently wrote about a similar topic ("To Tool or Not to Tool") https://blog.codeyam.com/p/to-tool-or-not-to-tool .
I wanted to see how this is similar or different with the focus on Claude Code + Skills in a more literal sense vs. tools in a more abstract sense.
reply