PR Updater

PR Updater

Push follow-up changes to an existing PR and update its description to reflect the new work.

Workflow

Step 1: Pre-flight Checks

1. Verify GitHub CLI authentication — run gh api user --jq '.login' to confirm the CLI is authenticated. If this fails, the user needs to run gh auth login first.
2. Find the existing PR — run gh pr view --json number,title,body,url,baseRefName,state to find the PR for the current branch. If no PR exists, abort and suggest using /create-pr instead. Check the state field — if it is not OPEN, abort and inform the user that the PR is already merged or closed.
3. Verify clean git state — run git status to ensure no uncommitted changes. If there are uncommitted changes, commit them directly — do NOT delegate to another skill or tell the user to commit first.
4. Sync submodules — check if .gitmodules exists first. If it does, run git submodule update --init --recursive. If not, skip this step.

Step 2: Sync with Base Branch

Ensure the feature branch is up-to-date with the base branch to avoid merge conflicts:

1. Fetch latest remote — run git fetch origin <base-branch> (use the base branch from the PR metadata)
2. Check for divergence — run git log HEAD..origin/<base-branch> --oneline to see if the base branch has new commits
3. Rebase if needed — if there are new commits on the base branch: a. Run git rebase origin/<base-branch> b. Resolve conflicts — if the rebase hits conflicts:
   • Read the conflicting files to understand both sides
   • Surface the conflict to the user — show both sides and ask which version to keep. Do not silently resolve conflicts.
   • Stage resolved files: git add <file>
   • Continue: git rebase --continue
   • Repeat until rebase completes
4. Verify clean state — run git status to confirm no unresolved conflicts remain
5. Push the branch — run git push. If the rebase changed history, use git push --force-with-lease instead. If --force-with-lease fails, it means someone else has pushed to this branch. Fetch the remote branch (git fetch origin <branch>), inspect the divergence (git log HEAD..origin/<branch> --oneline), and ask the user how to proceed — they may need to integrate the other contributor's changes first.

Step 3: Analyze New Changes

Understand the full scope of changes now in the PR:

1. Run git log origin/<base-branch>..HEAD --oneline to see all commits on this branch
2. Run git diff origin/<base-branch>...HEAD --stat for a high-level summary of changed files
3. Run git diff origin/<base-branch>...HEAD to read the full diff. Note: Three-dot (...) syntax is intentional — it shows only the changes introduced on this branch since it diverged from the base, excluding commits on the base branch that aren't part of this PR.
4. Identify the type of change: feat, fix, refactor, docs, chore, etc.