1 Comment
User's avatar
Fabrice Talbot's avatar

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.