/pr-walkthrough

name: pr-walkthrough
description: Create a narrated video walkthrough of a pull request with code slides and audio narration. Use when asked to create a PR walkthrough, PR video, or walkthrough video.

PR walkthrough video

Create a narrated walkthrough video for a pull request. This is designed to be an internal artifact, providing the same benefit as would a loom video created by the pull request's author — walking through the code changes, explaining what was done and why, so that anyone watching can understand the PR quickly.

**Input:** A GitHub pull request URL (e.g., `https://github.com/tldraw/tldraw/pull/7924`). If given just a PR number or other description, assume that the PR is on the tldraw/tldraw repository.

**Output:** An MP4 video at 1280×720 (30 fps) with audio narration, whisper-timed yellow-on-black subtitles, and standardized intro / outro slides, saved to `out/pr-<number>-walkthrough.mp4`.

All intermediate files (audio, manifest, scripts) go in `tmp/pr-<number>/` relative to this skill directory. This directory is gitignored. Only the final `.mp4` lives at `out/`.

Run commands that reference `./scripts` or `./video` from this skill directory.

Philosophy

**This is a walkthrough from the author's perspective.** The goal is the same as if the PR author sat down with someone and walked them through the changes — showing specific code, explaining what changed and why, in an order that builds understanding. The viewer should come away understanding both _what the code does_ and _how to think about the changes_.

This means:

• **The narration drives everything.** Write the walkthrough narration first, as a continuous explanation of the PR. Then figure out what should be on screen at each moment to support what's being said.
• **Show the code.** The default visual is a code diff or source file. Text slides are the exception (intro, brief transitions, outro), not the rule. When the narration talks about a function, the viewer should be looking at that function.
• **Walk through changes in a logical order**, not necessarily file order or commit order — but always anchored to concrete code, not abstract descriptions.
• **Explain the "why", not just the "what".** The code on screen shows what changed. The narration adds the reasoning — why this approach, what problem it solves, what edge cases it handles.

Workflow

Step 1: Understand the PR

Read the PR commits, diff, and description. Understand the narrative arc:

• What problem does this solve?
• What's the approach?
• What are the key mechanisms?

gh pr view <number> --json title,body,commits
git log main..HEAD --oneline
git diff main..HEAD --stat

**Skip generated files.** When reading the diff, ignore files that are auto-generated rather than hand-edited. These add noise without informing the walkthrough. Common examples in this repo:

• `**/api-report.md`, `**/api-report.api.md` — generated API surface reports
• `**/*.api.json`, `**/temp/*.api.json` — API extractor output
• `apps/docs/content/reference/**` — generated reference docs
• `yarn.lock`, `package-lock.json` — lockfiles
• `**/CHANGELOG.md` — auto-generated changelogs
• Any file the repo's tooling regenerates (snapshots, schema dumps, bundled assets)

If unsure whether a file is generated, check for a header comment like "DO NOT EDIT" or check whether the repo has a generator command that produces it. Filter these out when picking which files to feature in `diff`/`code` slides.

Step 2: Write the narration

Write the narration as continuous text, broken into logical segments. Each segment is a beat of the walkthrough — a concept, a change, or a group of related changes. Save this as `tmp/pr-<number>/SCRIPT.md`.

The narration should read like the author explaining the PR to a colleague: "So here's what we're doing... The core problem was X... The approach I took was Y... If you look at this function here..."

Structure: intro → context/problem → code walkthrough → summary. See **Script structure** below.

If the commits are simple and organized well (often on a branch with `-clean` in its name), you can follow their commit messages and descriptions to guide your narration. Otherwise, examine the code and create your own narrative. Introduce concepts in an order that builds on previous ones.

Avoid redundancy, especially between intro and first content segment.

Step 3: Generate audio and timestamps

Generate per-segment audio clips with one TTS call per segment. This avoids chunking, alignment, and splitting entirely — each segment is short enough for a single reliable TTS call.

Write a `narration.json` file, then run the `generate-audio.sh` CLI tool:

./scripts/generate-audio.sh narration.json tmp/pr-<number>/

**API key:** Sourced automatically from the repo `.env` file (`GEMINI_API_KEY`).

Narration JSON format

{
	"style": "Read the following walkthrough narration in a calm, steady, professional tone. Speak at a measured pace as if the author of a pull request were walking a colleague through the code changes.",
	"voice": "Iapetus",
	"slides": [
		"This pull request adds group-aware binding resolution to the arrow tool...",
		"The core problem was that arrow bindings broke when the target shape...",
		"If you look at the getBindingTarget method in ArrowBindingUtil.ts..."
	]
}

• **`style`** — Voice persona and pacing instructions. Keep it short and specific.
• **`voice`** — Gemini voice name (default: `Iapetus`).
• **`slides`** — Array of narration text, one entry per segment.

How it works

1. For each segment, the script builds a prompt: style preamble + segment text. 2. One API call to `gemini-2.5-pro-tts` per segment generates a WAV clip directly. 3. Each clip is validated (duration sanity check vs word count) and retried automatically if the output is bad. 4. Leading/trailing silence is trimmed from each clip.

**Output:** Per-segment audio clips (`audio-00.wav`, ...) and a `d