Looks interesting! I know it's easy to setup and test it but I'm on mobile current so I think it'd be great if there was full-interaction example to better understand how it works.
I'm not familiar with Skills, but looking at the repo I find the amount of decorative code/text as overkill for what amounts to just the following prompt in a bash script (yikes) executing after a commit is run:
{"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":"[learning-opportunities-auto] The user just committed code. Per the learning-opportunities skill, consider whether this is a good moment to offer a learning exercise. If the committed work involved new files, schema changes, architectural decisions, refactors, or unfamiliar patterns, ask the user (one short sentence) if they'd like a 10-15 minute exercise. Do not start the exercise until they confirm. If they decline, note it — no more offers this session."}}
I really love the idea, I've had Claude make textbooks for me on the fly using open source textbooks and documentation. Is it possible to extend this skill to more generalized areas of learning / application? Or, is it domain specific to code?
I will never understand why someone would go through all the trouble of developing this cool idea, without bothering to link a demo or include sample output. I see this every day on HN.
So the only way I can see what this skill actually looks like is to download and run it myself? No thank you.
For those who haven't gone down this rabbit hole like me yet: skills are just structured markdown files that describe how to handle a narrow-band task.
So, if I write my API endpoints a certain way, the skill would describe that specific process. Later, an agent can "see" this skill, load it when it's relevant to current chat context, and then do whatever is instructed.
Similar to "tool calls," but instead of being a function you can call, it's just instructions for how to perform that "skill."
At least for the agent I use (Cline), you can define skills either globally or locally (project level).
This is a great idea, I've been exploring with it this morning. I've really been feeling the brain drain from using AI to much, and while this isn't the fix. I think a few exercises a day can really help.
There is an iterative kind which applies specifically to the code-writing agents. Accepting the output of your coding assistant without checking whether it is correct will cause the loss of knowledge about your codebase. Context files, such as CLAUDE.md, migration protocols, and authentication protocols, function correctly if you possess sufficient knowledge to be able to update them properly.
Sometimes I have had sessions in which I blindly accepted the code produced by the agent for two hours, but afterwards was not able to create a new context file, having forgotten how my codebase worked. Such skill debt does not appear in the diff – it becomes apparent in situations when you must guide the agent, but cannot do it.
Such is the nature of the practice proposed by this skill.
Interesting responses here. I think most are missing the point.
For me, the main lesson here is seeing and learning from how others are using skills. Yesterday I was watching a Matt Pocock class on using agents and he was also showing off skills, such as how he uses a "grill-me" skill to develop product requirement document. I am certainly not going to do exactly what he does, but I now have my own ideas about how to develop requirements and implement them.
After all, in the word of Anthropic engineers themselves, Claude is like a talented engineer, but lacks expertise. Skills are folders and files that build expertise. Another important thing I leaned from Pocock is that the longer the context (or token size), the dumber the responses tend to get. So skills are another way to present the problem to an LLM in a compact manner and get optimized response.
Claude also has behavioral traits. So if someone iteratively builds a skill, it is most likely not going to port well to another user, because each of us chat differently. This is why I hesitate to share my skill folder with my colleagues. But I will certainly demo what I built so that they can see what's possible and figure out their own workflows.
So the value is in seeing how someone else builds using Claude, and imitate in your own way. Very much like when I first learned programming, I was copying code form Kernighan and Richie's C book, but then changing up things to understand how it works and later customize the code for my purpose.
I mentioned behavioral traits for another reason- the author is a psychologist and it is really interesting to see how she interacts with Claude, which is probably very different from how programmers use Claude. Tangentially, she (and a host of other experts in the field) left Twitter long time ago. I'm going to install bsky/mastodon and follow them, because I think it's important to watch how expert non-programmers are using LLMs.
I was surprised to learn that some skills don't even describe exactly what steps to take or what to do. They just kind of give a motivational speech which I guess primes the model to output better text for a certain task.
This frontend design skill that claude uses basically just begs it to pick nice fonts and make the design coherent. No specifics about which fonts or how to make nice color schemes and layout.
recursive skill-building's the obvious move. the missing piece is outcome tracking. without knowing which skill closed which loop, "deliberate" just means "you made one." the loop closes on the data, not the demo.
26 comments
[ 6.5 ms ] story [ 140 ms ] threadI want to learn Java spring, and probably let ai help me / quiz me. I will take a look into the skills for inspiration.
Examples?
> Generation effect: Accepting generated code and decreasing generating one's own code can skip the active processing that builds understanding.
Holy truth.
So the only way I can see what this skill actually looks like is to download and run it myself? No thank you.
So, if I write my API endpoints a certain way, the skill would describe that specific process. Later, an agent can "see" this skill, load it when it's relevant to current chat context, and then do whatever is instructed.
Similar to "tool calls," but instead of being a function you can call, it's just instructions for how to perform that "skill."
At least for the agent I use (Cline), you can define skills either globally or locally (project level).
Sometimes I have had sessions in which I blindly accepted the code produced by the agent for two hours, but afterwards was not able to create a new context file, having forgotten how my codebase worked. Such skill debt does not appear in the diff – it becomes apparent in situations when you must guide the agent, but cannot do it. Such is the nature of the practice proposed by this skill.
For me, the main lesson here is seeing and learning from how others are using skills. Yesterday I was watching a Matt Pocock class on using agents and he was also showing off skills, such as how he uses a "grill-me" skill to develop product requirement document. I am certainly not going to do exactly what he does, but I now have my own ideas about how to develop requirements and implement them.
After all, in the word of Anthropic engineers themselves, Claude is like a talented engineer, but lacks expertise. Skills are folders and files that build expertise. Another important thing I leaned from Pocock is that the longer the context (or token size), the dumber the responses tend to get. So skills are another way to present the problem to an LLM in a compact manner and get optimized response.
Claude also has behavioral traits. So if someone iteratively builds a skill, it is most likely not going to port well to another user, because each of us chat differently. This is why I hesitate to share my skill folder with my colleagues. But I will certainly demo what I built so that they can see what's possible and figure out their own workflows.
So the value is in seeing how someone else builds using Claude, and imitate in your own way. Very much like when I first learned programming, I was copying code form Kernighan and Richie's C book, but then changing up things to understand how it works and later customize the code for my purpose.
I mentioned behavioral traits for another reason- the author is a psychologist and it is really interesting to see how she interacts with Claude, which is probably very different from how programmers use Claude. Tangentially, she (and a host of other experts in the field) left Twitter long time ago. I'm going to install bsky/mastodon and follow them, because I think it's important to watch how expert non-programmers are using LLMs.
https://github.com/anthropics/claude-code/blob/main/plugins/...
This frontend design skill that claude uses basically just begs it to pick nice fonts and make the design coherent. No specifics about which fonts or how to make nice color schemes and layout.