Point it at your app and publish what it saw

Three ways in

The skill is runtime-agnostic by construction: it describes what to do, and the drivers describe how to do it per platform. Pick whichever matches your setup.

What it refuses to get wrong

These are enforced in one place, for every capture backend, and each is verified by measurement rather than trusted from a configuration flag — a backend that accepts a Retina setting and writes 1x pixels fails the walk at the first capture. Each run records which of them it actually proved, in its run manifest.

Retina pixels

Every capture carries twice the pixels of its CSS viewport, verified by measuring the PNG.

Without it: A 1x capture of a text-dense UI is unreadable zoomed in, and looks identical in a file listing.

Nothing in motion

CSS animations are removed and Web Animations are finished before every capture.

Without it: A mid-animation frame is a state the product never rests in.

Time pinned

The page's clock is fixed, so a live timestamp cannot make two identical screens look different.

Without it: A ticking clock silently disarms the duplicate check — it still runs, it just can never fire.

A fresh context per feature

Each feature gets its own browser context, proven by a storage marker that must differ.

Without it: Leaked state documents a session no real user had — and on a shared profile, one carrying your identity.

A real phone, not a narrow window

Device scale, touch points and user agent are set together, then read back from the page.

Without it: Sites pick their layout from the user agent; a narrow window documents a screen nobody sees.

Console and network kept

Errors and failed requests are collected during the walk and become issues.

Without it: An empty list because the API is down looks exactly like an empty list that is a feature.

No two captures alike

Every capture is MD5-compared against every earlier one in the same walk, not just the previous.

Without it: Identical bytes mean two claimed states with one real state behind them.

Read it before you trust it

A tool that claims its output is trustworthy should be easy to audit. These are the files worth opening first.

• plugins/walkthrough/skills/walkthrough/SKILL.mdThe skill itself — what an agent is told to do, and what it is told never to do.
• scripts/lib/capture/invariants.mjsThe invariants and their assertions. Every check carries the failure that motivated it.
• scripts/lib/capture/session.mjsWhere the invariants are applied, identically, regardless of which backend is running.
• scripts/lib/capture/driver-contract.mjsThe backend interface. Implement it and declare your capabilities; the session verifies them.
• docs/findings/capture-backends-2026-09-18.mdThe measurements behind the architecture: which backends can meet which invariant, and how that was tested.
• scripts/verify-capture-layer.mjsRun the same walk through every backend and watch the guarantees hold — or fail out loud.

Your own hub

The skill writes JSON and PNGs into apps/hub/public/walkthroughs/{slug}/. The hub reads them straight off disk with no build step and no request-time generation, so a walk is visible the moment it finishes.

1. 1Register your apppnpm new-project
2. 2Install a browser for the default backendnpx playwright install chromium
3. 3Walk it/walkthrough
4. 4Read itpnpm dev

No Playwright browser on the machine? The capture layer falls back to a Chrome you already have, over the DevTools protocol, with no npm dependency — and says so in the run manifest, because that backend cannot record video and you should know which artifacts came from which.