From Skill to Workflow: The Four Parts
10 min read
A skill is a worker who knows one job. A workflow is the shift schedule: which worker does what, in what order, and where the supervisor signs off. The skills course made you good at hiring; this chapter teaches the schedule. Every workflow, whatever it does, has the same four parts.
1. A trigger
The trigger is the event that starts the workflow, and it must be an event, not a feeling. "A web inquiry arrives" is a trigger. "When I get around to marketing" is not, and workflows without real triggers quietly return to being improvised prompting.
Triggers come in two kinds, and your audit already sorted your tasks into them:
- Event triggers. Something happens and the workflow answers it: a lead arrives, an invoice passes 14 days unpaid, a job is marked complete. These run whenever the event fires.
- Calendar triggers. A time arrives and the workflow runs: Monday 9 a.m. for marketing, Friday 3 p.m. for numbers. These are the backbone of Chapter 4.
2. Numbered steps
Each step names who acts (a skill, or you) and what the step produces. Steps produce artifacts, drafts, lists, numbers, never vague progress. If you cannot name what a step outputs, it is two steps or none.
3. Checkpoints
A checkpoint is a step where a human reads the output before the workflow continues. Checkpoints are not failure to automate; they are the load-bearing part of the design, and the next two lessons place them deliberately. For now, one rule: every workflow has at least one checkpoint before anything leaves the building.
4. A done-check
The finish line, stated so plainly that anyone can see whether the workflow completed: "reply sent and follow-up dated," not "lead handled." Workflows without done-checks do not fail; they just trail off, which is worse, because nothing tells you.
The runbook format
A workflow is written as a short numbered document called a runbook. Here is the shape, using the maintenance-reminder workflow from our HVAC company:
WORKFLOW: Maintenance reminders
TRIGGER: Calendar. First Monday, 9:40, inside Monday block.
1. [You] Export list of plan customers due for seasonal
tune-up this month.
2. [Skill] Reminder Writer drafts one email per customer:
plan status, suggested weeks, one-line booking
reply. Reads the Brain for tone and promo.
3. [You] CHECKPOINT. Read all drafts (10 min). Fix or
drop any that feel off.
4. [You] Send. Log count in the week sheet.
DONE WHEN: Every due customer has a sent reminder logged.Four steps, one checkpoint, an unambiguous finish. Notice what the runbook does not contain: no prompt text, no explanation of how Reminder Writer works. The skill file holds the how; the runbook holds the when and the who. This separation is what will let you hand the runbook to an employee in Chapter 6 without also handing over a prompting course.
Why write it down at all
You could hold a four-step sequence in your head, and while it lives there, three things are true: only you can run it, you cannot improve what you have not looked at, and every run costs a small decision about what comes next. Written down, the workflow runs on rails, an employee can cover it, and when step 3 keeps catching the same mistake, you have a specific step to fix rather than a general sense that "the AI is being weird."
The runbook is also where scope lives. A workflow that exists on paper has edges; one that exists in your head grows a step every time you are feeling ambitious, until it is too heavy to run on a busy Monday.
Try it now
Take the highest-scoring task from your week audit and draft its runbook: trigger, numbered steps with [You] or [Skill] on each, at least one checkpoint, and a done-check a stranger could verify. Do not polish the steps yet. The next lesson builds the full lead-to-invoice line, and you will steal at least two of its moves for your own draft.