verify-pr
Skill0 starsChanged 9 days agoMITView on GitHub
Use when the user asks to verify, test or QA a pull request before the merge, and at the proof step of full-stop. An independent tester runs the app at the head of the PR, tries to break each changed behavior and its callers, runs each fault again on the base, and reports each regression with steps to reproduce. It changes no test and no product code.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- krishhgg/t3termtheir own version, first seen Nov 1, 2026
- warpdotdev/oz-for-osstheir own version, first seen Oct 8, 2026
- Azure/LogicAppsUXtheir own version, first seen Jul 1, 2026
- tomimor/skillstheir own version, first seen Jun 26, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- warpdotdev/oz-for-oss★ 313same name
- Azure/LogicAppsUX★ 114same name
- krishhgg/t3term★ 11same name
- tomimor/skills★ 2same 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 repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- rules/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- babysit-prSkill
- beast-uiSkill
- cleanupSkill
- councilSkill
- doc-viewSkill
- featuremapSkill
- file-prSkill
- frontend-designSkill
- full-sendSkill
- full-stopSkill
- impeccableSkill
- leaving-pr-commentsSkill
- modernizeSkill
- no-commentsSkill
- patrolSkill
- sol-loopSkill
- statechartSkill
- technical-writingSkill
- tldrSkill
- untangleSkill
- whySkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 4 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Start the tester as a subagent or a delegate.
- Very specific: line 30
Read the PR: the title, the description, the linked issue and git diff <base>...<head>.
- Distinctive: line 36
Add the user flows that pass through the changed code, and one smoke flow: start the app, open the main page or run the main command, and …
- Very specific: line 38
When the repo has a featuremap.json, the featuremap skill can list the features that use the changed files.
- Distinctive: line 43
Use the commands of the repo first.
- Very specific: line 60
Run each fault again on the base, with the same steps, data and settings.
- Distinctive: line 69
When the PR says that it wants a new result, such as a stricter limit, that result is intended, not a regression.
- Very specific: line 76
Stop when each changed behavior has a result.
- Very specific: line 83
Start with the verdict: regressions found, pass or incomplete.
“Common” is measured: kept by at least 6 in 10 of the 4 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.
Files
Verify PR
The tester did not write the change. It uses the app as a user would, tries to break it, and gives the author steps to reproduce each fault. Green unit tests are not proof that the app works.
Tester
- Start the tester as a subagent or a delegate. When the harness lets you pick the model, use a model of another family than the author. For example, use a GPT tester for a change that Claude wrote.
- In the report, name the model that the tester ran on, as the harness reports it after the run. A model that you only asked for is not proof. When the harness does not confirm the model, say that you do not know it. When you cannot start a tester, do the work yourself, and say that the tester was not independent.
- The tester changes no file that git tracks: no test, no product code, no config. It keeps notes, logs and screenshots in a temporary folder outside the repo.
- Give the tester the PR, the base and head commits, the commands of the repo, and this skill. Do not give it your opinion of the change.
Scope
- Read the PR: the title, the description, the linked issue and
git diff <base>...<head>. Record the head commit. - List each behavior that the diff changes: a function, a route, a page, a command, a job, a config key or a message format.
- Find the callers of each changed behavior. Search the code for each changed name.
- Add the user flows that pass through the changed code, and one smoke flow:
start the app, open the main page or run the main command, and do one write.
When the repo has a
featuremap.json, thefeaturemapskill can list the features that use the changed files.
Run
- Use the commands of the repo first. Read
AGENTS.md, the README, the package scripts and the Makefile for the commands that start the app, wait until it is ready, drive it, collect evidence and clean up. - For a web interface, drive a real browser with Playwright or the browser tool of the harness. Collect the console errors, the failed requests, the server log and a screenshot or a trace of each fault.
- For a command line tool, an API or a library, run the real command or send real requests with real input.
For each changed behavior, try the normal path first. Then try the ways that break code: empty, very large and invalid input, a repeated submit, cancel, retry, refresh, back and forward. Also try a slow or failed dependency, and a user with fewer permissions. Look at the pages and commands next to the change too.
Compare with the base
Run each fault again on the base, with the same steps, data and settings. See
references/blame.md for the commands.
| Head | Base | Result |
| Fails | Passes | Regression. It blocks the PR. |
| Fails | Fails | Existing fault. Report it apart. It blocks only when the PR copies it or makes it easier to reach. |
| Fails for a reason outside the code | Not run | Environment fault. Fix the environment, or report the check as not done. |
When the PR says that it wants a new result, such as a stricter limit, that result is intended, not a regression. Then test the inputs next to the stated change, which the PR does not name. They show if the change does more than it says.
Stop
Stop when each changed behavior has a result. Also stop after 3 rounds of fix
and run again, or after 30 minutes. A limit gives incomplete, never pass.
A new push makes the result old. Run again on the new head.
Report
Start with the verdict: regressions found, pass or incomplete. Then give:
- The PR, the base commit, the head commit and the tester model.
- For each regression: the steps to reproduce, the expected result, the actual result, the evidence (log lines, a screenshot path) and the result on the base.
- Each existing fault and each environment fault, apart from the regressions.
- What you tested, and what you did not test, with the reason.
The author fixes each regression. Then the tester runs again on the new head.
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.