checklist-bound-execution

Checklist-Bound Execution

A harness for fanning checklist / plan items out to spawned agents WITHOUT drift. Use it any time two or more agents execute items from a shared plan and "did the agent actually do its exact job?" matters.

Why this exists (read first)

Spawned agents (Workflow agents, Task subagents) start with a FRESH, isolated context. They do not see the conversation, the plan, or your intent unless it is handed to them. When the assignment is vague — or worse, fails to arrive (the Workflow args global is unreliable and has come through as undefined) — the agent reconstructs the task from whatever it can read and IMPROVISES. That is the root cause of drift, not "lack of discipline."

Enforcement is therefore NOT a single instruction. It is four mechanisms together:

1. Determinism of assignment — each agent receives its item VERBATIM, embedded in its prompt.
2. Structured proof — each agent must return a schema-validated completion record (validated at the tool layer, so it cannot hand-wave; the runtime retries on mismatch).
3. Independent verification — a separate, read-only agent re-checks each item against its acceptance criteria, adversarially, and can FAIL it.
4. Loop-back — a failed item is sent back to a worker to fix, then re-verified, up to a bound.

A skill alone is advisory. This skill works because it pairs the procedure (here) with the Workflow script's deterministic control flow + structured-output schemas + a verifier stage. An optional SubagentStop hook can add a hard, model-can't-skip gate; this skill does not require one.

The non-negotiable invariants

• One item, one job. A worker does ONLY its assigned item(s). It touches ONLY the files the item names. Anything outside scope is a deviation — reported, not silently done.
• Verbatim, not from memory. The item's spec and acceptance_criteria are the source of truth. If they conflict with the worker's prior assumptions, the item wins. If the item is ambiguous or impossible as written, the worker returns status: "blocked" with the reason — it does NOT guess.
• No args, no filesystem in the script. Workflow scripts cannot read files or rely on args. Embed the checklist as a literal in the script (see references/workflow-template.js). Workers may ALSO be given the checklist file path to re-read as a cross-check.
• Verifier is read-only and adversarial. It tries to prove the item is NOT done. It cannot edit (so it cannot bias itself by fixing). Default to FAIL when evidence is missing.
• Done means verified. An item is complete only when its verifier verdict is pass: true.