← ClaudeAtlas

video-walkthroughlisted

Record a video walkthrough of a user scenario via Playwright: a Gherkin test scenario is replayed in a browser, every step is captioned as a subtitle, and the output is an mp4 (+ .srt) plus optional clean before/after screenshots of every step. One artifact serves both as proof the feature is tested and as video documentation. Use when asked to "record a walkthrough video", "make a video guide for a feature", "add a walkthrough to US-XX", "capture a demo of the scenario" — или по-русски: «записать видео прохождения», «сделать видео-инструкцию по фиче», «добавить walkthrough к US-XX», «снять демо сценария», «сделать скрины прохода».
Avatechdir/video-walkthrough-skill · ★ 0 · Testing & QA · score 72
Install: claude install-skill Avatechdir/video-walkthrough-skill
# Video walkthroughs via Playwright Turns one Gherkin scenario into a **test + video walkthrough**. The same scenario that verifies the feature is recorded in a browser with slowMo and per-step subtitles. Communicate with the user in their language. The language of the artifacts (subtitles, narration, screenshot names) follows the language of the scenario steps, not the language of this document. ## When to apply - A feature is done → the client needs a "how it works" video. - Proof is needed that the user path is tested. - You want living UI documentation that cannot silently rot (if the test breaks, the video does not build). ## Principles (do not violate) 1. **The video is a by-product of the test, not a separate procedure.** The scenario is written anyway; recording is attached via a flag. 2. **Verification is assertions only (`expect`).** Never "watch" recorded video frames multimodally — token-expensive and pointless. Video is for humans, assertions are for machines. The exception is not about verification: viewing PNGs from `screens/` as a separate, explicitly requested UX/UI-analysis task (see "Walkthrough screenshots"). 3. **Stable selectors (`data-testid`)**, not fragile paths — otherwise debugging eats tokens. 4. **Isolated data (seed)** via a dedicated backend/fixture — real data is never touched, `id`s/state are deterministic. 5. **Test stand on dedicated ports** — never conflict with the developer's working server. ## One-time proj