How to Know an AI's Work Is Right When There Is No Test: A Done-Means-Checkable Skill for Claude

When you hand an AI assistant an analysis, a summary, a plan, or a design, there is usually no test suite to tell you whether the result is right. The assistant finishes and says it checked its work, which means the model graded itself. The Done Means Checkable skill changes the order: it writes down what "right" means before the work starts, runs the best judge that is not the model, and reports what it could not verify.

What does the skill do?

It makes the assistant do three things in order. First, write acceptance criteria that a stranger could mark pass or fail. Second, run an outside judge and paste its output unedited. Third, end with a report that separates what was checked from what was not. On any run with a gate ("show me before you change anything"), it also keeps a record of what it decided apart from what it did.

When does it run, and when does it stay out of the way?

It runs only on a trigger. Everything else is done as asked, with no extra section.

Request	What the skill does
"Is this summary right?"	Runs. You asked whether a result is right.
"Summarize these contracts for the board, and make sure it's right."	Runs. A person will act on it and no test exists.
A result it produced failed a check and it is about to claim a pass	Runs. This is the case it exists to stop.
"Run the tests."	Bypassed silently. You named a runnable check.
"Rename tmp to retry_count."	Bypassed silently. A single-step edit.
"Just fix the typo in README.md."	Bypassed, with one line: Check: bypassed (ceiling). "Just" is a ceiling you set.

If a request meets a trigger and a bypass condition, an explicit request to verify wins. A deliverable-type noun such as "report" does not.

What counts as an acceptance criterion?

A statement a stranger could mark pass or fail without asking what you meant. "Covers the main risks" is not checkable. "Names at least the three risks in the attached incident log, each with the log line that shows it" is. The skill writes three to seven, derives them from your own words and files first, and labels any it proposes itself as proposed. Each criterion is tagged with how it will be checked: run (a command or query), held-out (a case the work was not fitted on), review (a fresh-context reviewer), or user (you answer specific questions). One that fits none is written as unverifiable and carried into the report, not dropped.

After the work starts, a criterion can change only if the change and the reason are logged. The skill may not loosen a criterion because the result failed it.

How does it pick the judge?

It picks a judge per criterion before the work, because a judge chosen after seeing the result tends to fit the result. The order is an executable check, then a held-out case, then a fresh-context reviewer, then you with exact questions. A held-out case has to be a real second case, not a rerun of the same input. A fresh-context reviewer costs time and tokens, so it is used only if you agree after seeing the cost. If no outside judge exists, the verdict is labeled UNVERIFIED: no external judge available.

What is the decision-versus-action record?

On a run with a gate, the skill records two fields. Decision is what it concluded and why. Action is what it actually did, in order. If the decision said wait and the action wrote a file, the mismatch goes at the top of the report. A carefully written gate that gets acted past is a failure even when the output looks good.

What has been tested?

Fresh-agent dry runs, with pass conditions written before each run and the action judged from git status and git diff in each test folder, not from what the agent said.

• First version, 9 cases. Decision: 7 pass, 1 not met, 1 untested. Action: 8 pass, 1 not observed. Two real findings. Asked "is this summary right?", it opened with the answer and listed its criteria afterwards. And with the Ambition Calibrator also installed, that skill's required Ambition check: bypassed line went missing.
• Control run. The same four cases with no skill at all. The plain model reached the same correct answers (a column that sums to 360 against a summary that says 380; a CSV that sums to $1.2M against a stated $1.4M) and respected the "do not change anything yet" gate. The skill does not make the model more correct on easy cases. What it adds is the trail: written criteria, pasted judge output, an Unverified list, and a decision/action record.
• After the fixes, final version. With both skills installed, the Ambition check: line was printed in 3 of 3 fresh runs (it was missing in 2 of 3 before), criteria came before the verdict in 3 of 3, and the judge output was shown in 3 of 3. "Run the tests" and the typo fix behaved as before.

Limits: one model, small numbers, and the pass conditions were written by the skill's author. The final version was not re-run on the rename, board-summary, or review-before-changing cases, and the case with Ambition Calibrator's confirmation gate is untested. It has not been measured whether work done this way is better than work done without it.

How do I install it?

1. Download done-means-checkable.md.
2. Save it as .claude/skills/done-means-checkable/SKILL.md in your project, or in ~/.claude/skills/done-means-checkable/SKILL.md to use it everywhere.
3. Ask Claude "is this right?" about an analysis or a summary. It loads from the skill's description.

The skill is a set of instructions Claude follows, with no backend call and no account. It is also in the GitHub repository with the other skills.

FAQ

Is this the same as asking the model to double-check its work?

No. A model re-reading its own answer is still the model grading itself. The skill requires a judge that is something else: a command, a query, a held-out case, a reviewer with fresh context, or you.

Does it work with models other than Claude?

The file is plain instructions, so any agent that loads skill-style files can follow it. The dry runs used Claude.

Why does it so often do nothing?

Writing criteria and running a judge costs time and attention. A rename or a test run does not benefit from it, so those are bypassed silently.

What if there is no way to run a check?

It says so. The result is labeled UNVERIFIED and you get the exact questions a human reviewer should answer.

Related: Ambition Calibrator decides how deep a task should go, and this skill decides how you will know the result is right. Empirical Diagnostician covers evidence-first debugging.