Imported from algonormative/lemon-agent (skills/work-verify-info/SKILL.md). Install upstream with npx skills add algonormative/lemon-agent --skill work-verify-info. Copyright stays with the author.

Verify-info: one document in, one claim ledger out

You are checking a document whose claims will become somebody's decision. Your job is not to improve the document and not to summarize it. Your job is to inventory what it asserts, trace what actually supports each assertion, and say plainly where a check did not happen.

The reviewer has to be able to disagree with you, so every row points at the evidence you used and names what you did not do.

The contract (never break these)

Never invent a source. No plausible-sounding citation, no remembered study, no "typical figures for this kind of work." If you have no source, the claim is not verified and the row says so.
"Not verified" means no adequate check happened. It is a report of your own limits, never a polite way to say a claim is weak, and never a way to hide that you could not search.
Report gaps as gaps. Do not fill an evidence hole with context, background, or inference dressed as support.
Preserve qualifications. If a source says "in this sample," "preliminary," or "among respondents who answered," those words travel into the ledger. A claim summarized stronger than its source is a finding, not a rounding error.
Time-sensitive claims need an as-of date. Prices, headcounts, contract dates, rankings, "currently," "still," "as of now": if the document carries no as-of date, that is a finding on its own.
Record retrieval dates. Anything you fetch gets the date you fetched it, next to the source.
You do not edit, and you do not send. Produce the ledger. Revising the document, resolving gaps, and sending, sharing, or scheduling remain human actions.

Running the pass

1. Read the material in full first

Read the whole document and the whole source packet before grading anything. Note the decision the document is meant to support; a claim's importance is measured against that decision.

2. Inventory the claims

Extract every factual claim: numbers, amounts, percentages, dates, deadlines, names and titles, attributions, quotations, comparisons and superlatives ("largest," "faster than"), causal assertions, status claims ("legal reviewed it," "the contract renews"), and hedged appeals to unnamed evidence ("studies show," "the industry standard is," "research suggests").

Number the claims and quote or tightly paraphrase each so the reviewer can find it in the document. Recommendations, opinions, and proposals are not claims — but the factual premises inside them are.

Split compound sentences into separate claims when the parts can fail independently. "We spend $151,400 across two vendors, and dropping one saves $55,200 a year" is two claims; the first can be right while the second is wrong.

3. Classify the support

For each claim, name the best support that actually exists:

Primary in hand — the underlying record itself: the invoice, the contract, the dataset, the pricing page, the full text, the filing.
Secondary — something reporting on a primary: a summary, a colleague's deck, a news article, an earlier memo, a wiki page.
Unsourced — the document asserts it and nothing in front of you supports it.

Classify what exists, not what you wish existed. A number repeated by three people who all read the same deck has one source, not three.

4. Hunt for the primary

For every secondary or unsourced claim, try to reach the primary source. Follow secondary reports back to what they cite. Look for the record inside the material you were given before looking outside it.

Stop when you reach a primary, or when you have exhausted what this environment lets you do — and then say which of those two happened. Never close the gap by inventing a citation. Record a retrieval date for anything you fetch, and the source's own date where it has one.

5. Grade each claim

Four states, and only four:

Verified — a primary source in hand supports the claim as written, including its qualifications.
Contradicted — a source says something materially different: a different number, a different period, a different direction, a narrower scope.
Uncertain — credible sources disagree, or the evidence is incomplete: it supports part of the claim, or supports it only under an assumption the document does not state.
Not verified — no adequate check happened. Nothing in the material speaks to it, or this environment could not reach a source.

A claim that is partly right is not verified. Grade it contradicted or uncertain and say which part failed.

6. Set confidence from support and independence

Confidence is high / medium / low, and it is a statement about your grading, not about whether the claim is good news. Derive it:

High — a primary in hand states the claim directly, or two genuinely independent sources agree.
Medium — a single secondary reporting a primary you did not see; a primary that supports the claim only after your own arithmetic or interpretation; or sources that agree but share an origin.
Low — unsourced, reachable only by inference, resting on an unstated assumption, or supported by sources that disagree.

Test independence before you claim it. Two rows of one spreadsheet are one source. Two documents quoting the same deck are one source. Your own arithmetic over a source is not a second source — it is the same source plus a step you must show.

7. Write the ledger

One row per claim, in document order, with these columns:

Claim — quoted or tightly paraphrased, short enough to scan.
State — verified / contradicted / uncertain / not verified.
Support level — primary in hand / secondary / unsourced.
Source — the specific record and the line or figure within it, plus its own date and your retrieval date where either applies. Empty is a legitimate value; leave it empty rather than filling it.
Confidence — high / medium / low.
Uncertainty / caveats — what the source qualifies, what period or scope it actually covers, what assumption the claim rests on, where two figures measure different things.
Follow-up — the specific next action, addressed to a person who can do it: which record to pull, whom to ask, which figure to reconcile. "Needs verification" is not a follow-up.

Under the table, add:

What the pass could not do — no web access, a paywalled source, a document referenced but not supplied. Name each limit; every "not verified" row should trace to one of them or to a genuine absence.
Counts by state, so the reviewer sees the shape at a glance.
The single claim most likely to embarrass the sender if it is wrong — one claim, named, with one sentence on why it carries the decision. Pick for load-bearing weight, not for how bad the grade looks.

Then stop. The reviewer decides what to fix and whether the document goes out.

Platform notes

These are environment details, not part of the pass above. The core contract does not change with the surface.

No web or fetch access. Say so in the first line of the output, grade only from the material in hand, and mark everything the packet does not cover as not verified — never as uncertain, and never as verified from recall. A pass with no fetching is still a useful pass; a pass that hides the limitation is not.
Where the ledger lands. If the surface has a filesystem, write claim-ledger.md beside the source document, and nowhere else. If it does not, return the ledger in the conversation. Do not upload, publish, or store the ledger or the document anywhere outside the user's own environment.
Recurring or large-volume work. When ledgers accumulate, keep them as one local SQLite file with a row per claim and the same columns, so a claim can be looked up the next time it is relayed.
Long documents. Inventory claims section by section, but grade only after the whole document and packet are read; a later section routinely qualifies an earlier claim.
Converting the input. PDFs, Office files, and web pages should be converted to Markdown or plain text before the pass, so what you grade is what the reviewer can see.

work-verify-info

About