# Browser Recording

Record a browser flow as video/GIF evidence for animations, transitions and multi-step...

- Repository: https://github.com/kirodotdev/KiroCrew (4711 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add kirodotdev/KiroCrew --skill browser-recording -g -a claude-code -y`
Codex: `npx skills add kirodotdev/KiroCrew --skill browser-recording -g -a codex -y`
Cursor: `npx skills add kirodotdev/KiroCrew --skill browser-recording -g -a cursor -y`
Gemini CLI: `npx skills add kirodotdev/KiroCrew --skill browser-recording -g -a gemini-cli -y`

## Description

Record a browser flow as video/GIF evidence for animations, transitions and multi-step interactions a still screenshot cannot prove. Uses the project's Playwright via a bundled runner, then ffmpeg to mp4 + GIF. Use when asked to record a demo or GIF, or when a UI change involves motion.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Browser Recording, video/GIF evidence for UI flows

A still frame cannot prove motion or sequence correctness. When a UI change
involves **animation, transitions, or a multi-step flow** (wizard steps, a
modal opening, drag interactions), record it. This skill is the *how* for the
evidence rule in the `frontend-design-workflow` skill's Phase 3.

## Recording evidence for GUI PRs (provenance)

`frontend-design-workflow` Phase 3 owns *which* evidence a GUI change needs: a
still screenshot for a static layout or styling change, a **recording** for
motion, a transition, or a multi-step flow a still frame cannot prove. This
section does not widen that rule, do not record a change a screenshot already
covers, it adds the one thing Phase 3 leaves open: how to make a recording
*reproducible and honest about how it was produced*.

When a change does need a recording, it must come from the **real server and
model flow**: the actual dev/preview server running the branch, driven through
a real interaction, never a fixture, a mock, or a hand-faked event stream. A
recording of a stubbed surface proves nothing about the code under review.

Embed the recording with a provenance line beside it disclosing how it was
produced:

```
recorded from <full-SHA> · <tree/origin> · mode: <flags> · real server + model, no fixtures
```

State the commit SHA, the tree or origin it came from, any mode flags that
change behaviour, and an explicit real-vs-fixture disclosure. The line is
written by the same agent that made the recording, so it discloses provenance
rather than proving it, the real check is the SHA-pinned embed a reviewer can
open and a re-record from that SHA. A recording with no provenance line leaves
how it was produced unstated.

## What it does

`scripts/record_browser.py` drives a headless Chromium through the **target
project's own Playwright install**, records the session as webm, and, when
ffmpeg is available, converts it to mp4 and a palette-optimized GIF.

The rest: https://github.com/kirodotdev/KiroCrew/blob/HEAD/src/kiro_crew/builtin_skills/browser-recording/SKILL.md