/apply-renovate-prs

name: apply-renovate-prs
description: >
  Apply the changes from all open Renovate bot pull requests of a GitHub
  repository into the local working tree. Use this skill when asked to apply,
  merge locally, consolidate, batch, or try out Renovate/dependabot-style
  dependency update PRs so the combined upgrade can be built and tested in one
  go. This skill only modifies local files; it never commits, pushes, merges,
  or closes anything on GitHub.
disable-model-invocation: true

Apply Renovate PRs Locally

Collect every open pull request raised by Renovate in the target GitHub repository and apply their changes to the local working tree, so all dependency upgrades can be built and tested together.

Hard constraints

• **Never** run `git commit`, `git push`, `git merge`, `git cherry-pick`,

`git rebase`, `gh pr merge`, `gh pr close`, or `gh pr review`.

• Do not create branches, tags, or worktrees unless the user asks.
• Do not modify anything on GitHub. Read-only `gh` commands only

(`gh pr list`, `gh pr view`, `gh pr diff`, `gh api` GET).

• Leave the result as uncommitted changes in the working tree and report what

was applied, so the user decides what to do next.

1. Check preconditions

gh auth status
git rev-parse --show-toplevel
git status --short --branch

• If `gh` is missing or unauthenticated, stop and tell the user.
• If the working tree already has uncommitted changes, report them and ask

whether to continue on top of them or let the user stash first. Do not stash or discard the user's work on your own.

• Record the current branch and `git rev-parse HEAD` in the final report, so

the user can undo with `git checkout -- .` / `git stash`.

• Fetch the base branch objects so three-way applies have the pre-image blobs:

git fetch origin

Determine the repository: use the `origin` remote of the current directory by default, or the `owner/repo` the user names (pass it as `-R owner/repo` to every `gh` command).

2. Discover the open Renovate PRs

gh pr list --app renovate --state open --limit 100 \
  --json number,title,headRefName,isDraft,mergeable,files,labels,url

If that returns nothing, Renovate may be running as a user account or a self-hosted app, so fall back to:

gh pr list --state open --limit 100 \
  --json number,title,headRefName,author,isDraft,url \
  --jq '[.[] | select((.author.login | test("renovate"; "i")) or (.headRefName | startswith("renovate/")))]'

Notes:

• Renovate's "Dependency Dashboard" is a GitHub *issue*, not a PR. Ignore it.
• Exclude draft PRs by default and say so; include them only if the user asks.
• If the user restricted the scope (for example "only patch updates", "only the

Spring Boot ones"), filter accordingly and state the applied filter.

Show the list to the user before applying, then proceed.

3. Order the PRs

Apply in an order that minimises conflicts:

1. Patch updates, then minor, then major (major upgrades are most likely to need follow-up source changes). 2. Manifest-only PRs before lockfile-heavy PRs. 3. Grouped PRs (Renovate branches such as `renovate/all-minor-patch`) before the single-dependency PRs they may overlap with.

Read each version bump from the PR title (Renovate titles are of the form `chore(deps): update dependency org.foo:bar to v1.2.3`) and keep a running table of `PR number → package → old version → new version`.

4. Apply each PR

For every PR, take the patch and apply it with a three-way merge:

gh pr diff <number> --patch > /tmp/renovate-<number>.patch
git apply --3way --whitespace=nowarn /tmp/renovate-<number>.patch

Then unstage what `--3way` staged, keeping the file contents, so the review diff stays readable:

git reset --quiet

Skip the `git reset` if the user chose to continue on top of pre-existing *staged* changes — it would unstage those too. In that case, note in the report that the applied changes are staged.

Handle the outcomes:

• **Clean apply:** record it as applied and continue.
• **Conflict markers** (`git apply --3way` writes `<<<<<<<` into the file):

resolve them by hand. For dependency files the resolution is almost always "keep both bumps" — take the higher version for each distinct dependency, and never leave a marker behind. Verify with `git grep -n '^<<<<<<<\|^>>>>>>>'`.

• **Patch fails to apply at all** (`error: patch does not apply`): do not force

it. Instead read the PR diff (`gh pr diff <number>`) and make the equivalent edit directly in the manifest — change the version coordinate to the target version from the PR title. This is the reliable path for generated lockfiles and for PRs whose base is stale.

• **Lockfiles** (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`,

`gradle.lockfile`, `uv.lock`, `poetry.lock`, `go.sum`, …): applied lockfile hunks from several PRs are frequently inconsistent. Prefer applying only the manifest changes and regenerating each lockfile once, in step 6.

Also apply Renovate PRs that touch non-code manifests — `Dockerfile`, `docker-compose.yml`, `.github/workflows/*.yml`, `.tool-versions`, `.sdkmanrc`, `renovate.json` — the same way.

After applying a wrapper or Docker image PR, work through the matching entry in step 5 before moving on.

5. Special cases

Renovate only updates the files its managers know about. Some repositories duplicate the same version elsewhere, so after applying a PR check for these companion edits and make them by hand.

Maven / Gradle wrapper PRs — also update `.sdkmanrc`

Renovate updates `.mvn/wrapper/maven-wrapper.properties` or `gradle/wrapper/gradle-wrapper.properties`, but it does **not** update `.sdkmanrc`, so the SDKMAN-pinned build tool stays behind.

grep -n distributionUrl .mvn/wrapper/maven-wrapper.properties \
  gradle/wrapper/gradle-wrapper.properties 2>/dev/null
cat .sdkmanrc 2>/dev/null

• Read the new version from `distributionUrl`

(`apache-maven-3.9.11-bin.zip` →