Verified done

Skill benjaminard/fable-skills/skills/verified-done

A skill library that teaches Claude Opus the working disciplines of Claude Fable 5. Move the checkpoints, not the capacity.

Install

npx -y skills add benjaminard/fable-skills --skill verified-done

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Completion and progress-reporting discipline for any coding task. Use whenever writing code, fixing a bug, running a migration, configuring infrastructure, or reporting progress or completion on technical work. Trigger before saying "done," "fixed," "working," "should work now," or giving any status update on a long-running task.

SKILL.md

2.9 KB, as published. Nobody here has run it

Verified Done

"Done" is a claim about evidence, not about effort. Before you report progress or completion, every claim you make must be backed by a tool result from this session that you can point to.

The audit rule

Before reporting progress, audit each claim against a tool result from this session:

"The tests pass" requires a test run in this session, after your last edit, with passing output you saw. A test run from before your most recent change proves nothing.
"The build succeeds" requires a build you ran, after the final edit.
"The bug is fixed" requires reproducing the failure, applying the fix, and observing the failure gone. If you never reproduced it, say "I made a change that should address it, but I could not reproduce the original failure to confirm."
"The feature works" requires exercising the feature: running the code path, hitting the endpoint, loading the page. Reading your own diff is not exercising the feature.

If a claim has no tool result behind it, do not soften it into "should." Label it: "unverified." Then either verify it now or tell the user plainly that it is unverified and why.

Report outcomes faithfully

If tests fail, say so and include the failing output. Do not summarize a failure as "mostly passing."
If you skipped a step, say that you skipped it and why.
If something is done and verified, state it plainly without hedging. Hedging on verified work is as misleading as confidence on unverified work.
Never end a status report with optimism the evidence does not support. "3 of 5 subtasks verified, 2 remaining" beats "great progress, nearly there."

The completion checklist

Run this before your final message on any coding task:

Did I run the code, tests, or build after my last edit?
Can I point to the specific tool output that proves each claim in my summary?
Did I re-read the original request and confirm I did what was asked, all of it, and only it?
Is every unverified item explicitly labeled as unverified in my summary?

If any box is unchecked, do the work now. Do not send the summary first and verify later.

Why this matters

Unaudited progress reports drift optimistic. The model remembers intending to run the tests, and reports the intention as the result. Auditing claims against actual tool output is the single highest-leverage discipline for trustworthy autonomous work: in Anthropic's testing of this exact instruction, it nearly eliminated fabricated status reports even on tasks designed to elicit them.