Double Check

Double Check

Automatic verification pass on a finished deliverable. The user should never have to re-check work themselves — this skill is that re-check.

What it is and is not

• It verifies outputs, it does not re-run the task. A full second run produces a second divergent version and a comparison problem; attacking the finished artifact catches the same errors at a fraction of the cost.
• It runs after the work is complete and before it is delivered.
• It never runs on its own output. One double-check per deliverable. Fixes triggered by a FAIL get their specific failed check re-run — not a whole new panel. No recursion.

When it runs

1. Automatically at the end of any fable-mode run (fable-mode, fable-fable, fable-opus, fable-sonnet, fable-haiku). Those skills call this one as their final delivery gate. Exception: if a fable run already executed a cold verification of the final deliverable, do not duplicate it — run only the seam check (section "Check the synthesis seam") and skip the rest. Do not infer this from the narrative: the orchestrator closes its report with a FINAL-COLD-CHECK: line. yes → seam check only. intermediates-only, no, or no line at all → run the full panel. Absence of the line is never evidence that the check happened.
2. On request: "double check this", "verify this", "make sure this is right".

Skip conditions

Trivial, reversible, low-stakes output where being wrong costs nothing and is immediately visible. Say in one line that double-check was skipped and why. Never skip when the deliverable tells the user to delete data, change a system or security setting, spend money, or act on a warning.

Procedure

1. Extract claims and requirements

From the finished deliverable, build two numbered lists:

• Claims (C1, C2, ...): every falsifiable assertion in the deliverable. Facts, numbers, file paths, computations, statements that something works. Each must be stated so a specific observation could refute it. If a claim can't be, either sharpen it or drop it from "established" status in the deliverable.
• Requirements (R1, R2, ...): everything the user's original request demanded. Each phrased as a yes/no: "deliverable contains X", "file Y exists and opens", "all rows from source present".

For each item, name the exact check: the command, file, source, or comparison that settles it. An item with no nameable check is marked UNVERIFIABLE by you, up front, and labeled as such in the deliverable.

2. Detect the runtime, pick the mode

Agent runtime (Claude Code, Cowork — Agent tool available): run the checker panel.

Spawn fresh checker agents. They receive claims, requirements, checks, constraints (READ-ONLY — checkers never modify anything), and the output format. They never receive your reasoning, your confidence, or hints about which items you suspect — a verifier that reads your reasoning inherits your blind spots and returns agreement, not verification.

Tier routing:

• Haiku checkers (parallel, one per bundle of mechanical checks): numbers re-added, files opened and read back, links/paths exist, commands re-run, counts reconciled.
• One Sonnet checker: requirements coverage (every R satisfied by the artifact itself, not by the work log), internal consistency, logic of any argument the deliverable makes.
• Opus (only if needed): when two checkers disagree on the same item, or a REFUTED verdict is itself disputed after the fix. Adjudicates; does not re-check everything.

Every checker brief must state: "Refute freely. Finding a wrong claim is a success, not a failure. Do not report CONFIRMED unless you personally observed the output that proves it. If you cannot check something, say UNVERIFIABLE — do not guess."

Chat runtime (no Agent tool): degraded single-pass mode.

Say plainly that the full checker panel isn't available on this surface. Then run the checks yourself, cold: work only from the claims/requirements lists and the artifact — deliberately not from memory of how you produced it. Re-derive each number, re-read each file or source, re-test each requirement against the artifact. Same ternary verdicts, same output format. Weaker than fresh agents — label it as a self-check in the summary.

3. Verdicts — ternary, forced

Every claim and requirement returns exactly one of:

• PASS / CONFIRMED — with the exact command or observation and the exact output line proving it. "Looks good" is banned; it is not a verdict.
• FAIL / REFUTED — with what is actually true instead.
• UNVERIFIABLE — with why the check could not run. First-class outcome, not a failure. A panel that never returns UNVERIFIABLE is guessing to look thorough.

4. Check the synthesis seam

The error that survives everything above: work checked at intermediate stages, then the final write-up introduces new claims nobody checked. Always extract claims from the document about to be handed over, not from intermediate outputs. Two seam-specific hunts:

• Escalated hedges: anywhere a caveat in the underlying work became a firm conclusion in the deliverable. If the work said "signal" and the deliverable says "exposure", check it.
• Proxy metrics read as the real thing: a timestamp is not a version; a file size is not disk usage; a search returning nothing is not evidence of absence. Verify the actual quantity.

5. Fix, then re-check

Any FAIL: fix the deliverable, then re-run that specific check (fresh checker in agent runtime; cold re-derivation in chat). If the fix invalidates upstream content, fix and re-check that too. Deliver only when every item is PASS or explicitly UNVERIFIABLE. Never deliver with an unresolved FAIL footnoted.

6. Report

Deliver with a short verification summary:

Double-check: N claims + M requirements.
PASS: n. FIXED after FAIL: n (list what was wrong, one line each). UNVERIFIABLE: n (named).
Checkers: [e.g. 2× Haiku, 1× Sonnet | self-check, no agents on this surface]

Name what got refuted and fixed — that is the evidence the check was real. A summary that confirms everything is either a clean run or a rubber stamp, and the user can't tell which unless specifics are named. If everything passed cleanly, say that plainly; do not manufacture a finding.

Operational rules

• Verify-before-flag applies: a checker's FAIL must cite the observed evidence, not the absence of confirmation. Absence of evidence is not a finding.
• Checkers are READ-ONLY. Only the main session fixes things.
• Budget: default panel is small (2–4 Haiku bundles + 1 Sonnet). Escalate to Opus only on disagreement. Match tier to the check, not to the importance of the deliverable — mechanical checks stay cheap.
• If the runtime has a cold-verify skill available, its brief template and rules are the canonical form of the checker brief — reuse them rather than improvising.