Skip to main content
Give it a pull request link. The agent reads the diff, the commits and who worked on it, then explains the change. A real pull request as a 32-second explanation: code, before and after, and sound.

​
Make it

Paste the pull request link into Make something and say who will watch:
The agent reads the actual pull request and checks whether it has shipped, so a proposed change is never shown as released. If your team already has a release video you like, add its link and ask for the same style. With your own agent instead of the app, start the message with /hyperframes.

​
Pick the story for the audience

  • Users: lead with the visible change, show before and after, name any action they must take.
  • Contributors: the architecture change, the tradeoff, the code path a reviewer needs.
  • Social: one feature reveal with visible proof and only the code that explains it.
Say whether it’s a changelog, a feature reveal, a fix or a refactor, and mention any breaking change. The video explains the change; it doesn’t read the description aloud.

​
Prompts that work

Verified, from the examples page — a 30-second feature reveal:
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.
Made from the prompt above.

​
Say these when they matter

​
Variants

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.
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.
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.

​
Common mistakes

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.
  • Avoid: walk through the entire diff, file by file
  • Instead: 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.
  • Avoid: start with the diff, then explain what it does
  • Instead: lead with what users get, then show the key hunk
Hard-timing a narrated cut. The spoken length sets the runtime, so give a range.
  • Avoid: a 40-second narrated walkthrough
  • Instead: a ~40-second narrated walkthrough

​
Verify the proof

  • The pull request and target branch are correct.
  • Proposed, merged, and released are not confused.
  • User-facing claims match the actual behavior.
  • Code excerpts show only the relevant lines and remain readable.
  • Tests and refactoring are not presented as product features.
  • Contributor names and release details are accurate.
Ask the agent when the explanation or the evidence must change; fix a timing, a code crop or a caption by hand in the editor.