live-verify
Skill1 starsChanged 26 days agoMITView on GitHub
Verify a change by running it, not by assuming — full gate, fresh production-shaped build, then drive the affected flow end-to-end and observe real output. Use before committing nontrivial product changes, after wiring any integration, or whenever the question is "does it actually work?
2 other projects use a version of this.
Adopted by
Most recently taken up by
- TheurgicDuke771/DataQtheir own version, first seen Nov 8, 2026
- ffroliva/gflow-clitheir own version, first seen Sep 14, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- ffroliva/gflow-cli★ 367same name
- TheurgicDuke771/DataQ★ 0same 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 repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- checkpointSkill
- dep-checkSkill
- doc-auditSkill
- harness-auditSkill
- live-verifySkill
- project-adoptSkill
- project-auditSkill
- project-initSkill
- retroSkill
- tidySkill
- checkpointSkill
- dep-checkSkill
- doc-auditSkill
- harness-auditSkill
- project-adoptSkill
- project-auditSkill
- project-initSkill
- retroSkill
- tidySkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are 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.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
If the project has its own verify/run skill (many harnesses ship a built-in that bootstraps one per project), defer to it for the mechanics …
- Very specific: line 20
Run the adapter's gate commands in order (lint · type-check · build, or the project's equivalents).
- Distinctive: line 50
Check the project's memory for per-project recipes (ports, seeds, live-mode toggles, golden files) before re-deriving them.
≈ “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
live-verify
The gate proves the code compiles; only driving the change proves it works. Every nontrivial change gets observed doing its job in a production-shaped run before it's committed.
If the project has its own verify/run skill (many harnesses ship a built-in that
bootstraps one per project), defer to it for the mechanics and use this skill as
the checklist. Adapter: .claude/ai-dev-kit.config.json (gate, verify;
legacy prodVerify honored as the fallback); a missing field → derive it from
the repo and say so.
1. Run the full gate
Run the adapter's gate commands in order (lint · type-check · build, or the
project's equivalents). A green gate ≠ verified — it's the entry ticket.
2. Run the real artifact
Produce a fresh production-shaped artifact (verify.build) and run it
(verify.run), confirming readiness per verify.ready.kind (http · tcp-port ·
exit-code · log-line · file-exists · manual). Never repurpose or disturb a
standing dev process — dev modes mask production-only failures.
Domain mechanics live in references/ — read exactly one, keyed on the
adapter's projectType; absent, infer the type from the repo (manifests,
engine project files), state the inference, and use the closest fit:
- web-app / api-service → references/web.md
- game → references/game.md
- cli → references/cli.md
- library → references/library.md
- data → references/data.md
3. Drive the affected flow
Exercise the change the way its real consumer would — user, caller, player,
importer, downstream job — starting from the adapter's verify.observe entries
plus judgment about what this change touches. Observe the actual output
(response body, DB row, rendered frame, exit code + stdout, artifact content) —
reaching the code path proves routing, not behavior.
4. Cross-domain gotchas
- Check the project's memory for per-project recipes (ports, seeds, live-mode toggles, golden files) before re-deriving them.
- Killing a background process can orphan children and hold ports/locks — tree-kill by PID and confirm release before rebinding.
- Flaky verification has look-alike causes (env leaking from the shell, a stale artifact being run, keyed-vs-keyless modes) — rebuild clean with CI-shaped env before debugging the test itself.
5. Report what "verified" means
State what was driven and what was observed, with verbatim evidence (the status line, the row, the payload, the frame, the exit code) — never "should work". If a flow could not be driven (missing key, external dependency, no display), say so explicitly and list what remains unverified.
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.