Oleafly Verify Claims

Oleafly Verify Claims

This skill answers one question for every factual sentence in a section: does the source it cites actually say that? The output is a table, a report, and a list of proposed fixes. It is not a rewrite.

Never edit the user's prose in this skill. A claim audit that silently corrects what it finds destroys the evidence of what was wrong, and the user cannot check your judgement afterwards. Propose the fix, name the file and line, and let them decide. The only files this skill writes are research/claims.md and a report under review/.

Step 1. Fix the scope

Audit one section, or one file, at a time. A whole manuscript in one pass produces a table nobody reads.

Confirm with the user which file, or infer from what they just asked about. project_map with {} returns sections with the file and line of each heading, so you can name the boundaries precisely.

Set the plan with update_todos, one item per step below.

Step 2. Read the text with line anchors

read_file with {"path": "sections/related.tex", "offset": 1, "limit": 200}. The result carries offset, lines_returned and total_lines. Line N of the returned content is file line offset + N - 1. Read further slices until you have covered the section.

To pin a line number exactly, search_project with {"query": "<six distinctive words from the sentence>"} returns the file and line of every match. That is more reliable than counting, and it is the anchor to record in the table.

Step 3. Extract the claims

Go sentence by sentence. A claim is anything a reader could be wrong to believe.

Audit these:

• A statement about what prior work did, showed, achieved or failed to handle.
• A number, a rate, a size, a threshold, a benchmark result, a date.
• A statement about the state of a field. "Most approaches assume..." is a claim about a population.
• A causal statement. "Because X, Y follows."
• A statement about what is standard, common, or widely used.
• A definition attributed to a source.

Skip these:

• The paper's own contributions and results, which are evidenced by the paper itself, not by a citation.
• Statements of intent. "We now describe the method."
• Pure mathematics that is derived in place.
• Hedged framing that asserts nothing. "One way to see this is..."

Number the claims C1, C2 and onward. Quote each one, or paraphrase tightly enough that the user recognises the sentence.

Step 4. Map each claim to its cited key

For each claim, record which keys the sentence cites. A claim with no citation is not automatically a problem, but it has to be classified deliberately (step 6).

project_map with {} gives bibKeys and unresolvedCites. Any key on the claim list that appears in unresolvedCites is already broken before the content question is asked: it cites nothing. Record it as unsupported with the reason "no bibliography entry".

Step 5. Gather the evidence

For each cited key, in this order, stopping when you have enough to judge:

1. read_file with {"path": "research/sources/<key>.md"}. If the sweep ran, this holds the abstract verbatim and the provenance. This is the cheapest real evidence available.
2. project_library_search with {"query": "<the claim, in the source's own vocabulary>"} searches the project's own files, including any imported full text and the user's reading notes.
3. read_file on the PDF at research/sources/<key>.pdf when the abstract does not settle it and the paper is in the project.
4. verify_citation with {"doi": "<doi from the entry>"} to confirm the entry resolves to a real record with the title, venue and year the entry claims. This checks the citation exists and matches; it does not check that the paper supports the claim. Both checks matter and they are different.

When no evidence is available at all, that is a finding, not a blocker. Record the claim as unsupported with the note "no source note, no full text in the project", and propose that the source be added by oleafly-literature-sweep.

Never judge from the title. Titles overstate, and a title that matches the claim is the most common way a wrong citation survives review.

Step 6. Assign a support level

Exactly one of three, defined in full in references/support-levels.md.

partial is the level that does the most work. Most citation problems in real manuscripts are not fabrications, they are a true finding stretched one step past what was measured.

The evidence note must say what the source actually says, not just that it disagrees. "Measured on graphs up to 10k nodes; the sentence says arbitrary scale" is actionable. "Overstated" is not.

Step 7. Write research/claims.md

Create the directory if needed with create_file and {"path": "research", "is_dir": true}, then write_file the table from assets/claims.md.

Columns: number, claim, location as file:line, cited key, support level, evidence note. Then a summary count, then a proposed fixes table.

If research/claims.md already exists, read_file it first and merge rather than replacing. An earlier audit's findings on other sections are not yours to discard.