report-claim-audit

Topics in the source

• Report claim audit
• 0. Pin your authority before reading anything
• 1. Recount every claim from the artifact that owns it
• 2. Look for what the report did not say
• 3. Price the decisions
• 4. Act only inside your boundary
• 5. Output shape
• Pitfalls

A daily dispatch, teammate handoff, or closeout digest is a set of claims, not evidence. This skill is the pass that turns it into a decision brief the operator can answer with numbers instead of re-reading the repo themselves. Open the role contract that governs the run: who may write which paths, what needs operator approval, what must never be written. Everything below is shaped by it — an audit run usually licenses reading and at most a notes/STATUS write, never a repair of what it found. Numbers come from the per-item JSON, the control manifest, the index, or the validator's own output — never from the report's table. A report correct eight times running is still a hypothesis on the ninth. Re-derive derived counts (N of M complete, X cells missing a key) by walking the per-item files in code, not by re-reading the report's prose. Print what you computed next to what it claimed. Verify absence claims with the negative search. A confirmed absence is itself a finding about the surface: "no STATUS.md exists anywhere" reframes the run from reading status to deriving it, and that recurring cost belongs in the brief. When the report names a validation command, locate the script befor

This is an excerpt. Refer to the complete source and its current requirements.