Excellent reflection on SKILLs and their limitations!
You're one of the first one on Substack who clearly stated the challenge of skills.
I came to the same conclusion: the skill or as I call it "job to be done" needs to be exposed in the instructions file. The simplest way in Claude Cowork and ChatGPT work is to declare it in your project's AGENTS.md or CLAUDE.md. The same instructions will do. I have an instruction for trigger words for safe execution, e.g. when I say "Cyborg writing [job to be done]", execute...
We differ a bit in how we execute the job to be done. I declare a workflow a bit like you and only use skills for truly repetitive, atomic, and independent tasks (e.g. writer skill). To avoid drift, you may consider a YAML file for the state and logic and proper gates to validate each step.
On the job to be done itself, my workflow map the job, e.g. one workflow for a substack article; one step is the draft, another one is the QA with ~15 gates one of them ensuring the SEO/AE is done, I am on-brand, on-terminology, on-target audience, etc.
Using prompt in a md file is semantic and AI is mot hood at following orders. You end up with drift, e.g. use Gmail connector => uses Chrome extension
YAML file next to your workflow can define a machine-readable contract for execution and keep track or the execution state. That way, your gates are deterministic.
Excellent reflection on SKILLs and their limitations!
You're one of the first one on Substack who clearly stated the challenge of skills.
I came to the same conclusion: the skill or as I call it "job to be done" needs to be exposed in the instructions file. The simplest way in Claude Cowork and ChatGPT work is to declare it in your project's AGENTS.md or CLAUDE.md. The same instructions will do. I have an instruction for trigger words for safe execution, e.g. when I say "Cyborg writing [job to be done]", execute...
We differ a bit in how we execute the job to be done. I declare a workflow a bit like you and only use skills for truly repetitive, atomic, and independent tasks (e.g. writer skill). To avoid drift, you may consider a YAML file for the state and logic and proper gates to validate each step.
On the job to be done itself, my workflow map the job, e.g. one workflow for a substack article; one step is the draft, another one is the QA with ~15 gates one of them ensuring the SEO/AE is done, I am on-brand, on-terminology, on-target audience, etc.
That makes a lot of sense. I'm also starting to restrict skills a bit more.
So what exactly do you mean by YAML file. I use that for metadata, but I don't think that's what you mean.
Using prompt in a md file is semantic and AI is mot hood at following orders. You end up with drift, e.g. use Gmail connector => uses Chrome extension
YAML file next to your workflow can define a machine-readable contract for execution and keep track or the execution state. That way, your gates are deterministic.
Interesting! I'm going to play around with this.