double-checklisted

# 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,