> ## Documentation Index
> Fetch the complete documentation index at: https://hyperframes-codex-docs-human-first-refactor.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Turn a pull request into a video

> Explain a GitHub pull request as a changelog, feature reveal, fix, or technical walkthrough.

Use this workflow when the source is a GitHub pull request or a specific code change.

The agent reads the PR, identifies what changed and why it matters, then turns that into a short visual explanation.

<Frame caption="From a film built out of a real pull request — the diff, the files, and the review, on screen.">
  <video className="aspect-video w-full object-cover bg-zinc-100 dark:bg-zinc-900" src="https://static.heygen.ai/hyperframes-oss/docs/images/showcase/wfv2-pr.mp4" poster="https://static.heygen.ai/hyperframes-oss/docs/images/showcase/wfv2-pr.jpg" autoPlay muted loop playsInline />
</Frame>

## Start with the PR

```text theme={null}
/hyperframes Turn https://github.com/owner/repo/pull/123 into a
45-second release video for existing users. Focus on the visible behavior,
not implementation details. Show the before and after, and include the
migration note from the PR description.
```

Say who the video is for:

* users need the outcome and any action they must take;
* contributors may need architecture and tradeoffs;
* a social audience needs one clear change and visible proof.

## Approve the angle

Confirm:

* the intended PR and target branch;
* whether the audience cares about user impact, architecture, or both;
* the release state: proposed, merged, released, or planned;
* the before-and-after behavior;
* breaking changes or migration work;
* the maximum level of code detail.

## Check the facts

Before export:

* verify the PR is the intended source;
* distinguish shipped behavior from planned follow-up;
* do not turn test coverage or refactoring into a user-facing claim;
* include breaking changes and migration steps;
* confirm issue, version, and product names.

Use [Studio Storyboard](/studio/storyboard) to review the explanation and [Source](/studio/source) when a code excerpt needs adjustment.

## Common problems

| Problem                                  | Better direction                                           |
| ---------------------------------------- | ---------------------------------------------------------- |
| The video reads the PR description aloud | Build a story around the user or system change.            |
| Refactoring becomes a product claim      | Separate internal work from visible behavior.              |
| Code appears too briefly to read         | Show only the relevant lines and hold them longer.         |
| The PR is not released yet               | Say that clearly instead of presenting it as shipped.      |
| The audience is mixed                    | Make separate user-facing and contributor-facing versions. |

<CardGroup cols={2}>
  <Card title="Review in Studio" icon="palette" href="/studio">
    Check the facts, sequence, code excerpts, timing, and final release language.
  </Card>

  <Card title="Choose another workflow" icon="route" href="/workflows">
    Return to the source-and-outcome chooser.
  </Card>
</CardGroup>