prove-done
Skill0 starsChanged 39 days agoMITView on GitHub
Shows evidence that a branch meets its spec's success criteria and lists every spec change since approval. Use when a branch's work is finished and reviewed, before finishing the branch or opening a pull request; also when asked to prove a change is done.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- wo52616111/skillstheir own version, first seen Aug 23, 2026
- xiaogeli/claude-prove-donetheir own version, first seen Apr 27, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- wo52616111/skills★ 1same name
- xiaogeli/claude-prove-done★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarial-reviewSkill
- brainstormSkill
- execute-planSkill
- find-root-causeSkill
- finish-branchSkill
- handle-feedbackSkill
- tddSkill
- triage-open-itemsSkill
- update-specSkill
- write-planSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
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
- Very specific: line 12
When you find something worth doing later that this work does not include, add it as an item to .dietpowers/trackers/open-items.md, …
- Distinctive: line 14
Run the project's full test suite, linter and build fresh on the current state of the branch.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Prove Done
A claim that work is done is only as good as the command output behind it. This step turns the spec's success criteria into evidence your partner can check, and shows every change of direction made since the spec was approved.
Ask your partner one question at a time, in plain text; do not use the AskUserQuestion tool, because some clients show only the tool's question and drop the text around it. Put what your partner needs to answer in the same message: the problem and why it matters, then the options, recommended first, each with a short bold label in words (never numbers or letters) and a one-line reason. End with a line naming those labels in the same order, such as Reply with **new PR**, **straight to main**, or **drop it**., and make the question the last thing in the message, after any tool use. Your partner may answer with an option, their own alternative, a question or an aside. Keep messages short: lead with the decision, then only the detail needed to answer it. Before a stretch of work that takes more than a moment, such as dispatching a reviewer, writing a spec or plan, or fixing findings, say in one line what you are about to do; after your partner answers, say what comes next before starting it.
When you find something worth doing later that this work does not include, add it as an item to .dietpowers/trackers/open-items.md, following ## Open items in ${CLAUDE_PLUGIN_ROOT}/shared/trackers.md, and say so in one line.
- Run the project's full test suite, linter and build fresh on the current state of the branch. Read the whole output and the exit codes.
- List every change to the spec since it was approved, from its
Changednotes, and, when the plan'sSpec:line names a commit, check them againstgit log -p <commit>..HEAD -- <spec>andgit diff HEAD -- <spec>for edits without a note. - For each success criterion in the spec as it stands now, name the test or command that shows it holds, and its result. With no spec, use the requirements the review used, or ask your partner for them. Mark any criterion nothing demonstrates. Where the code and the spec disagree, never mark that criterion as passed: ask your partner which side should change, with your recommendation. To change the code, use the
dietpowers:tddskill, which commits the fix, and run step 1 again. To change the spec, invoke thedietpowers:update-specskill. - Report: pass or fail, the criteria with their evidence, the spec changes, and anything unmet. State only what the output shows.
Evidence for common claims:
| Claim | Evidence |
| Tests pass | Test command output showing 0 failures |
| Linter clean | Linter output showing 0 errors |
| Build succeeds | Build command exiting 0 |
| Bug fixed | The original symptom retested, now passing |
| Regression test works | Reverted the fix, watched the test fail, restored it |
| A subagent finished | The VCS diff, not the agent's report |
| Requirements met | Each spec success criterion paired with the test or command that shows it |
Terminal state: if the dietpowers:handle-feedback skill invoked you, return to it. Otherwise, if everything passed and every criterion is shown, invoke the dietpowers:finish-branch skill; if not, report what is unmet and stop.
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
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.