agentleFS
MPIsaac-PerMPIsaac-Per/claude-code-loop-patterns/skills/verify-before-done/SKILL.md

verify-before-done

Skill2 starsChanged 4 months agoMITView on GitHub

Forces evidence-backed completion. Refuses to mark a task done without a test pass, typecheck, lint, or verification script run, even when the change feels small.

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before claiming completion, you must answer all of these questions with concrete evidence:

    line 16
  2. Distinctive:

    Run the project's verification harness if one exists:

    line 26
  3. Very specific:

    If the project has no harness, run the closest analog (a single pytest, pnpm test, cargo test, or whatever is canonical) and capture the …

    line 40
  4. Distinctive:

    Do not write "done" or "all tests pass" without showing the evidence.

    line 44
  5. Distinctive:

    If any gate failed or you skipped a check, say so explicitly.

    line 52

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Verify Before Done

You are about to declare a task complete. Stop. The article's core failure mode is plausible completion: you do 80% of the work, narrate the rest convincingly, and stop. Evidence is the only thing that prevents this.

The rule

"Done" must be tied to evidence, not tone or confidence.

Before claiming completion, you must answer all of these questions with concrete evidence:

  1. What changed? Specific file paths and line numbers.
  2. What command verified it? Exact command, exit code, relevant output.
  3. What failed? Anything you tried that did not work, even briefly.
  4. What remains untested? Be honest, do not paper over.
  5. What assumption is still open? Any unverified hypothesis.

How to gather evidence

Run the project's verification harness if one exists:

./scripts/verify.sh

Or run gates individually:

typecheck
lint
test

If the project has no harness, run the closest analog (a single pytest, pnpm test, cargo test, or whatever is canonical) and capture the result.

Format for the completion claim

Do not write "done" or "all tests pass" without showing the evidence. Bad:

All done, tests pass.

Good:

Completed. Evidence: ran pnpm test, 47 passed in 8.2s. Typecheck clean. Lint clean. File changes: src/foo.ts:42-58 (new function), src/bar.ts:103 (call site updated). Untested: error path when the upstream API returns 500, since I could not reproduce it locally.

If any gate failed or you skipped a check, say so explicitly. Do not declare completion.

When to invoke

Trigger this skill whenever:

  • You are about to mark a task complete or write a closing summary
  • You are about to remove the final TODO from a list
  • You are about to say "this should work" or "I think we are done"
  • A user asks "is it done?" or "did it work?"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.