$npx -y skills add remotion-dev/remotion --skill prOpen a pull request for the current feature
| 1 | Ensure we are not on the main branch, make a branch if necessary. |
| 2 | 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. |
| 3 | |
| 4 | 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. |
| 5 | |
| 6 | For example: |
| 7 | |
| 8 | ``` |
| 9 | bunx oxfmt <changed-file-or-package-directory>... --write |
| 10 | ``` |
| 11 | |
| 12 | If none of the changed files are supported by Oxfmt, skip this step. Inspect any formatter changes before committing. |
| 13 | |
| 14 | Then run |
| 15 | |
| 16 | ``` |
| 17 | bun run build |
| 18 | bun run stylecheck |
| 19 | ``` |
| 20 | |
| 21 | to ensure we compile and CI linting/formatting passes. |
| 22 | |
| 23 | Commit the changes once. The title of the PR must be according to the [`pr-name`](../pr-name/SKILL.md) skill. |
| 24 | |
| 25 | Push the changes to the remote branch once, using `git push -u origin HEAD`. |
| 26 | |
| 27 | Never force push, unless users asks for it. |
| 28 | |
| 29 | Use the `gh` CLI to create a pull request and use the same format as above for the title. |
| 30 | |
| 31 | When creating the PR, do not pass the PR body inline through a shell command (for example, avoid `--body "..."` or heredocs in `bash`). Instead: |
| 32 | |
| 33 | 1. Write the PR body to a temporary Markdown file in the system temp directory (for example `/tmp/remotion-pr-body.md`, or a unique file created under `/tmp`). |
| 34 | - If the current work was started from, fixes, or is otherwise tied to a GitHub issue, include a closing keyword in the PR body such as `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. |
| 35 | 2. Create the PR with `gh pr create --title "<title>" --body-file <path-to-temp-md-file>`. |
| 36 | |
| 37 | Example: |
| 38 | |
| 39 | ```bash |
| 40 | gh pr create --title '`@remotion/package`: Add feature' --body-file /tmp/remotion-pr-body.md |
| 41 | ``` |
| 42 | |
| 43 | ## Link directly changed website pages |
| 44 | |
| 45 | 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. |
| 46 | |
| 47 | 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. |
| 48 | |
| 49 | Only wait for the Vercel comment. Do not wait for the deployment to finish, create a Vercel heartbeat, or probe the preview page. |
| 50 | |
| 51 | 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. |
| 52 | |
| 53 | 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. |