Double Check

Family version: v6 (2026-10-10).

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

This skill is both the gate (when verification runs, on what, and what happens to a FAIL) and the mechanism (how to brief a cold verifier so it checks the world instead of your argument). Both live here — there is no companion skill to load.

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-opus, fable-sonnet). 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 run closes its report with a FINAL-COLD-CHECK: line. yes → seam check only. intermediates-only, no, or no line at all → run the full checks (panel or self-check mode, per below). Absence of the line is never evidence that the check happened.
2. On request: "double check this", "verify this", "make sure this is right".

Panel or self-check. Some hosts allow subagents only when the user asks for them (observed: the cloud runtime's Agent tool, 2026-10-10). Run the checker panel only when this skill was invoked by slash command or by name ("double check this"), or when the fable run that called it was spawn-authorized (see fable-mode's Invocation gate). Otherwise — "verify this", "make sure this is right", or a fable run without spawn authorization — use self-check mode (step 2) and say so. The usage limit overrides both: when the user reports usage at their threshold, check in first; unless they say otherwise, use self-check mode.

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.

The core rule: pass the claims, never the reasoning

An agent reviewing its own work almost always agrees with itself. It re-reads its reasoning, finds it reasonable, and signs off — the same blind spot that produced the error also produces the approval. A cold agent has no stake in the conclusion and no memory of why it seemed right. It has to go get the evidence again. That is the entire mechanism; everything below protects it.

The moment a verifier reads why you concluded something, it starts evaluating your argument instead of the world. It inherits your framing and your blind spot. You get agreement, not verification.

Give the verifier: the claim, the spec or original requirements, and where to look. Withhold: your reasoning, your confidence, your narrative, and which claims you think are shaky. Do not hint at what you expect it to find — "I think claim 4 might be weak" tells it where to spend effort and implies the others are fine.

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. Good: C3: /Applications is 63 GB. Bad: C3: Storage looks basically fine, mostly apps. If a claim can't be stated so an observation would refute it, it isn't a claim — it is a summary. 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

Panel mode (Agent tool available AND spawning authorized): run the checker panel.

Spawn fresh checker agents using the brief template below. 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.

Tier routing — match the tier to the check, not to the importance of the deliverable:

• One Haiku checker (all mechanical checks in one bundle): numbers re-added, files opened and read back, links/paths exist, commands re-run, counts reconciled. Add a second Haiku only when the mechanical checks will not fit one brief, and say why.
• 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.

Collect every verdict. Spawns may run in the background even when foreground is requested (observed in the cloud runtime, 2026-10-10). Do not fix, synthesize, or deliver until every checker has returned; never act on a partial panel. If a checker errors or fails to return, run its checks in self-check mode and label them so.

Self-check mode (no Agent tool, or spawning not authorized): degraded single-pass mode.

Say plainly that the checker panel did not run and why (no Agent tool on this surface, or spawning not authorized). 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.

Checker brief template

You are a COLD VERIFIER. Claims below were produced by other agents.
You did not see their reasoning. Assume each claim may be wrong.

[hard constraints — e.g. READ-ONLY, no sudo, no modifications]

## CLAIMS
C1: <falsifiable assertion> → check via: <command / source>
C2: ...

## OUTPUT
C1: CONFIRMED|REFUTED|UNVERIFIABLE — <exact command> → <exact output line>
C2: ...

## CORRECTIONS
<every claim that was wrong, and what is actually true>

Refute freely. Finding a wrong claim is a success, not a failure.
Do not report a claim as confirmed unless you personally observed
the output that proves it. If you could not check something, say
UNVERIFIABLE — do not guess and do not pad.

The "refute freely" line is not optional. Without it, agents optimize for agreement: they read a claim, find it plausible, and confirm.

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. It is how blind spots stay visible instead of quietly becoming assumed-true. 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. Multi-agent work has a seam — the workers produce findings, a verifier checks those findings, and then the synthesizer writes the deliverable, and the synthesizer's own additions and escalations were never checked by anyone.

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. Real example: a worker correctly reported an app bundle's mtime as an "un-updated signal, not a true unused signal"; the synthesizer turned that into "18 months stale, security exposure, update immediately." The app was four weeks behind. Nothing had checked the final report.
• Proxy metrics read as the real thing: a timestamp is not a version; a file size is not disk usage; a process existing is not a process running; 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. If the fix invalidates upstream content, fix and re-check that too.

One re-check round. In panel mode, batch every fixed item into ONE fresh re-checker brief (Haiku, unless an item needs Sonnet's logic check). If anything fails that round, fix it and verify it by cold self-check — re-derive from the artifact, no new spawn — and mark those items "self-checked" in the summary. No further spawn rounds. An Opus adjudicator for a disputed verdict (step 2) sits outside this cap — at most one per disputed item. In self-check mode, every re-check is a cold re-derivation.

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. 1× Haiku, 1× Sonnet, 1 re-check round | self-check — no Agent tool / spawning not authorized]

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. When the mistake was yours rather than a worker's, say so plainly too — own the specific error and move on, no extended apology.

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 1 Haiku + 1 Sonnet, plus at most one re-check round (cut from 2–4 Haiku + 1 Sonnet on 2026-10-10, after a 2+1 panel cost ~580K subagent tokens; coverage at 1+1 not yet measured). Escalate to Opus only on disagreement. Match tier to the check, not to the importance of the deliverable — mechanical checks stay cheap.