Skip to main content

​
What this makes

A code-change explainer built from a GitHub pull request. The /pr-to-video workflow reads the PR through gh — the diff, commits, files, and contributors — reshapes it into a story, and builds it frame by frame, rendering code beats on a purpose-built diff surface. The input is a code change, not a website or a product page. A PR link (https://github.com/owner/repo/pull/N), an owner/repo#N ref, or “this PR” in a checked-out repo all work. A product to sell → /product-launch-video; a topic with no PR → /faceless-explainer. Unsure → start at /hyperframes.

​
Base prompt

Verified, from the examples page — a 30-second feature reveal:
/pr-to-video Make a 30-second 1920x1080 feature-reveal video from [PR URL]. Lead with what users get, not the diff; show the key code change with the code-diff block for one beat only; end on version number + repo URL. No narration, kinetic captions instead.
Rendered from the prompt above, unedited.

​
Variants

/pr-to-video Make a ~40-second 1920x1080 changelog video from [PR URL]. Changelog angle: open with the release line, then one beat per notable change — a short label and a one-line “what it does” each. Show at most two code-diff hunks across the whole video. End on version + repo URL. Calm male TTS narration, no captions.
Rendered from this prompt with [PR URL] = heygen-com/hyperframes#2092, unedited.A changelog trades depth for breadth — many small changes, each a beat, rather than one change explored deeply. Keep code beats sparse so the pace stays fast. A PR doesn’t carry its shipping version — the agent finds it from the release tag or the package manifest on main.
/pr-to-video Make a ~40-second 1920x1080 fix-explainer from [PR URL], for developers. Fix angle: state the bug’s symptom first, then the root cause, then the one-line fix on the code-diff block. End on version + repo URL. No narration, kinetic captions.
A fix reads as symptom → cause → fix. Lead with what users saw break, not the stack trace — the diff is the payoff, not the opening.
/pr-to-video Make a ~70-second 1920x1080 refactor-walkthrough from [PR URL], for developers. Refactor angle: why the old shape hurt, then the new shape, showing the before/after with the code-morph block for the key file. End on version + repo URL. Calm male TTS narration.
A refactor changes shape without changing behavior, so the story is why the new structure is better. code-morph animates one form transforming into another — the right block when the point is the transition, not a line-by-line delta.

​
The knobs that matter

The style is fixed to the workflow’s warm-editorial preset with a navy code surface built for diffs — it’s what makes the code beats legible. You don’t choose a theme here; you choose the angle, the hunks, and the narration.

​
Common failure modes

Forcing a theme over the preset. The style is fixed for a reason — the navy code surface is tuned for diff legibility; a foreign theme fights it and produces a compromise (see rules and anti-patterns).
  • ❌ /pr-to-video ... dark theme, neon accents
  • ✅ let the preset carry the look; spend your specificity on the angle and the code beats
Asking for the whole diff. A PR video explains the change; it doesn’t recite every file. A full diff is unreadable at video scale.
  • ❌ walk through the entire diff, file by file
  • ✅ feature the 2-3 key hunks, each a small legible snippet
Opening on the code. The diff is the payoff, not the hook — lead with what the change means.
  • ❌ start with the diff, then explain what it does
  • ✅ lead with what users get, then show the key hunk
Hard-timing a narrated cut. With narration the spoken length sets the runtime; state a range, not a fixed number.
  • ❌ a 40-second narrated walkthrough
  • ✅ a ~40-second narrated walkthrough