agentkitcoagentkitco/agentkit-dev-skills/skills/prove-it-ran/SKILL.md

prove-it-ran

Skill0 starsChanged 14 days agoMITView on GitHub

Verify that tests, builds and checks actually ran and exercised the changed code, before claiming a task is done. Use before reporting completion, or when asked to prove tests ran or verify a fix.

In this repository12 other files it gives its agents.
- agents-md-auditSkill
- brag-doc-from-gitSkill
- dependency-upgradeSkill
- explain-codebaseSkill
- pr-descriptionSkill
- repro-first-debuggingSkill
- review-my-diffSkill
- safe-refactorSkill
- security-quick-reviewSkill
- session-handoffSkill
- write-agents-mdSkill
- write-subagentSkill

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Test runners: the output shows a test count above zero, and the new or changed tests appear by name or file.
line 19
Very specific:
Check the exit code, not just the wording (echo $?
line 20
Distinctive:
Make sure the runner picked up your files: right directory, right config, test file matches the naming pattern.
line 21
Very specific:
Check for silent skips: Search output for skipped, xfail, pending, todo, and your own .only/.skip/pytest.mark.skip leftovers (rg …
line 23
Distinctive:
Never edit a test, snapshot or threshold only to turn a check green.
line 40
Distinctive:
If something cannot be run here (needs credentials, a device, production), list it under "Not verified" with how the user can check.
line 42

≈ “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.

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

Files

SKILL.md

Prove it ran

Goal: never say "done" or "tests pass" on the strength of belief. Show evidence that the checks ran, covered the change, and would have caught a failure.

Procedure

List the claims you are about to make ("the bug is fixed", "all tests pass", "the build succeeds", "no lint errors").
For each claim, run the command now, from a clean state of your edits, and capture the output. Do not rely on output from earlier in the session if you edited files since.
Confirm the check really ran:
- Test runners: the output shows a test count above zero, and the new or changed tests appear by name or file. "0 tests", "no tests found" or "skipped" is not a pass.
- Check the exit code, not just the wording (echo $? right after the command, or the runner's summary line).
- Make sure the runner picked up your files: right directory, right config, test file matches the naming pattern.
Confirm it covers the change. For a bug fix, the test must fail without the fix: temporarily revert the fix (git stash the source change only, or comment it out), run the test, see it fail, restore, see it pass. If you cannot do this, say so.
Check for silent skips. Search output for skipped, xfail, pending, todo, and your own .only/.skip/pytest.mark.skip leftovers (rg "\.only\(|\.skip\(|xit\(|fdescribe|pytest.mark.skip").
Run the wider checks the project defines (lint, type check, build). Report exact commands.
Report in a table and be explicit about anything you did not or could not run.

Report

| Claim | Command | Evidence (count / exit code / key line) | Verified |
|---|---|---|---|
| Fix works | <cmd> | 1 failing before, passes after | yes |
| Suite passes | <cmd> | 212 passed, 0 failed, exit 0 | yes |
| Lint clean | <cmd> | not run: no lint script | no |

Rules

"Should work" and "looks right" are not evidence. Replace them with a command and its output or say you did not verify.
Never edit a test, snapshot or threshold only to turn a check green. If a test is wrong, say why and ask.
Report failures in full, including ones that look unrelated. Mark pre-existing failures as such only if you confirmed them on a clean checkout.
If something cannot be run here (needs credentials, a device, production), list it under "Not verified" with how the user can check.

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.

Check your setup, free