agentleFS
Sign inStart free
T0mSIlverT0mSIlver/skills/verify/SKILL.md

verify

Skill1 starsChanged 33 days agoMITView on GitHub

The verifier: a second agent, not the author, checks a PR before merge. Reads the diff, issue, intent card, spec and the PR's blast radius; runs or reads the evidence; looks at every screenshot and video itself; compares against peers on the same screen, and against main for a bug fix; does a refuter pass; and returns VERIFIED, NOT VERIFIED or INCONCLUSIVE with its scope, recorded for the ramp-up tally. Also how to write a repo's verify-<app> skill. Use when asked to verify a PR or change, before one merges, and when a repo has no scripted way to drive its app.

188 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use instinct-export, instinct-import and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • AviadPSkill

    risk-assess

    Assess the risk and blast radius of a proposed code change before implementing it. Evaluates CI impact, framework-wide vs localized scope, rollback path, and identifies blindspots. Use when user says "what's the risk", "is this safe", "assess the impact", "risk assess", "blast radius", or before applying framework-wide or CI-affecting changes. Do NOT use for code quality review (use code-quality) or plan validation (use design-validator).

    Also in 3 projects that use this

  • diego-tobalinaSkill

    build-fix

    Fix build and compilation errors systematically. Run when build fails.

    Also in 6 projects that use this

  • AaravChadhaSkill

    secure

    Security review with a confidence gate - a finding exists only with a concrete exploit scenario and a high/medium/low confidence rating; everything else goes to a worth-hardening list, never inflated. Sweeps five surfaces: auth gates, secrets hygiene, injection and unsafe sinks, unsafe deserialization/crypto/transport, and LLM tool-use trust boundaries. Reports only, never fixes. Use when the user asks for a security review or to check vulnerabilities, secrets, or auth.

    Also in 3 projects that use this

  • ArvorCoSkill

    specify

    Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec.

    Also in 10 projects that use this

  • +1 more from TheKREATORS

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 167 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. Very specific:

    Gather the evidence, risk by risk: Read what CI already proved: the screenshot diff and the e2e run, on a run whose head SHA is the PR's …

    line 22
  2. Distinctive:

    VERIFIED: every risk in scope has evidence that would have caught it, and you looked at it.

    line 66
  3. Distinctive:

    Run it end to end once before committing it: a verify skill that never ran is a draft.

    line 77
  4. Distinctive:

    The wrong build looks right: Check the version or build id on screen or in the doctor output before judging what it shows.

    line 83
  5. Distinctive:

    Findings go to the PR,: not to the owner. A card only for a deviation from intent, or for UX proof during the ramp-up.

    line 87

“Common” is measured: kept by at least 6 in 10 of the 167 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

You didn't write the change, and you don't read the author's transcript: the PR is what ships, so the PR is what you judge. You report; the author fixes.

Happy path

  1. Read the inputs. gh pr view <n> and gh pr diff <n>, the issue, the intent card's answer or the spec it cites, and the PR's Blast radius section. No blast radius: stop at NOT VERIFIED, since the author owes it.
  2. Check the blast radius. List every surface the diff reaches. Each one the section misses is a finding, and you prove it like the rest.
  3. Check the intent. Anything the card or spec didn't ask for (a page, setting, option, abstraction) is a finding. A deviation from the owner's answer goes to the owner on a card (intent-card), never into a merge.
  4. Gather the evidence, risk by risk. Read what CI already proved: the screenshot diff and the e2e run, on a run whose head SHA is the PR's head. Drive the real app only for risks the suite doesn't cover, through the repo's verify-<app> skill. Exercise each feature the way its users do, with fake users when it involves more than one person or device.
  5. Look at every image and video at full size before judging: open each file, and pull frames from a video at its key moments. Write what each shows and whether it looks right against the charter's "looks off" list.
  6. Compare with peers on the same screen: the icon against the icons beside it at the same size, the row against the rows above and below, the same screen on the other platforms. Where the eye is unsure, measure (bounding-box centres, text width against its box).
  7. Bug fix: baseline on main. Reproduce the bug on main with the same steps, then show it gone on the PR head.
  8. Edge cases. Those in the issue, plus the ones the risks call for: empty and very long content, another locale, dark theme, small screen and large font, offline, first run and upgrade from the last release.
  9. Refuter pass. Argue against your own verdict before posting it. VERIFIED: what would make this evidence not cover the claim? A stale build, an artifact from an older head, a test that passes on main too, one platform standing in for another. NOT VERIFIED: does the finding reproduce, on a concrete path, and is it the app and not the harness?
  10. Post the verdict as one PR comment (gh pr comment):
## Verification: VERIFIED | NOT VERIFIED | INCONCLUSIVE

**Scope:** <platforms, features and risks this covers, at head <sha>>
**Not covered:** <what, and why>

| Risk | Evidence | Got to | Looks right? |
|---|---|---|---|
| <from the blast radius> | <run link, image, file:line> | ran it | yes: <what it shows> |

**Findings:** <each with file:line or image, and how to reproduce>
Tally: kind=<kind> verdict=<verdict> head=<sha>

One Tally: line per kind of risk the PR carries, using the blast radius's kinds. During the ramp-up the owner's verdict goes beside it, and the matches are counted.

Verdicts

  • VERIFIED: every risk in scope has evidence that would have caught it, and you looked at it.
  • NOT VERIFIED: a finding reproduces, or the author's proof is missing.
  • INCONCLUSIVE: the evidence couldn't be produced (no device, flaky run). Say what would settle it. Never round it up.

Writing a repo's verify-<app> skill

Each repo keeps .claude/skills/verify-<app>/ saying how to launch, check, drive and prove its app, with one feature file per user-facing feature. reference/verify-app-skill.md has the shape. Run it end to end once before committing it: a verify skill that never ran is a draft.

Gotchas

  • A thumbnail hides a 4 px offset. Crop to the element and its peers.
  • The wrong build looks right. Check the version or build id on screen or in the doctor output before judging what it shows.
  • Emulators and simulators differ from devices in icon masks, fonts and notch insets. Name what you ran on in the scope.
  • Findings go to the PR, not to the owner. A card only for a deviation from intent, or for UX proof during the ramp-up.
  • A finding with no concrete path ("what if…") is dismissed, not reported. Trace the caller first.

Not possible

  • Proving a visual change by reading code: it needs a render.
  • Hardware the box doesn't have: INCONCLUSIVE, with that gap in the scope.

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