Diversio Engineering
On this page
SKILL DOCUMENTATION

Browser Walkthrough Recording

Record and review a captioned feature walkthrough for a PR or how-to guide.

Overview

Record and review a captioned feature walkthrough for a PR or how-to guide.

This skill ships inside the Browser Walkthrough Recording plugin and can be installed through the Claude Code marketplace or directly in Codex from its skill path.

Parent Surface

Parent docs: Browser Walkthrough Recording

Related wrapper commands from the parent plugin:

/browser-walkthrough-recording:record

When to use

For a diagram or written explanation without a live browser recording, use the relevant documentation skill instead.

  • “Record a captioned walkthrough of this local feature for the PR.”
  • “Show support how this flow works, with close-ups and clean screenshots.”

Settle the inputs

local delivery; ask before uploading or changing a PR.

Check Node.js, Playwright, FFmpeg with libx264, and ffprobe. If absent, explain what must be installed; do not silently install global tools.

Use the supplied scripts relative to this skill directory. Copy the capture script into a task-owned scratch project before adapting it; do not edit the installed skill. Keep scripts outside directories slated for cleanup.

  • Ordered flow, audience, local/dev URL, demo login, and expected outcome.
  • Exact environment and data ownership. Never record production or customer data.
  • Destination, access restrictions, duration and upload-size limit. Default to local delivery; ask before uploading or changing a PR.
  • Existing browser tooling: reuse the repo's Playwright and browser when possible. Check Node.js, Playwright, FFmpeg with libx264, and ffprobe. If absent, explain what must be installed; do not silently install global tools.

1. Prepare safe inputs

Prefer synthetic fixtures in a disposable local database. Renaming a few fields in a customer dump does not anonymize metrics, free text, images, or audit rows. If approved local fixture changes are needed, verify the exact database host, name, and ownership first. Do not rely on DEBUG, a dev settings suffix, a host substring, or Python assert as a safety boundary. Never clear whole tables, create a superuser, or change shared data merely to make a video prettier.

Authenticate before creating the recording context, using a separate unrecorded context if necessary. Transfer only the needed storage state in memory; never commit it. Show the signed-in starting state, not passwords, tokens, login links, or secret-bearing terminal output. One-time tokens are still secrets. Use fictional names and reserved email domains such as example.test.

Inspect the app without recording first. Confirm every screen in the flow has only safe data, including notifications, tooltips, avatars, URLs and error states. If a leak is discovered in a capture, quarantine it locally and re-record with safe inputs; a caption or blur is not proof that the original is safe to publish.

2. Plan a readable recording

Write a short storyboard: step, action, expected visible state, caption, focus area, screenshot. Use one task per clip; aim for 30–90 seconds unless the flow needs longer. Trim startup and idle time, not the pauses viewers need to read.

Use 1920×1080 only when the interface needs it. Avoid 4K for ordinary UI demos.

framing or a deliberate close-up over shrinking the entire dashboard.

allows top/bottom placement; move it when it obscures the subject. Allow at least 2.5 seconds, longer for longer captions. Include the outcome, not just “click here.” Supply the same steps as accessible text outside the video.

not rely on color alone: name the control in the caption. No flashing effects.

The template's add_zoom changes page CSS zoom and can reflow the app: label it as a presentation aid, check the layout, and restore zoom afterwards. If reflow changes behavior, use an FFmpeg crop/scale of the recorded detail instead. Never present a cropped screenshot as a successful interaction.

  • Capture at 1440×900 with matching viewport and video size (the template default). Use 1920×1080 only when the interface needs it. Avoid 4K for ordinary UI demos.
  • Keep text readable at the destination's normal player size. Prefer tighter framing or a deliberate close-up over shrinking the entire dashboard.
  • Use short numbered captions, high contrast, and plain words. The template allows top/bottom placement; move it when it obscures the subject. Allow at least 2.5 seconds, longer for longer captions. Include the outcome, not just “click here.” Supply the same steps as accessible text outside the video.
  • Highlight one relevant control at a time; remove the previous highlight. Do not rely on color alone: name the control in the caption. No flashing effects.
  • For small controls, use a stable close-up after an establishing wide shot. The template's add_zoom changes page CSS zoom and can reflow the app: label it as a presentation aid, check the layout, and restore zoom afterwards. If reflow changes behavior, use an FFmpeg crop/scale of the recorded detail instead. Never present a cropped screenshot as a successful interaction.
  • Prefer calm cuts over animated pans. Keep enough surrounding UI for orientation.

Resources

Scripts

  • capture-template.cjs
  • to-mp4.sh

Installation

Switch between Claude Code and Codex, then copy the install command for the runtime you use.

claude plugin marketplace add DiversioTeam/agent-skills-marketplace
claude plugin install browser-walkthrough-recording@diversiotech

Invocation:

/browser-walkthrough-recording:record