Pull requests
A pull request holds every detail a reviewer could want and none of the context its author had. An explainer of the PR gives the reviewer that context in a few minutes: what the change is for, how it works, and the parts that deserve a closer look.
Here's one, made automatically for a PR on the action's own repository: Scrimba PR Guide Workflow.
Three ways to get one
From your coding agent. Connect Claude Code, or any tool that speaks MCP, and ask it to explain the PR. The agent has the repository, so it reads the diff, the surrounding code and the history, then writes the lesson itself. Nothing to install in the repository.
Automatically, on every PR. Add the Scrimba PR Explainer GitHub Action and each pull request gets an explainer as it's opened, posted as a comment for whoever reviews it.
From ChatGPT or Codex. With the @Explain Video Generator plugin installed, ask for a video of the pull request you're looking at. Codex has the code, so it works the same way as a coding agent. In ChatGPT, paste the diff or attach the changed files first.
The Chrome extension isn't the tool for this. It explains the page you're reading, so on a pull request it sees only what GitHub renders, not the repository behind it.
The GitHub Action
scrimba/pr-explainer is Scrimba's own GitHub Action. On every pull request that's ready for review, it runs Claude Code on the checked-out code, streams an explainer to Scrimba through the agent plugin and CI endpoint, and keeps one comment on the pull request updated with the link.
What you need
- A repository on GitHub with Actions enabled.
- Node.js 20.12 or newer, for the installer.
- Claude Code. The action runs on a Claude Code OAuth token from your subscription, so no API key is involved.
- Optional: the GitHub CLI, signed in with
gh auth login, so the installer can store the token for you.
Setting it up
Run the installer from a local checkout of the repository:
npx pr-explainerIt writes .github/workflows/scrimba-pr-explainer.yml, then offers to set the one secret the workflow needs. Say yes and it runs claude setup-token for you, or asks you to paste a token, and stores it as SCRIMBA_PR_EXPLAINER_CLAUDE_CODE_OAUTH_TOKEN on the repository.
The installer commits nothing. Commit the workflow file and push, and the action is live.
If you skip the automatic setup, or the GitHub CLI isn't available, do the same two steps yourself:
claude setup-token
gh secret set SCRIMBA_PR_EXPLAINER_CLAUDE_CODE_OAUTH_TOKENWhat happens on a pull request
The workflow runs when a pull request is opened, reopened, pushed to, or marked ready for review. Draft pull requests are skipped until they're marked ready.
The job checks out the pull request's merge commit and hands Claude Code the PR's title, description, linked issues and diff. It reads the changed files as they are now, the code around them and nearby tests, then writes the explainer. It never modifies the repository.
A comment appears on the pull request straight away and updates as the run goes on:
- Queued, then Generating once Claude Code starts.
- Done, with a Watch explainer link. The link arrives while the explainer is still being written, so you can start watching before the run finishes.
- Skipped, with a one-line reason, when the change is too small to be worth a video: a typo fix, a formatting-only change, a comment edit or a lockfile update.
- Failed, with a link to the workflow log.
The explainer is a helper, not a merge gate: a failed run never blocks merging, and the check still passes. A new push cancels a run that's still in progress and starts a fresh one for the new commit.
What the explainer covers
Each one is built as three acts:
- The stage. What the PR is for, in plain terms, and the parts of the system it touches, introduced by following one real event through them.
- The how. The flows the change adds or alters, walked as side-by-side diff slides with the pointer on the exact lines, plus a diagram or animation where the shape or the motion explains more than code.
- The issues. Problems the agent could verify, one per slide, each with the failing case and the smallest fix, and a plain call on whether it should block the merge. A clean PR gets one slide saying so.
The explainer teaches from real code and diffs. It never uses generated images.
Who can watch
The explainer is unlisted: anyone with the link can watch, no Scrimba account needed. That's what makes the link work for everyone reading the pull request.
It doesn't belong to anyone yet. The first person to open the link, sign in and claim it becomes its owner and controls its visibility from then on. See Privacy, claiming and sharing.
Open-source repositories
On a public repository, the pull request comment is public too, and so is the link in it. Whoever claims the explainer first owns it.
Forks
Pull requests from forks are skipped by default, and the workflow says why in a comment above the setting. The agent reads the pull request's content with access to the checked-out repository and the token passed to the job, so a fork PR could carry instructions aimed at it.
Set allow-forks: true on the action only if you trust every fork that can open a pull request against the repository.
Running it by hand
The workflow can also be started from the Actions tab. Choose Scrimba PR Explainer, click Run workflow and enter a PR number. This regenerates the explainer without a new commit.
Options
These go under with: on the action step in the workflow file.
| Input | Default | What it does |
|---|---|---|
pr-number | The PR from the triggering event | Which pull request to explain |
model | Claude Code's default | The Claude model to run, such as opus or claude-opus-5-5 |
allow-forks | false | Whether pull requests from forks get an explainer |
agents | claude | Which agent writes the explainer. Only Claude is supported for now |
Troubleshooting
The run fails with "Missing SCRIMBA_PR_EXPLAINER_CLAUDE_CODE_OAUTH_TOKEN secret". The secret isn't set on the repository. Run the two commands under Setting it up.
No comment appears. Check that the pull request isn't a draft, that it comes from the same repository rather than a fork, and that the workflow file still has issues: write under permissions and GH_TOKEN in the step's env. The installer writes all of those.