verifykitlisted

# 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 and stop rather than inventing a flow. - **`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