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.
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.
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 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.
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!
I didn't see any emergent behavior, just combining of skills (which I'll admit looks useful). Calling this emergent is click bait.
Yeah, it’s literally talked about and documented by the vendor as an intended characteristic of the design.
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.
> 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.
Ahhhh. I see now.
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.
Codex added skills support recently. It appears to work exactly the same as Claude Code.
ohhh! I'm gonna have to try that out. Thankfully everybody is still playing nice hahah!
you're not wrong. my goal was for more playful.
Well, it's a little odd, because up until a couple months ago we had to have everything we wanted it to be able to do in context anyway.
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.
turtle, turtle...
It's really going to be interesting to see how this tech evolves.
A skill that creates other skills can be very useful as well.
E.g. you could have:
- a set of skills to use design patterns of a library
- a skill to add to this skill-set -- either when prompted by user or autonomously via a stop-hook
E.g. I set up this combination for design patterns for the Langroid[1] LLM-Agent framework:
https://github.com/pchalasani/claude-code-tools/tree/main/pl...
[1] https://github.com/langroid/langroid
Having too many skills can be a mistake. Getting too meta can be a mistake. I wrote about it on my blog too.
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.
Skills are just prompts the agent can choose to load.
That's it
If you come across any other skills that could be fun to combine, lmk!
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.
This might help: https://scottspence.com/posts/how-to-make-claude-code-skills...
Post has moved to https://vibeandscribe.xyz/posts/2026-01-07-emergent-behavior...
doh! I messed up. Thank you
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.
No need to be sorry! That's why I posted this.
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.
Year is wrong in the article by the way. It says 2025.
FUCKING AI HAHAHA, thank you! fixed.
No AI could code a better seahorse emoji xD
Kiss of death? I'm seeing "404 Not Found nginx/1.18.0 (Ubuntu)"
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.
1000000% agree. That's a problem I'm working on right now. I did learn about hooks, which is a way to constantly remind it. But that's too generic.
At some point I plan to do some ralph wiggum loop stuff maybe to hash out the best way for triggers to work.
I'm reading up on this right now.
Here's some prior work that might be interesting: https://scottspence.com/posts/how-to-make-claude-code-skills...
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!
404 for me
https://vibeandscribe.xyz/posts/2026-01-07-emergent-behavior...
(year fixed below)
Redirects my man, Learn em and love them