verifykitlisted

# verifykit Drive a just-built frontend feature the way a user would, capture what happens — screenshots at each meaningful state plus one short animated GIF of the flow — and publish that proof so a pull request can embed it inline. verifykit is the step between reviewing the code and opening the PR: reviewing reads the source, this **exercises the running feature** and produces visual evidence it works. It is a **driver and recorder, nothing more**. It does not write tests (that's a test-suite skill), does not produce a human checklist (that's a manual-QA skill), and does not provision environments — it drives the UI it's given and records what it sees. ## When this fires After a frontend feature is built and you want proof it works before the PR: "verify this", "capture the feature working", "record the flow", "prove the UI change", "/verifykit", or a PR step that needs proof artifacts. It captures a running feature with a visual surface — if the change is backend/CLI-only with nothing to drive, say so and stop rather than inventing a flow. 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. ## Procedure ### 1. Scope the feature and find the entry point Ground the run in what actually changed — read `git diff` (and the linked issue/plan when there is one