Great article pointing at a topic that is totally misunderstood. I would not follow the research.
Because skills are so easy to build, people think they "understand" how to build them. This is the exact opposite.
Few things that are missing and important:
- a skill is small and autonomous; it should be able to complete the job on its own and own only one job
- a skill is more than SKILL.md; think context; is it in references/ and packaged with the skill bundle or outside? Is it for your own usage or distributed? Suddenly things get complicated...
- a skill is not a workflow; it can be embedded into a workflow but cannot replace it
- a skill needs triggers to execute (e..g "write the article draft"); this becomes messy very quickly as you add skills to your stack: 50 skills x 5 trigger keywords per skill = 250 triggers => you or your AI will run a skill by accident
- most novice don't even know that you should define trigger words... and don't know where to define them
- a skill is exposed globally when you usually want it constrained to a workspace; this is problematic too
I built 150+ skills on my own and deleted ~130 of them over the last year.
My conclusion: you can (should) run most of your workflows without skills and only keep the ones that you cannot live without; for me it is writer skill, drift capture skill (voice, workflows), content qa skill like sugarman score for copywriting applied to Linkedin or Substack.
I'm coming to a similar conclusion and have been weeding out my skills. And in some cases, I'm just moving details to a context doc or AGENT.MD, which seems to work well enough in many cases. In fact, I would say those take precedence over skills. So a lot of times when a skill goes wrong it has something to do with one of these two things.
Great article pointing at a topic that is totally misunderstood. I would not follow the research.
Because skills are so easy to build, people think they "understand" how to build them. This is the exact opposite.
Few things that are missing and important:
- a skill is small and autonomous; it should be able to complete the job on its own and own only one job
- a skill is more than SKILL.md; think context; is it in references/ and packaged with the skill bundle or outside? Is it for your own usage or distributed? Suddenly things get complicated...
- a skill is not a workflow; it can be embedded into a workflow but cannot replace it
- a skill needs triggers to execute (e..g "write the article draft"); this becomes messy very quickly as you add skills to your stack: 50 skills x 5 trigger keywords per skill = 250 triggers => you or your AI will run a skill by accident
- most novice don't even know that you should define trigger words... and don't know where to define them
- a skill is exposed globally when you usually want it constrained to a workspace; this is problematic too
I built 150+ skills on my own and deleted ~130 of them over the last year.
My conclusion: you can (should) run most of your workflows without skills and only keep the ones that you cannot live without; for me it is writer skill, drift capture skill (voice, workflows), content qa skill like sugarman score for copywriting applied to Linkedin or Substack.
I'm coming to a similar conclusion and have been weeding out my skills. And in some cases, I'm just moving details to a context doc or AGENT.MD, which seems to work well enough in many cases. In fact, I would say those take precedence over skills. So a lot of times when a skill goes wrong it has something to do with one of these two things.