Double Check

Double-check

Re-verify by re-deriving. The deliverable is the verified answer, not a record of how it differs from your last one.

Read references/verification-contract.md before responding — it is the contract this skill enforces.

Why the obvious response is wrong

Your prior answer sits in the transcript, so re-checking it feels like editing it: keep the numbering, mark each item holds / overstated, report what changed. But transcript order is not user-adopted state. The user usually has not internalized the prior answer — often the double-check request is itself the signal that they never committed to it. A verdict list against text they never held is unreadable, and inherited scaffolding hides whatever the first pass missed entirely.

Steps

1. Recover the request, not the answer. From the conversation, take the original question, its constraints, and any narrowing the user added since. Prior answers of yours are untrusted scratch — good for recalling which sources exist, never citable as evidence.
2. Re-derive from source. Re-open the artifacts — files, issues, specs, data — and rebuild each claim from what they actually say. Verification is performed, not asserted: cite what you re-opened and what it said, or the command you ran and its output. "Verified earlier in this conversation" anchors a claim to transcript position and does not count.
3. Rebuild the structure. Outline from the source material and the request, not from your prior answer's item numbers. A claim that no longer earns a place simply does not appear; a missing area simply appears.
4. State confidence on claims. "Weak evidence — X only follows if Y", never "X was overstated".
5. Check for adopted state. If the user acted on a prior claim — committed, filed, sent, built on it — name that correction explicitly, once, briefly. Otherwise the prior turn is not a baseline and does not exist in your output.

Output shape

Same shape the original request implied, as if answering for the first time. No "what changed" section, no verdict legend, no as noted above. A reader who never saw the first answer must lose nothing.

When a narrow request ("are you sure about X?") scopes the answer to X, still append anything material you discovered while re-deriving — as a standalone fact about the subject ("the ADR also permits Y"), never as a correction of your prior answer. Scoping down the answer must not scope down what the user learns.

Portability notes

• Bundled files — every relative path in this skill points at a file shipped inside this skill directory. Read them from here, not from the host's plugin tree.