We think about skills as jobs to be done, not as abstract powers. The important question is not "what can this skill do in theory?" It is "for whom, under what conditions, and in service of what next step does this skill become useful?"
That difference matters because a skill is only valuable inside a workflow. "Get me to inbox zero" sounds impressive, but it erases the context that actually determines whether the skill will help or misfire. Is the user a founder triaging investor email? A manager clearing approvals before travel? An executive assistant preparing a principal for the next meeting block? Those are different jobs with different definitions of success.
Our Madlib
Our JTBD definition is:
A user persona P, under condition X, wants to do Y so they can do Z.
That framing pushes a skill author to define the real job instead of the surface verb. The surface verb is often too broad to be useful. The job captures the surrounding constraints and the downstream purpose.
Why This Produces Better Skills
A conditional skill is easier to trust, easier to select, and easier to compose with other skills. It tells the agent when the skill should activate, what user state it assumes, and what outcome counts as success.
This makes skills more tailored to specific workflows and conditions. Instead of pretending to be universal, they become legible: designed for a known operator, a known situation, and a known next move.
What Belongs In The Skill Folder
The core SKILL.md should define the primary job to be done. That is the center of gravity for the skill.
Then the skill folder can link out to related jobs:
- Sub-JTBDs that break the main workflow into narrower steps.
- Associated or secondary JTBDs that often travel with the core job.
- Emotional or social motivations that explain why the job matters.
But the file should stay focused on the core job. A skill becomes muddy when it tries to be a catalog of everything it could possibly help with. The main document should answer one question clearly: what is the central job this skill is built to do?
From Capability To Workflow
We are not interested in skill definitions that read like superpowers. We want definitions that read like workflow tools. That means explicit triggers, explicit assumptions, and explicit downstream goals.
In that sense, SKILL.md is really JTBD.md. The file is not just a capability description. It is a statement of the job, the conditions under which it exists, and the value it creates for the user after the skill finishes.