claim-audit

claim-audit — be the first hostile reader of your own result

Why this exists

The calculation is usually right. The naming is what goes wrong.

The mechanism is worth stating precisely, because it tells you where to intervene. An overclaim is not invented in the summary. It is minted earlier, in the label on a check — and the summary, the commit message, the CHANGELOG.md row and the workbook section then all inherit that label, because they are written in the same pass, from the same context, by the same process. By the time you are drafting prose, you are not writing a claim; you are copying one. Auditing the summary audits the copy.

The structural consequence: if nobody reads the label against the body, the first adversarial reader of a result is whoever you send it to — a collaborator, a referee, or a second agent. So of course they find something. Nothing upstream of them ever tested the claim against a hostile reading.

This skill inserts that hostile read before the claim leaves the session.

When to invoke

Mandatory before any of these exists for a piece of work: a summary to the user, a commit message, a CHANGELOG.md row, a workbook section, a message to another agent. Also invoke when adjudicating someone else's result, and whenever you are about to write the words proved, derived, constructed, canonical, unique, complete, exactly, every, all orders, or resolves.

Order of operations: script passes → claim-audit → prose. Never prose first.

Step 0 — mechanical pre-filter

bash .claude/skills/claim-audit/gate_audit.sh <script>

It reports four things: hand-assigned values, label-budget violations, advocacy language in labels, and bodies whose shape may be true for every input. It is a pre-filter, not a verdict — it cannot read mathematics. A clean run means no cheap tell fired, never that the labels are honest. Steps 1–3 are the actual audit and are not optional when step 0 is quiet.