verify-and-report
Skill1 starsChanged 2 days agoMITView on GitHub
Check finished work against the request and report the result honestly with evidence. Use this before saying any task is done, fixed, complete or working, and before any commit or pull request. Never claim success without running this.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
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 29
Use the commands from orient-in-codebase.
- Distinctive: line 35
Use the feature: If users touch it, run it for real.
- Distinctive: line 42
Review the diff once more: Check for debug code, secrets, unrelated changes and files you did not mean to include.
- Distinctive: line 45
Write the report: Use the template below. Include failures and skipped checks.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
Verify and report
"Done" is a claim, and it needs evidence. The most damaging habit in an agent is reporting success for something that was never run. An honest report of a partial result is far more useful than a confident wrong one.
When to use
At the end of every task that changed files or ran commands.
Steps
- Return to the request. Reread what the user asked for, and list each requirement. Mark each as done, partly done or not done.
Run checks from narrow to broad.
- The tests for this change
- The related test suite
- Lint and type checks
- Build
- The wider suite that CI runs
Use the commands from
orient-in-codebase. Do not assume a check passed because a similar one did.- Read the output. Exit code and summary both matter. Check that tests actually
ran:
0 testsor a filter that matched nothing is not a pass. - Use the feature. If users touch it, run it for real. Use a browser for UI, and call the endpoint for an API. A passing build does not show that a page works.
- Compare failures with your baseline. Anything that failed before your change is pre-existing, so report it as that. Anything new is yours. Do not call a failure unrelated without showing that it also fails without your change.
- Review the diff once more. Check for debug code, secrets, unrelated changes and files you did not mean to include.
- Write the report. Use the template below. Include failures and skipped checks.
Words to avoid
Replace these with something you observed.
| Instead of | Write |
| "Should work" | "Ran X, result Y" |
| "Fixed" with no evidence | "The test failed before, and passes now" |
| "All tests pass" after a partial run | "Ran 14 tests in auth/, all pass; full suite not run" |
| "Probably unrelated" | "Also fails on the base branch" |
| "I've verified" with no command | Name the command and result |
Stop and ask when
- A requirement cannot be met as written.
- A check fails and you cannot find out why after three attempts. Report it as failing. Do not hide it.
Common mistakes
| Tempting move | Why it fails | Do this instead |
| Report before running anything | The claim has no basis | Run the checks |
| Leave out a failure | The reader trusts a false result | Report it plainly |
| Skip a slow suite silently | The reader assumes it ran | Say you skipped it |
| Summarize output from memory | Details get invented | Quote the real result |
| List every step you took | Hides the result | Lead with the outcome |
Report
Result: <done / partly done / blocked>
Requested:
- [x] <requirement>
- [ ] <requirement>: <why not>
Ran:
- `<command>`: <result, with counts>
Checked by hand: <what you tried in the real feature, or "not done">
Pre-existing failures: <list, or none>
Not checked: <list, or none>
Risks: <anything the reader should know>Other versions2 projects use a version of this.
Word for word · 2
- Remote-Arc/remote-arc★ 5100% same
- yaohuangguan/remote-arc★ 5100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
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 repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- audit-test-suiteSkill
- change-data-safelySkill
- debug-failureSkill
- fix-flaky-testSkill
- hand-off-workSkill
- implement-changeSkill
- orient-in-codebaseSkill
- refactor-safelySkill
- review-codeSkill
- secure-changeSkill
- use-external-apiSkill
- write-pull-requestSkill
- write-testsSkill
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.