Verify Handoff

Verify Handoff

Produce a self-contained verification prompt that a fresh Claude session can use to independently check a deliverable against its source of truth. The fresh session sees the source and the deliverable — but knows nothing about how the deliverable was generated. That blindness is the whole point: a verifier who inherits the generator's reasoning is not a second opinion.

When this is worth using

Use at the end of producing any numeric deliverable going to stakeholders — period review decks, payroll audits, campaign sizing queries, financial summaries, anything where a wrong number is expensive to ship.

Do not use for personal drafts, exploratory analysis, or anything that won't leave your hands. The overhead of running a second session is only worth it when shipping a wrong number has real cost.

Flow

1. Confirm this warrants a handoff. If the deliverable is low-stakes, say so and skip the skill.

1. Gather inputs. Ask in one consolidated question (not a chain) if any are unclear:

• Deliverable path (the .pptx, .xlsx, .docx, .md you just produced)
• Source-of-truth path (workbook, raw data file, SQL query, or exported query result)
• Scope — what specific values / consistency checks need to hold
• Tolerance bands if different from default (±$1 currency, ±0.1% percentages, exact string match for names and framing language)
• Anything the user has already manually verified and wants the verifier to skip

1. Construct the handoff prompt. Use the template below. Critical: do NOT leak session-1 reasoning. No "we used column F because..." — just "source is at {path}, expected rule is X, verify."

1. Save the prompt to a file. Default location: same folder as the deliverable, named verify-handoff-{YYYY-MM-DD}-{short-slug}.txt. This makes the verification request auditable — if a number is ever challenged later, you can go back and see exactly what was checked.

1. Hand it to the user. Give them:

• A computer:// link to the saved prompt file
• A 3-line flow reminder: (a) open a fresh Cowork session, (b) point it at the same folder, (c) paste the prompt
• A note on what the verifier will write back (a report file next to the deliverable)

Prompt template

When building the handoff prompt, use this shape. Fill in bracketed sections from the conversation.

INDEPENDENT VERIFICATION TASK

You are verifying a stakeholder deliverable. Do not assume any prior work is correct. Your job is to independently read the source of truth, compute expected values, and compare them to what the deliverable shows. If a value in the deliverable has no corresponding source value, flag it — do not rationalize it.

Deliverable: {absolute_path_to_deliverable}
Source of truth: {absolute_path_to_source}

Verification scope:
- {named value 1: e.g., "Total P5 Sales" — expected to equal sum of store-level sales in {source sheet/column}}
- {named value 2}
- {consistency check: e.g., "Each RM's total = sum of their stores"}
- {callout consistency: e.g., '"X of 10 above budget" in Bottom 10 slide must match the table above it'}
- {framing/text check: e.g., "No occurrence of 'Mid-Period' anywhere in the deck — this is a Period End deliverable"}
- {anti-typo check: e.g., "Each dollar amount has four or more digits matching source; check for single-digit transposition errors like $38,998 vs $37,998"}

Tolerance:
- Currency: ±$1
- Percentages: ±0.1%
- Names, labels, framing language: exact match
- {any task-specific tolerance adjustments}

Procedure:
1. Read the source. For each item in the verification scope, compute the expected value independently.
2. Read the deliverable. Extract the corresponding value from its actual location.
3. Compare. Do not accept a mismatch as "close enough" outside the tolerance band.
4. Also flag:
   - Any value in the deliverable with no clear source equivalent (possible fabrication)
   - Any source value that looks anomalous (possible data quality issue upstream)

Output: write a report file to {same folder as deliverable}\verification-report-{YYYY-MM-DD}.md with these sections:
- MATCHES — brief list, one line each
- MISMATCHES — for each: location in deliverable, deliverable value, source value, absolute delta
- UNMAPPED — values in deliverable with no source tie
- ANOMALIES — suspect source values worth a human second look
- FRAMING/TEXT ISSUES — any failures on exact-match checks

Do not propose fixes. Do not rewrite the deliverable. Report findings only. End with a one-line verdict: PASS / PASS WITH WARNINGS / FAIL.

What makes a good scope list

Good items — specific, computable, location-pinned:

• "Total P5 Sales (title slide KPI card) equals sum of column D in Sheet1"
• "Top Performer name and store match the source row with highest % budget"
• "Bottom 10 callout 'X of 10 above budget' matches what the Bottom 10 table actually shows"
• "No 'Mid-Period' text anywhere — this is a Period End deliverable"

Bad items — vague, unverifiable, or not computable from the source:

• "Verify the deck looks right" — verifier will skim
• "Check the narrative makes sense" — not a numeric check
• "Make sure nothing is off" — no shape for the verifier to use

If you cannot enumerate what to check, the handoff will not save you. Push on the scope list before emitting the prompt.

Style rules for the prompt

• Imperative, no hedging. "Compute X from source" — not "you might want to check X."
• No session-1 context. The verifier must not see "we chose Y because Z" — that biases the check.
• Absolute paths, not relative. The fresh session has a different working directory model.
• One scope item per bullet. Combined items get skimmed.
• Tolerance is non-negotiable. State it once, state it clearly.

Pitfalls

• Leaking reasoning into the handoff. Session 1's assumptions must not appear in the prompt. If the verifier is told "source is in column F (RRP, not I)," it can't independently catch the case where column F was the wrong choice. Give it the source and the rule separately; let it discover the mapping.
• Vague scope. "Verify the numbers" = useless. Name the values.
• Running this on every task. It is for stakeholder-facing deliverables. Using it for every email draft burns sessions.
• Over-trusting the verification report. The verifier can also be wrong. Treat PASS WITH WARNINGS and FAIL seriously; treat PASS as one strong signal, not certainty. If a number is critical, a third independent check (yourself, a colleague, a hand-calc) is not overkill.
• Forgetting to save the prompt. Auditability is half the value. A saved prompt file is a record of what was checked.

What this skill does not do

• Perform the verification itself — that runs in the fresh session.
• Fix mismatches — the verifier reports findings; fixes happen in a third step (usually back in session 1 or a follow-up).
• Replace domain-specific validation skills (e.g., carwash-deck-refresh Phase 4). This skill is for the handoff; the verifier session may still need domain skills to do the check well.
• Produce a verification prompt for a deliverable that does not yet exist. Generate the deliverable first.

Example invocation

User: "/verify-handoff" (after just finishing the P5 deck refresh)

What happens:

1. Confirm deck is stakeholder-facing — yes.
2. Gather: deck path (from session context), source workbook path (ask if not clear), scope list (KPI cards, RM/DM totals, Top/Bottom 10, Bottom-10 callout, no Mid-Period text, standard tolerances).
3. Build the prompt from the template, filling in paths and scope.
4. Save to ...\Presentation POC\verify-handoff-2026-04-23-p5-deck.txt.
5. Return a computer:// link and the 3-line flow reminder.

User's next move: open fresh Cowork session → select the same folder → paste the prompt → fresh session reads source + deck, writes verification-report-2026-04-23.md next to the deck.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: abhijit-nexlytix
• Source: abhijit-nexlytix/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.