verifykit
verifykit
Drive a just-built frontend feature the way a user would and capture what happens. In show mode the capture is a screenshot handed to the operator in the session, cheap enough to answer "did the button move". In proof mode it is screenshots plus one short animated GIF, published so a pull request can embed them inline. setup readies a machine and a repo for both. verifykit is the step between reviewing the code and opening the PR: reviewing reads the source, this exercises the running feature.
It is a driver and recorder, nothing more. It does not write tests (that's a test-suite skill, testkit when it's installed), does not produce a human checklist (that's a manual-QA skill), and does not provision environments beyond its own driver. It drives the UI it's given and records what it sees.
When this fires
After a frontend feature is built and you want to look at it or prove it works. It captures a running feature with a visual surface. If the change is backend/CLI-only with nothing to drive, say so without inventing a flow, and route to qakit for a manual test plan (/qakit); without qakit, name the commands and endpoints a person should exercise by hand.
show. "Show me what it looks like", "screenshot this", "what does the page look like now", "did the button move". Screenshots to a local path, nothing published.proof. "Verify this feature", "record the flow working", "prove the UI change", "capture proof for the PR", or a PR step that needs proof artifacts. Screenshots plus a GIF, bundled and published for the PR body.setup. "Set up verifykit", "install the browser driver", "get this machine ready to capture". Installs what is missing and reports what is present.
When the verb is ambiguous, run show. An invocation that names a PR, proof, a record, or proving is proof. Everything else is show, because it is cheap and reversible, and escalating to proof costs one sentence.
Distinct from a manual-QA plan (which a human runs) and from a code review (which reads source). verifykit is the automated drive-and-record; if the user actually wants a hand-test checklist or a source review, point them at the right skill instead of capturing.