If I had a nickel for every dev who has written a "productivity suite" of skills, and shared it with others as if it was a burst of innovation that everyone can benefit from (when it's really extremely specific to that dev and their workflow) ... well I'd have a lot of nickels.
It turns out productivity skill sets for Claude are a bit like opinions and assholes (everyone has one, and ...)
I mean, just to give you an idea of how common this is, my CEO made a suite like this ... although he had the self-awareness to realize what he made was very specific to him.
Agreed. Skills are hardly transferrable unless you are just focusing on globally applicable things like syntax, structure, etc. The most useful skills are things that are not well known and project/ organization specific. The "tribal knowledge" aspect of coding.
To each his own, but it seems like all this could be one moderately-sized AGENTS.md/CLAUDE.md, and much of it doesn’t need to be detailed at all.
For example, you could just put “always follow TDD” in there. If you want to be very complete you could add “first write tests and make sure they’re red before continuing to code. Make sure tests are green on completion”.
Skills are useful for calling specific scripts, adding specific data (like branding info) or detailing truly unusual, bespoke workflows (like the use of cutting-edge machine learning algorithms you’ve developed yourself or something). If you’re detailing something like TDD, you’re probably hampering the model by giving it a definition that is less accurate than the one it has learned in training.
In my experience, it’s just easier to build it as you go. Every time the bot stumbles, make sure it’s a teachable moment and the lesson is learned. Every once in a while, do some house cleaning.
Trying to start with these preset banks of instructions just never seems like it works out in the long run. It’s also unsettling catching it behaving in an odd way, and realizing that it was taking a cue from instructions you never wrote, but imported from elsewhere. Like playing a game of pretend with someone else’s rules.
If I had a nickel for every dev who has written a "productivity suite" of skills, and shared it with others as if it was a burst of innovation that everyone can benefit from (when it's really extremely specific to that dev and their workflow) ... well I'd have a lot of nickels.
It turns out productivity skill sets for Claude are a bit like opinions and assholes (everyone has one, and ...)
I mean, just to give you an idea of how common this is, my CEO made a suite like this ... although he had the self-awareness to realize what he made was very specific to him.
Agreed. Skills are hardly transferrable unless you are just focusing on globally applicable things like syntax, structure, etc. The most useful skills are things that are not well known and project/ organization specific. The "tribal knowledge" aspect of coding.
You are entirely correct. Matt Pocock is still a nice guy with reasonable opinions and shares a lot with us.
I've personally learned from reading his skills.
I have one I started back in October last year and been improving since. Also a python docs cli to manage agent state in markdown locally.
I love reading them to see if theres a way mine could be improved, what topics they hit on, how they approach different problems.
https://github.com/ArtRichards/agent-playbook-suite
https://artrichards.github.io/agent-playbook-suite/blog/
https://github.com/ArtRichards/docs-cli
To each his own, but it seems like all this could be one moderately-sized AGENTS.md/CLAUDE.md, and much of it doesn’t need to be detailed at all.
For example, you could just put “always follow TDD” in there. If you want to be very complete you could add “first write tests and make sure they’re red before continuing to code. Make sure tests are green on completion”.
Skills are useful for calling specific scripts, adding specific data (like branding info) or detailing truly unusual, bespoke workflows (like the use of cutting-edge machine learning algorithms you’ve developed yourself or something). If you’re detailing something like TDD, you’re probably hampering the model by giving it a definition that is less accurate than the one it has learned in training.
The second skill has this before/after example:
> BEFORE: "There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)"
> AFTER: "There's a problem with the materialization cascade"
It claims the second is easier reading. Is it just me, or does anyone else prefer the first?
In my experience, it’s just easier to build it as you go. Every time the bot stumbles, make sure it’s a teachable moment and the lesson is learned. Every once in a while, do some house cleaning.
Trying to start with these preset banks of instructions just never seems like it works out in the long run. It’s also unsettling catching it behaving in an odd way, and realizing that it was taking a cue from instructions you never wrote, but imported from elsewhere. Like playing a game of pretend with someone else’s rules.
Christ, this is exhausting.