Grounded reporting
Skill kalshamsi/fable-discipline-skills/skills/grounded-reporting
11 evidence-backed process-discipline skills for Claude Code — Fable 5 working disciplines transplanted onto Opus, blind A/B validated
npx -y skills add kalshamsi/fable-discipline-skills --skill grounded-reportingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.3 KB, as published. Nobody here has run it
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
- Before drafting, list the claims you are about to make — every "done", "sent", "fixed", "verified", "covered".
- 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.
- 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.
- 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.
- 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).