The Pre-Completion Checklist

Agents optimize for completion, not correctness. Left alone, one declares "done" after a partial build and a test run it chose not to investigate. So block the completion signal until a fixed sequence has passed.

Why this, for you: "done" is the moment the agent is most likely to lie to you — premature closure is built into how it's trained. A pre-completion checklist intercepts that signal and forces a verification pass, catching the gap between intent and implementation before it ships.

Without an explicit gate, an agent declares success after partial implementation, a failing test it didn't investigate, or code that compiles but doesn't satisfy the requirement. A pre-completion checklist intercepts the completion signal and forces a verification sequence first.

1 Four phases, each a gate

Planning — did you understand the requirement before starting?
Building — did you implement what was specified, not a simpler substitute?
Verification — did you run the end-to-end tests, check for regressions, confirm the output satisfies the stated requirement?
Fixing — did you address every issue found, tracked in a verification ledger, before declaring done?

Each phase must complete before the next begins. The checklist is not a suggestion — it is a gate. Forcing the agent to re-engage with the original requirement after output is generated creates a second pass that catches drift between intent and implementation (the same backward-checking that Weng et al., 2022, found improves accuracy across arithmetic, commonsense, and logic).

2 A hook, not a sentence

Prompt-based instructions achieve 70–90% compliance; a hook achieves near-100% because it runs at the system level, outside the LLM's reasoning chain — so it fires even when the agent forgets the instruction under context pressure.

Implement the gate three ways, strongest last: as a mandatory final step in the system prompt; as a PostToolUse hook that detects completion signals and injects the checklist as a continuation prompt (exit 2 to block); or as dedicated middleware that wraps the completion path and blocks until the checklist returns PASS. The combination — hook plus explicit prompt instruction — is what makes it run even on a long session.

# PostToolUse hook: on a "done" signal, inject the checklist and block if grep -qi 'task complete\|"status".*"done"\|STOP'; then echo "Before completing, report PASS/FAIL for each: 1. Run the suite — paste the actual output, do not summarize 2. Confirm each acceptance criterion is met 3. Confirm no existing tests were removed or modified" >&2 exit 2 # blocks the completion until the checklist passes fi

3 Specific items, or it's theater

Effective items are specific and verifiable. "Run the test suite and confirm all tests pass" — not "check your work." "Confirm each acceptance criterion is met" — not "review the requirement." A vague item nominally passes without verifying anything; the agent satisfies the surface form of the instruction, not its intent.

When the gate backfires

Unsatisfiable items deadlock. If the agent can't make a failing test pass — flawed test, contradictory requirement, missing capability — the checklist becomes an infinite loop; add a retry cap and an escalation path. Vague items give false confidence — "check your work" passes without checking. And latency compounds: each pass is a full round-trip, so a gate at every stage of a long pipeline can cost more than just running the end-to-end tests directly.

↪ Your win: gate the "done," don't trust it

Intercept the completion signal — premature closure is built into agent training.
Four phases as gates — planning, building, verification, fixing; each before the next.
Implement as a hook — ~70–90% prompt compliance vs near-100% at the system level.
Every item specific and observable — "paste the test output," not "check your work."
Cap retries — an unsatisfiable item turns the gate into a deadlock.

Retrieval practice — recall, don't peek

Question 1Agents declare "done" prematurely because they optimize for…

Question 2A checklist enforced as a hook beats one in the prompt because it…

Question 3A checklist item like "check your work" fails because it is…

Question 4An unsatisfiable checklist item risks creating…

Question 5 · spaced recall from Lesson 1The danger zone for agent errors is when the answer is…

Ask me anything. Want a PostToolUse pre-completion hook tuned to your stack, or help turning a vague "looks good" gate into specific, observable items? Next: Red-Green for Agents — tests as the spec, run as separate invocations.