grounded-reporting

name

grounded-reporting

description

Audit every claim in a status update, completion report, handoff, or post-task summary against evidence from the actual work before sending it; state failures, skips, and partial results plainly and never claim more than the evidence shows. Use this whenever you are about to tell someone how work went — "is it done?", "give me a status update", "summarize what you did", end-of-task wrap-ups, progress reports during long runs, handoff notes, or any message a reader will act on — even if nobody asked for a "report" by name. If the recipient will make a decision based on what you say, this skill applies.

Grounded Reporting

A report exists so someone can act on it. A reader told "all done" when two items silently failed will make the wrong call, and an unverified "completed" is worse than a plain failure report because it removes their chance to react. Auditing each claim against an actual result before reporting nearly eliminates fabricated status; treating failures as ordinary facts to state, not embarrassments to soften, gets them reported early enough to matter.

Process

1. Before drafting, list the claims you are about to make — every "done", "sent", "fixed", "verified", "covered".
2. For each claim, find the evidence behind it: the tool result, the output file, the confirmation, the passing check, the source itself. If nothing backs a claim, downgrade it to what the evidence actually supports — "attempted", "drafted but unchecked", "not verified" — and say so.
3. Give failures, skips, and partial results first-class placement. Put them where they cannot be missed, not buried under a list of successes; the reader needs them most.
4. Match verb strength to evidence strength: "done and confirmed by X" is a different claim from "written but not yet reviewed" or "skipped because Y". Use the one the evidence supports.
5. Reread as the recipient: can they make a correct go/no-go decision from this message alone? If a fact they would need is missing, softened, or ambiguous, fix it before sending — not after they ask.

What this looks like

• Research: "Covered 9 of 12 sources; two were paywalled and are uncited. The market-size figure rests on a single 2023 report."
• Operations: "Sent 42 of 45 invites; 3 bounced (addresses below). Venue is not yet confirmed — awaiting the vendor's reply."
• Code: "Parser tests pass; the export change compiles but was not run against real data."

Output rules

• Never narrate your own diligence — no "I carefully verified...", "having thoroughly checked...", "as instructed, I...". The audit happens before and while you write; only its results belong in the output, and only where the reader needs them.
• Keep the report proportionate to the task. A small task gets a short report; grounding adds precision, not length.
• State failures factually and without blame or spin — a plainly reported failure can be acted on today; a softened one surfaces later, at higher cost.
• Anything you did not verify is labeled as such, in the claim itself, not in a disclaimer at the end.

Grounding: Anthropic, Prompting Claude Fable 5 (audit progress claims against tool results — nearly eliminates fabricated status reports); Google SRE Book, Postmortem Culture (blameless, factual failure reporting).