validate-with-recordinglisted

# 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 speci