validate-with-recording

Screen-recording QA

Why this exists

Screenshots show states, not behaviour. Everything between two screenshots is invisible: a spinner that never stops, a layout that shifts 200 ms after paint, a toast that appears and vanishes, a double-submit, a flash of unstyled content, or the simple fact that a step took eleven seconds. A before/after pair cannot distinguish "it worked" from "it worked eventually, badly".

This skill records the browser continuously while you drive it, then converts the recording into evidence you can actually read.

Note that mcp__claude-in-chrome__gif_creator does not solve this. It stitches together screenshots you already took and exports them for a human to download — it returns nothing to you, and adds no information you did not already have. Worse, the vision API only ever reads a GIF's first frame, so an animated GIF is not something you can watch. If you have one, pass it to analyze_recording, which decodes every frame.

The constraint that shapes everything

You cannot be shown a video. There is no video input, and animations are not supported. So the tools convert a recording into a budgeted set of stills plus structured text.

The budget is real and small: images cost a flat 1600 tokens each, and a tool result stays untruncated only under ~12,500 tokens — about seven images. Default is six: one contact sheet plus five detail frames. Do not raise max_images casually; prefer get_frames to drill into a specific moment.

Two rules about the window, or you will record nothing

Both of these were found the hard way, and both produce a recording that looks valid and contains nothing.

1. The tab you are validating must be the active tab of its window. Window capture records what the window paints, and a window paints only its active tab. Claude in Chrome happily drives a background tab — and that tab will not appear in the recording at all. Switch to it first.

2. No other window may be sitting on top of the target window. macOS marks a covered window occluded and the browser stops painting it, so the capture shows frozen browser chrome and a blank page. Two browser windows at nearly the same position are the usual culprit. Being behind a full-screen terminal on a different Space is fine; being underneath another window on the same Space is not.