Feature Demo

Use this skill when the user asks for a demo video, walkthrough recording, or promo clip of a feature. It is NOT for verification screencasts of a code change — that is capture-visual-proof.

Pipeline: plan the narrative → author script → narrate → capture (browser, paced to the narrative) → trim opening → render → verify → upload.

The bundled render/ project is a reference template, not a fixed pipeline stage: copy it to the work dir and adapt the copy freely (branding, caption styling, layout, extra presets) when the demo calls for it. The timeline JSON is the stable contract between capture and render — keep the copy consuming it and any adaptation stays in sync with the recording.

All work happens under /tmp/feature-demo/work (the work dir). Nothing from this pipeline is ever committed to the repository.

SCRIPT=/tmp/feature-demo/demo-script.json OUT_DIR=/tmp/feature-demo/work node "$HOME/.agents/skills/feature-demo/capture/capture.mjs"

The runner is an agent-browser orchestrator: every browser action it performs goes through the agent-browser CLI, so it is the only browser automation this skill needs. It also reads /tmp/feature-demo/narration.json (written in step 3) on its own; captions-only runs simply will not have one. Keep the runner's printed summary and ls -la /tmp/feature-demo/work for the report. If the agent-browser executable is unavailable in this sandbox, report a blocker (proof runtime unavailable) instead of substituting another browser automation path. Expected outputs: /tmp/feature-demo/work/recording.mp4 and /tmp/feature-demo/work/timeline.json. Verify both exist and that ffprobe reports a duration close to the timeline's durationSeconds (the runner itself fails loudly when the recording is much shorter than the interaction). One retry on failure; then report blocked with the runner's error. The runner requires agent-browser v0.37.0 or newer and records headless using native record start ... --fps. It stops any existing daemon, opens the target page, sets the viewport, then attaches recording to that active page. Native recording preserves wall-clock holds without a synthetic frame ticker. Above 30 FPS the runner uses native H.264 raw.mp4 and lossless faststart remuxing, avoiding VP8 encoder backpressure; ordinary capture keeps raw.webm. Inspect capture-stats.json: capturedFrames counts incoming frames, frames includes held duplicates, and wallSeconds records interaction time. Check actual motion-frame changes and file duration before claiming higher capture FPS; an encoded 60 FPS stream or a 60 FPS render alone does not prove 60 distinct captured frames. Static holds legitimately repeat frames. Disclose reduced cadence or pacing failures instead of increasing output FPS. If a recording comes back much shorter than the interaction, the runner fails loudly. GPU-backed surfaces (WebGL/WebGPU, 3D, games) do not present frames to the headless compositor and cannot be recorded here — report webgl surface stalls recording naming the surface rather than retrying. If record stop itself reports an ffmpeg error, the sandbox is likely a stale snapshot with an outdated runtime ffmpeg (stale sandbox runtime).

npx remotion render src/index.ts Demo-wide out/demo-wide.mp4 --browser-executable="${REMOTION_HEADLESS_SHELL_PATH:-/opt/remotion/headless-shell}" --log=error

Run this with a GENEROUS command timeout (10 minutes) on the first attempt: a narrative-length cut is 750+ frames rendering in software on a small container, which routinely exceeds the default two-minute command window — a timeout there is wasted work, not a render failure. If the binary does not exist (older sandbox snapshot), run npx remotion browser ensure once and render without the flag. Repeat for Demo-vertical when the vertical preset was requested.