Agent skill · software engineering · remotion-dev
update-from-upstream-main
Update the current Remotion branch with the latest canonical main branch. Use when asked to update or sync from upstream main, merge the latest main into a feature branch, fast-forward local main, or bring a pull request branch up to date without rewriting published history.
Why this skill is useful
Adds an executable script for updating branches in a specific Git workflow that preserves history and handles conflicts, which is not commonly found in public documentation.
What it needs
About 2k tokens when loaded. Last updated 2026-08-06. 55,698 stars on the source repository.
What this skill does
Update From Upstream Main Update from the canonical remotion-dev/remotion repository while preserving local work and published branch history. Workflow 1. Inspect the repository before changing it: Stop and report the state if an operation such as a merge or rebase is already in progress. A detached checkout is supported and must not prevent the update. If the working tree contains staged, unstaged, or untracked changes, stash them automatically and continue: Record the created stash's commit ID so the same entry can be restored later. Do not treat uncommitted changes as a reason to stop. Do not include ignored files unless the user explicitly asks. 2. Select the canonical remote whose URL points to remotion-dev/remotion. Prefer upstream when it exists; otherwise use origin. If neither remote points to the canonical repository, stop and ask before adding or changing a remote. 3. Fetch the latest main branch without changing the working tree: 4. Update the checked-out branch: On main, require a fast-forward: On a feature branch or detached checkout, merge main without opening an editor: Do not rebase, reset, or force-push. A merge keeps published branch history intact and can be pushed normally; on a detached checkout, report that the resulting commit is still detached. 5. If the merge conflicts, resolve each file deliberately and preserve both the feature intent and upstream changes. Do not accept ours or theirs across the entire merge. Check every resolved file for leftover conflict markers before staging: Inspect and remove any matches that are conflict markers. Then stage only the resolved files and finish the merge with: 6. If step 1 created a stash, reapply it after the upstream update is complete: Reapply the stash before reporting success or before stopping after a fetch or merge failure, provided no Git operation is still in progress. If applying the stash causes conflicts, resolve them deliberately without rerunning git stash apply. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills remotion-dev/update-from-upstream-main