Make one job repeatable
A folder, a ten-section playbook, and four prompts that build it, equip it, run it and grade it
The gap between a good one-off result and a system is that nobody wrote down what good looks like. This is one folder and one file that does: purpose, success criteria, rules, output format — plus the three sections most people skip, which are where the value actually is. Four prompts build the playbook, work out what it is missing, run it, then grade the result against it and say which of five things went wrong.
Playbook, context, tools, examples, verification. The first four are what most people assemble; the fifth is what turns it into something you can trust unattended. A workflow that produces output is easy. A workflow that checks its own output against a written standard, names what failed, and tells you which part of the standard caused it — that is the difference between a prompt you rerun and a process that improves.
The five-minute setup
One folder. Everything the agent needs lives inside it, so every run starts from the same place instead of from whatever happens to be in the chat.
What goes where
The numbered prefixes are doing real work — they keep the order stable so the agent reads them the same way every time.
The playbook template — ten sections
Fill the brackets by hand, or let the first prompt below interview you and fill them for you.
The first seven are a competent brief, and plenty of people already write something like them. The last three are rarer. Verification gives the agent a standard to check itself against. Failure handling replaces the default behaviour — quietly inventing a plausible substitute — with three explicit alternatives: stop, report, or write NOT VERIFIED. And the improvement log is what stops the same failure recurring, because it forces the fix back into the playbook rather than into your memory of that one time it went wrong.
Turn a job into a playbook
It interviews you before writing anything. The instruction not to invent missing business information — and to mark anything it assumes — is what keeps the output yours rather than generic.
Work out what the playbook is missing
Run it after the first. The REQUIRES CONFIGURATION marker is the useful bit — it stops the agent assuming it has access to a tool you have not actually wired up.
Run the job
The one you reuse every time — only the input line changes. Note that it deliberately does not return the result; it hands off to the verification stage.
Make it grade its own work
Eight checks, a structured pass/fail report, then fixes — and finally a diagnosis of which of five things actually caused the failure.
Five causes, and what each one means you fix
This taxonomy is the part that compounds. Without it every failure looks like “the AI got it wrong”, and you change the wrong thing.
Verification checklist — before any output leaves
There is an entry elsewhere in this lab about building an agent backend for a whole business — workspace, brain, access, infrastructure. This is the smaller, sharper cousin: one job rather than a company, and its job file carries ten sections rather than seven. The three extra ones are verification, failure handling and the improvement log. If you only ever adopt one idea from either, adopt those — they are what make the difference between output you have to check and output that checks itself.
The folder structure, the ten-section template, all four prompts and the verification checklist are as given in the source. The author’s byline, the pointer to their longer paid guide, and the closing follow prompt are not carried across. Nothing here needed external verification — there are no version numbers, star counts or pricing claims to check, which is unusual for this shelf and worth saying plainly rather than implying a check happened.