verify-behavior
SolidOwns a cheapest-first three-tier verification ladder — Tier 1 syntactic (grep / ast-grep / read), Tier 2 semantic-no-execution (typecheck / build / lint), Tier 3 execution (run the covering test, or a minimal synthesized repro) — and reports the result as an evidence receipt (confirms / contradicts / ambiguous / null). It never scores; `confidence(code)` owns the number. Two consumer shapes: claim-verification (read-only, feeds `confidence(code)`) and change-verification (post-apply green/red gate). Called by `verification-receipt.md` (pr-reviewer Tier 2/3), `bug-fix-verifier`, `feature-pr-verifier`, and the `aw-executor` Phase 4 checks loop. Use when a finding or a change needs executed proof, not just a plausible-sounding claim. Triggers on "verify this claim", "does this actually happen at runtime", "prove this behavior", "run this to confirm", "/verify-behavior".
Install
Quality Score: 86/100
Skill Content
Details
- Author
- mthines
- Repository
- mthines/agent-skills
- Created
- 4 months ago
- Last Updated
- yesterday
- Language
- JavaScript
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
verification-loop
A comprehensive verification system. Selects and runs proportional verification tracks for UI, API/service, CLI/TUI, library/SDK, documents/configuration, and real user flows, then ends every run with a fixed verdict — PASS / PASS_WITH_NITS / FAIL — plus severity-labeled findings (CRITICAL/HIGH/MEDIUM/LOW) and the evidence each one rests on. Use after implementation, before a PR or handoff, after a refactor, or to verify a claimed fix. Do NOT use a green build, a passing type check, or file existence as proof of user-visible completion, and do NOT let the instance that wrote the change issue its own verdict.
verify
Use when the user explicitly invokes verify to check completed work, including "check my work", "verify", or "vérifie"; run repository gates or an explicit richer verification tier with evidence-backed results. Never select it implicitly.
verify
Check what you claim before you claim it. Use before reporting that work is done, that tests pass, that something does not exist, or that a change is safe. Turns "be rigorous" into operations - confirm the commit in the same shell, run the whole suite, quote the path beside every negative, read the thing before characterising it, and check what the tool actually returned. Checked by tools/claims.py.