verify-before-claim

Spawns a fresh adversarial verifier subagent to prove code changes work with live evidence.

Updated Aug 1, 2026
One-click install
npx skills add https://github.com/dxiiren/project-skeleton --skill verify-before-claim-dxiiren
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify-before-claim
Source: https://github.com/dxiiren/project-skeleton/tree/main/.claude/skills/verify-before-claim
Command: npx skills add https://github.com/dxiiren/project-skeleton --skill verify-before-claim-dxiiren

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI assistants routinely claim a change is done, fixed, or working based on their own assumptions, a green build, or a passing lint run — and defects ship. This Skill forces an independent verification step before any such claim is made, so unverified work never gets reported as finished. ## Core Features & Use Cases - Fresh adversarial verifier subagent: Spawns a verifier with zero knowledge of what was changed or why, receiving only the verbatim requirement and the changed-file list from git status / git diff. - Live-evidence bar: Requires real HTTP calls, real browser runs via Playwright tools, real data queries, and host commands — mocked unit tests and passing builds are automatic FAILs. - Four named failure-mode sweep: Explicitly checks partial coverage, over-application, deployment-present-vs-behaviour-verified, and happy-path-only testing, each reported as PASS, FAIL, or UNVERIFIED. - Use Case: After fixing a login bug, instead of telling the developer "fixed", the assistant hands the original requirement and changed files to a fresh verifier that starts the app, drives the real login flow in a browser, probes edge cases, and returns a numbered evidence log. ## Quick Start Before claiming a change is done, ask the assistant to verify this change with a fresh adversarial verifier using only the requirement and the changed-file list.

Frequently Asked Questions about verify-before-claim

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a code change actually works before claiming it is done?

Spawn a fresh verifier subagent that receives only the original requirement and the changed-file list from git status and git diff. It must prove the change with live evidence — real HTTP calls, browser runs, and data queries — and return a numbered evidence log with a PASS, FAIL, or PARTIAL verdict.

Why should verification run in a fresh subagent instead of the same context?

Verifying inside your own context inherits your assumptions about what you changed and why, which defeats independent verification. A fresh subagent receives only the requirement and file list, so it probes the actual system rather than reviewing your story.

What evidence counts as proof that a change works?

Only live evidence counts: real HTTP calls, real browser runs via Playwright tools, real data store queries, and host commands. Mocked unit tests alone are an automatic FAIL, and a passing build, clean lint, or deployed file is not behaviour.

What failure modes does adversarial verification check for?

It sweeps four named modes: partial coverage (missed call paths), over-application (boundary values mishandled), deployment-present read as behaviour-verified, and happy-path-only testing. Each must be explicitly reported as PASS, FAIL, or UNVERIFIED.

When can verification be skipped before claiming done?

Skip only when nothing was exercised at all, such as a docs-only edit with no behaviour touched, and state plainly that you skipped it and why. Small changes, green builds, and obviously correct diffs are not valid reasons to skip.

What happens when the verifier returns FAIL or PARTIAL?

Fix the root cause and re-run the protocol from scratch with a new verifier. Do not argue the finding away, re-prompt the same verifier for a softer read, or report done with a caveat while any UNVERIFIED line stands.