“Done when” checklists for work you hand to agents
Every step ends with a Done when line and an Evidence line, so nobody reports done without proof.
The problem
Most checklists say what to do. They rarely say how anyone will know it was done. That gap barely matters when you do the work yourself. It matters a lot when an agent does it and then reports done.
The template
<Title, as an outcome> due: day <N> after: <step keys> evidence: <none | note | link | file>
- [ ] The actions, as a short checklist
- [ ] Each one small enough to check off
Done when: <the observable condition, stated so a stranger could check it>.
Evidence (<type>): <exactly what to attach or write down>.Write the acceptance checks first due: day 0 after: none evidence: file
- [ ] List the 4 to 7 rules the feature must follow, in plain language
- [ ] Turn each rule into a test or a script that fails today
- [ ] Commit the checks before any agent starts on the code
Done when: the checks exist on main and every one of them fails against the current code.
Evidence (file): the commit hash of the checks, and the failing run's output.
Agent implements the feature due: day 1 after: checks evidence: link
- [ ] Give the agent the rules, the checks and the allowed paths
- [ ] The agent may not edit the checks
Done when: the checks pass, unchanged, and the diff touches only the allowed paths.
Evidence (link): the merge request, with the passing run attached.
Independent review due: day 1 after: implement evidence: note
- [ ] Someone other than the author reads the diff (another model family, or a person)
- [ ] Re-run the checks on a clean checkout
Done when: the reviewer has re-run the checks themselves and approved.
Evidence (note): who reviewed, what they ran, and anything they flagged.Log last week's numbers due: Fri after: none evidence: link
- [ ] Copy impressions, engagements and follows for every post into the tracker
- [ ] Log follower counts for each platform
Done when: every post older than 48 hours has numbers.
Evidence (link): the tracker's report for the week.How to use it
- Copy the format to wherever your tasks live: an issue, a markdown file, the prompt itself.
- Write the title as an outcome, then the actions as a short checklist, each one small enough to check off.
- End with Done when: a condition a stranger could observe. “The site is launched” can't be checked; “the homepage returns 200 at the real domain over HTTPS, and the sitemap is submitted” can.
- Add Evidence with its type (none, a note, a link or a file). Most steps need a note. Save files for the steps where being wrong is expensive.
- Set
dueas an offset (day 3) so the same plan can start any Monday, andafterto the steps it waits on.
Where it came from
Every step in the playbooks I write now has this shape, and the two lines at the bottom do the work.
An agent is very good at satisfying exactly what you wrote down. So write down the thing you actually want: the end state someone can observe, and the proof. It stops the “I've completed the task” message that turns out to mean “I wrote some code.” It also gives a reviewer a fixed target, so review stops being a matter of opinion.
The after field is the list an agent needs before it starts. It also shows you what's blocked and what can run in parallel.
Excellent does the checking half for agent work: it compares the result with what you asked and shows you the evidence. excellent.so