← ClaudeAtlas

app-verifylisted

Drive a running or deployed web app end-to-end as a real user to catch bugs that automated tests and typechecks miss: pages that return HTTP 200 but render wrong, forms that POST 200 yet never save, stat cards that are hardcoded fakes, reports fed by dead database columns, and silent data-layer failures (access rules hiding rows, swallowed query errors, wrong DB identity or connection) — for any framework and any datastore. Also verifies deployments against the live server: build gate, push, deploy, health check, commit match. Use whenever the user wants to verify prod, smoke test the app, QA the app, test every page or tab, check the app as a user, confirm a deploy shipped, ask if production is healthy, or sweep the whole app for what's broken — even if they never say the word "test", and right after any deploy. Do NOT use for: running an existing unit/integration test suite, fixing a typecheck or build error, scoring code quality (that's a "health" check), reviewing a PR diff, setting up CI, debugging one k
nikhilkyn-png/app-verify · ★ 0 · Code & Development · score 70
Install: claude install-skill nikhilkyn-png/app-verify
# App Verify Verify a running or deployed web app by operating it, not by reading its source. The highest-value bugs are the ones that pass the typechecker and return HTTP 200 but are still wrong: a form that saves nothing, a report built on a column no code writes, a stat card with a hardcoded number. Source review and unit tests routinely miss these. Driving the real app in a browser and checking the datastore underneath is how you find them. Two modes, often run together: - **Sweep** — go through every route/flow as a user, find what's broken or fake. - **Deploy-verify** — confirm a build/commit/deploy actually shipped and the live app is healthy. **Stack-agnostic.** The method is the same for any framework, language, and datastore. Concrete commands below use one stack (Next.js + Supabase/Postgres) as a worked example — translate each to yours: the route list comes from your router, the "database" is your authoritative store (SQL, NoSQL, an API), and the "direct read" is whatever client reaches it (psql, an ORM console, a Mongo shell, the provider's dashboard or API). Where you see a Postgres/Supabase term, read the principle, not the brand. ## Security & credentials This skill stores no secrets — it's instructions, nothing else. Two steps touch credentials, and both stay inside the operator's own machine: - **Session cookie** — the route sweep reuses the already-logged-in browser session by reading its cookie (`document.cookie`) to make authenticated `curl` reques