The expectations-checklist Skill — Locking the Operator's Acceptance Test
How Datarim preserves the operator's original intent across pipeline stages — from PRD through QA and compliance — using a structured expectations file that blocks on missed wishes.
An agent's quality check is only as reliable as the target it checks against. When the target is a paraphrase of the operator's intent — as happens when acceptance criteria are generated from a PRD — the check can silently drift from what the person actually wanted. The expectations-checklist skill exists to preserve the original intent as a separate, operator-owned artefact.
The file lives at datarim/tasks/{TASK-ID}-expectations.md. It is written once, from the PRD or plan, and then only ever extended — never rewritten. Each item is a single human-readable wish with a concrete success criterion that can be checked by running a command or observing a visible result.
When the file is created
For Level 3 and Level 4 tasks, the file is created by the architect during /dr-prd, once acceptance criteria are finalised. For Level 2 tasks without a PRD, the planner creates it during /dr-plan. Level 1 tasks do not require it, though it can be added optionally.
The three artefacts that surround it form a triad: the init-task file carries the operator's verbatim prompt; the task-description carries the agent's interpretation and implementation notes; the expectations file carries the acceptance test. These serve different purposes and are authored by different parties.
The schema and evidence types
Each wish item declares an evidence_type: empirical (a runtime command with real stdout), static (a grep or file check against the source tree), or measurement (a numeric value compared to a budget, such as latency or coverage). This field is required in schema version 2 and tells /dr-qa what kind of evidence to produce for each wish.
Status transitions follow a fixed enum: pending, met, partial, missed, n-a, or deleted. History is append-only — each status change gets a dated line, never an overwrite.
The blocking gate
At /dr-qa and /dr-compliance, the validator runs against the file and produces one of three verdicts. A PASS means every wish is met, not-applicable, pending, or deleted. A CONDITIONAL_PASS means some wishes are partial or missed, but each carries an operator-written override of at least ten characters. A BLOCKED verdict stops the pipeline, prints the failing wish IDs, and emits a routing CTA directing work back to /dr-do with those wish IDs in focus.
This routing behaviour is what distinguishes the expectations file from ordinary acceptance criteria: a missed wish does not just show up in a report — it stops the pipeline and names exactly what to fix.
Append-merge and multi-phase tasks
When a PRD is revised or a task gains scope, new wishes are appended at the bottom. Existing wishes are never edited; a history line records any change in context. For multi-phase umbrella tasks, wishes belonging to later phases remain pending throughout earlier phases — not n-a, which would permanently remove them from consideration. The history entry names the phase, so a later auditor can distinguish "not yet verified" from "overlooked".
Read more about the Datarim pipeline in what Datarim is, or see the finishing-a-development-branch skill for what happens after expectations are met.