Prepare current changes for a GitHub pull request by formatting affected files, checking builds and style, committing, and pushing. Create or update the PR, link related issues, and add page previews when available.
Open a pull request for the current feature
Review the instructions the agent will receive before you install.
Ensure we are not on the main branch, make a branch if necessary.
Check whether a PR already exists for the current branch with gh pr status or gh pr view. If one exists, update it with local changes.
Keep new agent-authored tests, including new test cases in existing files, out of the PR unless the user explicitly requested them. Updates to existing tests, fixtures, and snapshots are allowed when needed for the change. Review the diff and preserve pre-existing user changes.
If the changes add a Remotion Element, read the Element contribution guide before continuing.
Run Oxfmt on the files or package directories affected by the current change. Pass their actual paths; do not assume that the repository root has a src directory. Include relevant root-level files, and do not format unrelated packages or the whole repository.
For example:
bunx oxfmt <changed-file-or-package-directory>... --write
If none of the changed files are supported by Oxfmt, skip this step. Inspect any formatter changes before committing.
Then run
bun run build
bun run stylecheck
to ensure we compile and CI linting/formatting passes.
Commit the changes once. The title of the PR must be according to the pr-name skill.
Push the changes to the remote branch once, using git push -u origin HEAD.
Never force push, unless users asks for it.
Use the gh CLI to create a pull request and use the same format as above for the title.
When creating the PR, do not pass the PR body inline through a shell command (for example, avoid --body "..." or heredocs in bash). Instead:
/tmp/remotion-pr-body.md, or a unique file created under /tmp).
Closes #1234 or Closes https://github.com/owner/repo/issues/1234. Preserve the issue number or URL from the user's original request if they provided one.gh pr create --title "<title>" --body-file <path-to-temp-md-file>.Example:
gh pr create --title '`@remotion/package`: Add feature' --body-file /tmp/remotion-pr-body.md
After creating the PR, check whether it directly adds or modifies a primary page in packages/docs. Determine each page's public path from the page source, using packages/docs/docusaurus.config.ts as the route source. Do not infer paths for deleted pages or changes that only affect shared components, styles, data, or configuration.
After creating the PR, poll its comments for up to 60 seconds for the Vercel comment, sleeping 5 seconds between checks. Take the Preview link from the remotion project row and append each page path to it; ignore the bugs project row. If that preview link is unavailable and the deployment link only points to the Vercel dashboard, use vercel inspect <deployment-url> only when the Vercel CLI is installed and authenticated. Otherwise, do not modify the PR body and report that the preview URL could not be resolved.
Only wait for the Vercel comment. Do not wait for the deployment to finish, create a Vercel heartbeat, or probe the preview page.
Append the deep links to a ## Preview section in the PR body. Fetch the current body into a temporary Markdown file and update it with gh pr edit <pr> --body-file <path-to-temp-md-file>; never pass the replacement body inline.
If either the page path or the preview URL cannot be determined confidently, leave the created PR unchanged and report that preview links were not added.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add a reported Remotion bug to the bugs API with its affected versions, a short title, and upgrade guidance. Follow the existing entry format and place the new record first so recent bugs appear at the top.
Add a Remotion command-line or configuration option, or convert a hardcoded flag into a shared option definition. Connect parsing, configuration setters, help entries, and generated documentation so the option is consistently available and documented.
Add a new effect to @remotion/effects, including its implementation, package entry points, documentation, interactive demo, and preview images. Follow the package conventions and verify the changes with tests, formatting checks, and builds.
Add a person to the Remotion experts page by placing their portrait, entering their profile and contact links, and generating an expert card image. The instructions specify file locations, profile fields, and how to verify card generation.
Create a new @remotion package within the Remotion monorepo, a repository containing multiple packages. Set up its files, register it across the project, and prepare documentation, usage examples, and build configuration.
Add a new sound effect to @remotion/sfx, from registering the audio file to exporting its URL and documenting its use. The workflow covers playback examples, attribution, navigation entries, waveform generation, and the package build.