Specification
- Skill ID
- remotion-dev/remotion/release
- Publisher
- remotion-dev
- Repository
- remotion
- Installs
- 0
- Files
- 1
- Synced
- Sep 23, 2026
How to use it
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
remotion-dev/remotion/releaseInstalls these files- SKILL.md
What this skill tells the agent
- Kill any
turboprocesses that might be running with SIGKILL - Before beginning the release, verify that gcloud is logged in by running
gcloud auth print-access-token >/dev/null. If it fails, rungcloud auth login, then repeat the check. Do not continue with the release until the check succeeds. - Codex-specific: Before running release commands, make sure rbenv wins over the macOS system Ruby. Codex may start non-interactive shells with
/usr/binbefore~/.rbenv/shims, causing Ruby 2.6 to be used even though the user's terminal uses Ruby 3.3.x. Run release commands that may invoke Ruby/Bundler with:PATH="$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH" <command>Verify withPATH="$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH" ruby --version; it should use the user's rbenv Ruby, not/usr/bin/ruby. This matters because the lambda Ruby package currently resolves gems such asjsonthat require Ruby >= 2.7. - Run
npm login(I will manually do 2FA in the browser) - Use
op item get "Npmjs" --fields password --reveal --account remotiondev.1password.comto get the password for NPM. - Use
op item get "Npmjs" --otp --account remotiondev.1password.comto get a one-time password for 2FA. - Run
npm token create --name="PublishRemotionXXXXXX" --packages "remotion" --packages "create-video" --packages-and-scopes-permission read-write --bypass-2fa --scopes "@remotion" --otp=<otp>. Replace XXXXXX with a random string so we have a unique name. Useop item get "Npmjs" --otp --account remotiondev.1password.comto get the OTP and pass it via--otp=. It will ask for a password, pipe in the password usingecho "$PASSWORD" |. - Run
bun i - Run
bun run build - Run
npm view remotion versionto get the current version number - Run
bun set-version.ts <version>, where <version> is the current version plus 1. If the exit code is not 0, abort the entire release process immediately. - Run
cd packages/example && sh runlambda.sh && cd ../... If this fails, abort the release. - Run
NPM_CONFIG_TOKEN=<token> bun run releasewhere <token> is the NPM token we just created - Ordinary publishing already triggers npm's automatic malware scan; no separate staging step is needed for the current direct-publish workflow. Availability commonly takes around five minutes, sometimes 15 minutes or longer. These times are not guarantees.
- Verify every public package selected by
publish.tswithnpm view <package>@<version> version --json. A successfulbun publish --tolerate-republishexit is not proof of availability: it can hide a409 Cannot publish over previously staged version "<version>". - For missing versions or staging conflicts, check the npm lifecycle status API:
GET https://registry.npmjs.org/-/package/<encoded-package-name>/version/<version>/status, authenticated with a token that has publish access. URL-encode scoped names, for example@remotion%2Fwhisper-web. Keep credentials out of logs. - If the status is
validating, poll status and exact-version availability once per minute for up to one hour while continuing independent release work. Do not republish or restage the same version while scanning is pending. If it is still validating after this observation window, report it as an acceptable pending scan with its last observed status, not as available or guaranteed to become available. - If the version is awaiting maintainer approval, use
npm stage list <package> --jsonandnpm stage view <stage-id> --jsonto verify the package and version. Wait for scanning to finish before approval, then runnpm stage approve <stage-id> --otp=<fresh-otp>using the authenticated maintainer session and the 2FA instructions above. Waiting alone does not approve a staged version. Recheck exact-version availability after approval or a published status. - An empty stage list does not prove that scanning is pending or that a conflict will resolve itself. If the status API is unavailable, check
npm stage listand the package's versions page on npmjs.com while logged in as a maintainer. A status API403can mean the endpoint is not enabled for this package;404can mean a missing version or insufficient access. Report blocked, rejected, manual-review, or unknown states and unresolved errors explicitly; do not classify them as acceptable scanning delays. - If npm explicitly returns
E_STAGE_REQUIRED, follow staged publishing: usenpm stage publish <tarball>with the affected package's prepared release artifact, wait for scanning, then review and approve its stage as above. A staging 409 alone is not a reason to switch workflows or upload again. - In the release summary, distinguish verified available packages, confirmed pending scans, stages awaiting approval, and unresolved failures. Include the affected package and version for every pending or failed item. Other publish failures remain errors.
- Once the new package versions needed by the templates are available, run
bun run publishtemplatesfrom the repository root to republish every template. If a required version is still pending, report template publishing as pending too. If any template fails to publish, stop the release workflow and report the failure. - Generate a changelog in markdown and save it to
/tmp/release-<version>.md: - Run
git log v<previous_version>..v<new_version> --onelineto get all commits - Extract PR numbers from merge commits
- For each PR, run
gh pr view <number> --json title,author,number,url --jq '"* \(.title) by @\(.author.login) in \(.url)"' - Categorize PRs into sections: "What's Changed", "Templates", "Docs", "Internal"
- In "What's Changed", sort items so that entries for the same package are adjacent (no subheadings, just sorted order). Changes to the
remotioncore package should appear first - Strip redundant prefixes from PR titles (e.g. remove "Docs:" from items in the Docs section)
- Linkify items whose PR added a new documentation page: run
git diff --diff-filter=A --name-only v<previous_version>..v<new_version> -- 'packages/docs/docs/**/*.mdx' 'packages/docs/docs/**/*.md'to list added docs pages, map each added page to the PR that introduced it, and wrap that item's title in a markdown link to the page (e.g.* [<title>](https://remotion.dev/docs/<slug>) by @author in <url>). Determine the URL from the page'sslug:frontmatter if present, otherwise from its file path relative topackages/docs/docs/. Leave items without a new docs page unlinked. - "Templates" is a separate section for any template-\* changes
- Check for genuinely new contributors by running
gh api repos/remotion-dev/remotion/contributors --paginate --jq '.[].login'and comparing against PR authors. Only add a "New Contributors" section for authors not in that list - Add
**Full Changelog**: https://github.com/remotion-dev/remotion/compare/v<previous_version>...v<new_version>at the bottom - Use the same format as previous GitHub releases (check with
gh release view v<previous_version>) - Don't release until you get approval. Allow me to edit it before.
More from remotion-dev
Use this skill in a project
Open any RiverX project, search the Skills panel for remotion-dev/remotion/release, and install it in one click.
