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
- 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.
- 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.
- 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.
- State confidence on claims. "Weak evidence — X only follows
if Y", never "X was overstated".
- 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.
1---2name: double-check-23description: Use when asked “are you sure/certain” or “I don't trust that”; recheck code/files from source and repeat prior analysis in full, not just changes.4---56# Double-check78Re-verify by re-deriving. The deliverable is the verified answer,9not a record of how it differs from your last one.1011Read `../../references/verification-contract.md`12before responding — it is the contract this skill enforces.1314## Why the obvious response is wrong1516Your prior answer sits in the transcript, so re-checking it feels17like editing it: keep the numbering, mark each item *holds* /18*overstated*, report what changed. But transcript order is not19user-adopted state. The user usually has not internalized the prior20answer — often the double-check request is itself the signal that21they never committed to it. A verdict list against text they never22held is unreadable, and inherited scaffolding hides whatever the23first pass missed entirely.2425## Steps26271. **Recover the request, not the answer.** From the conversation,28 take the original question, its constraints, and any narrowing the29 user added since. Prior answers of yours are untrusted scratch —30 good for recalling which sources exist, never citable as evidence.312. **Re-derive from source.** Re-open the artifacts — files, issues,32 specs, data — and rebuild each claim from what they actually say.33 Verification is performed, not asserted: cite what you re-opened34 and what it said, or the command you ran and its output. "Verified35 earlier in this conversation" anchors a claim to transcript36 position and does not count.373. **Rebuild the structure.** Outline from the source material and38 the request, not from your prior answer's item numbers. A claim39 that no longer earns a place simply does not appear; a missing40 area simply appears.414. **State confidence on claims.** "Weak evidence — X only follows42 if Y", never "X was overstated".435. **Check for adopted state.** If the user acted on a prior claim —44 committed, filed, sent, built on it — name that correction45 explicitly, once, briefly. Otherwise the prior turn is not a46 baseline and does not exist in your output.4748## Output shape4950Same shape the original request implied, as if answering for the51first time. No "what changed" section, no verdict legend, no52*as noted above*. A reader who never saw the first answer must lose53nothing.5455When a narrow request ("are you sure about X?") scopes the answer to56X, still append anything material you discovered while re-deriving —57as a standalone fact about the subject ("the ADR also permits Y"),58never as a correction of your prior answer. Scoping down the answer59must not scope down what the user learns.