# Preview And Prove

> Use when the user wants a real local or UI proof — launch local, relaunch, run local, "do not deploy / run local", QA via playwright, e2e in browser/app, tunnel for test mode, "did you verify/check it works" on a visible flow, preview, or responsive QA. Prefer this over deploy-and-prove when they say run local or do not deploy. Especially checkout, authentication, onboarding, forms, extensions, or responsive behavior.

- Skill: `yosefhayim/preview-and-prove` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yosefhayim/preview-and-prove`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yosefhayim/preview-and-prove/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: YosefHayim (https://skillmd.com/u/yosefhayim)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yosefhayim/preview-and-prove

---


# Preview and Prove

Validate the product through the surface the user actually sees. Source inspection and automated tests support the claim; they do not replace a real browser-visible run.

## Safety

- Read the repository's run, test-data, and environment instructions before starting services.
- Use local, sandbox, preview, or explicitly authorized test accounts and payment methods. Never create a production charge, send a real campaign, or mutate customer data to prove a flow.
- Do not expose credentials, cookies, tokens, personal data, or private screenshots in logs or the final report.
- Ask only when a required credential, irreversible action, or product choice cannot be discovered safely. If a surface is unavailable, report it as unverified.

## Workflow

1. Define the exact route, actor, viewport, preconditions, success state, and side effects to verify. For checkout, authentication, onboarding, and other stateful funnels, include at least one safe failure-and-recovery path.
2. Inspect repository instructions and start the real application plus required local dependencies. Record the URL, build identity, seed/test account, and relevant feature flags without revealing secrets.
3. Open the app in a real browser. Reproduce the flow through visible controls rather than bypassing it with direct API calls.
4. Observe the page, accessibility tree, console, failed requests, redirects, cookies/storage, and network responses relevant to the flow.
5. Verify the durable outcome behind the confirmation UI: persisted record, sandbox provider state, session transition, delivered local event, or other authoritative readback.
6. Test representative desktop and mobile viewports when layout matters. Capture before/after screenshots for fixes and freeze animation or nondeterministic data when comparison matters.
7. Fix only after reproducing the problem. Re-run the complete flow from a clean state, then run the repository's relevant automated checks.

For extensions, verify the unpacked extension in a headed browser and its actual host permissions/content-script behavior. For OAuth or payments, include redirect and callback/webhook state, not only the final page.

## Verification

Report:

- exact route, actor, viewport, environment, and build or commit identity;
- steps performed and the observed visible result;
- console/network errors, including “none observed” only when inspected;
- authoritative persisted or provider-side readback;
- screenshot or artifact paths when safe to retain;
- automated checks and any surface that remained inaccessible.

Do not say “works in the UI” if only source, unit tests, an API, or a mocked component was exercised.