Stale PR Modernizer
Brings an old pull request up to date by first deciding whether it should still exist, then rebasing only the ones worth keeping and checking with git range-diff that nothing was lost or brought back.
What it does
Treats a stale PR as a product question before it is a Git question. It records the PR URL, state, base, head branch, head SHA, checks and review state, reads the title, body, linked issues, commits, review threads and full diff, and writes down the smallest coherent goal the PR was after. Then it fetches the base and the PR head, records the merge base, and reads what landed on the base branch since the two diverged, searching merged and open PRs for a replacement or a competing implementation. The questions go beyond overlapping lines: has the same user-facing problem already been solved, did APIs, types, schemas or architectural boundaries move, do both sides now claim the same invariant, was the code being changed deleted or deliberately simplified, would landing it restore an old behaviour or create two ways to do one thing. A clean merge is not treated as proof the PR is current. The answer is one of three dispositions. MODERNIZE means the goal and the shape still hold, so it rebases in a disposable branch or worktree, resolves conflicts by the PR intent against the newer invariants of the base, compares the old and new commit series with git range-diff, runs the focused checks, and pushes with --force-with-lease tied to the head it observed before the rebase. REWORK means the goal holds but a mechanical rebase would preserve the wrong implementation, so it describes the smallest credible rewrite and stops. CLOSE means the PR is superseded or no longer worth its cost, so it cites the evidence and stops without closing anything. It never merges. Distilled from the modernize skill in t3dotgg/tstack (MIT), the set of everyday agent skills Theo Browne published on 2026-10-24 (2,215 stars and 137 forks four days later).
When to use
- ✓A PR has been open for weeks, main has moved on, and someone has asked the agent to rebase it
- ✓Git reports no conflicts, but you suspect the code the PR touches was refactored or replaced in the meantime
- ✓You are clearing a backlog of old PRs and need a keep, rework or close call on each one, backed by evidence
- ✓You are picking up a colleague's abandoned branch and want to know whether it still belongs in the product before spending a day on it
When not to use
- ✗The branch is fresh and current, and the job is to finish and land it: use dev-branch-finisher
- ✗You want the change reviewed for bugs: use code-review-helper. This skill judges whether the PR still fits the codebase, not whether its logic is correct
- ✗You want the PR merged or closed for you. The skill recommends and stops, and both of those decisions stay with a person
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/stale-pr-modernizer.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
---
name: stale-pr-modernizer
description: Use when asked to update, rebase or revive an old pull request, or to "modernize" a PR. Also use when triaging a backlog of stale PRs into keep, rework or close.
---
# Stale PR Modernizer
Modernize the idea, then the branch. A clean rebase proves the lines still apply. It says nothing about whether the PR still belongs in the product.
## Ground rules
- Pull the latest remote state of the PR branch, the base branch, and any related branch before starting.
- Changes already in the working tree belong to the user. If the tree is dirty or in use, work in a disposable worktree.
- Being asked to modernize authorizes rebasing and updating the PR branch. It does not authorize merging, closing, changing the base branch, or widening the scope.
- No unqualified force push, ever. A rebased branch goes up with --force-with-lease pinned to the head SHA observed before the rebase.
- Post no PR comment unless the user asked for one.
## Pin down what the PR was for
Resolve the PR and record its URL, state, base branch, head repository and branch, head SHA, author, checks, and review state. Read the title, the body, the linked issues, every commit, the review threads, and the complete diff.
Before judging the implementation, write one sentence: the smallest coherent goal this PR was trying to accomplish. Everything after this is measured against that sentence.
Fetch the latest base and PR head. Use the PR's real base branch rather than assuming the local copy is current, and record the merge base, so the original change and the base branch's later changes can be read separately.
## Read what happened around it
Go through the commits and diffs that landed on the base since the PR diverged. Search merged and open PRs whenever a title, code path or behaviour hints at a replacement or a competing implementation.
Conflicts in overlapping lines are the least interesting finding. Ask:
- Has the same user-facing problem already been solved another way?
- Did APIs, types, schemas, dependencies or architectural boundaries change?
- Do both sides now claim ownership of the same behaviour or invariant?
- Was the code under change deleted, moved, or simplified on purpose?
- Would landing this restore an old behaviour, or create two ways to do the same thing?
- Is the original benefit still worth its maintenance cost?
"No conflicts" is not evidence that a PR is current.
## Pick a disposition before touching the branch
| Disposition | When | What happens |
|---|---|---|
| **MODERNIZE** | The goal is still useful and the implementation is still the right shape | Rebase, resolve, test, push |
| **REWORK** | The goal is still useful, but a mechanical rebase would preserve the wrong implementation | Describe the smallest credible rewrite, then stop, unless the user also asked for the rework |
| **CLOSE** | Superseded, obsolete, pointed the wrong way, or no longer worth its cost | Cite concrete evidence and stop. Never close without explicit permission |
Be willing to say CLOSE. Age alone proves nothing in either direction, and effort already spent is not a reason to keep a PR alive. Rebasing a branch that should be closed is wasted work.
## Rebasing a MODERNIZE
1. Create a safe local branch or disposable worktree at the recorded PR head.
2. Rebase its commits onto the freshly fetched base.
3. Resolve each conflict by the PR's goal and the base branch's newer invariants. When a conflict turns out to be a product or architecture disagreement, stop guessing and reopen the disposition.
4. Compare the pre-rebase and post-rebase series with git range-diff, then read the final diff. Confirm no intended behaviour disappeared and no behaviour that already landed got reintroduced.
5. Run the repository's focused checks for the area touched. Separate real failures from ones that were already failing or come from infrastructure.
6. Push with --force-with-lease against the remote head recorded before the rebase. If the lease is rejected, someone pushed in the meantime: fetch and reassess instead of overwriting their work.
Do not merge.
## Reporting back
Open with the disposition and the reason in one line. Then cover the meaningful changes on the base branch, any conceptual conflicts (or a statement that none turned up), the rebase and push result if one happened, the checks run and how they came out, and the decision or work that remains, with a link to the PR.
Keep observed facts and judgment apart. When something could not be verified, say so plainly rather than filling the gap with confidence.
## Finished means
The disposition is stated and backed by evidence from the base branch. A MODERNIZE has a range-diff showing nothing lost or revived, passing focused checks, and a lease-protected push. A REWORK or CLOSE left the branch exactly as it was found. The PR is unmerged and still open.
Example prompts
Once installed, try these prompts in Claude:
- Modernize PR #1482. It adds rate limiting to the webhook handler and has been open since July.
- Here are six PRs older than 60 days. Give me MODERNIZE, REWORK or CLOSE for each with the evidence, and do not push anything yet.
- Rebase PR #311 onto main, but before you push, show me the range-diff and tell me whether anything that landed on main since would be reverted.
- Oct 28, 2026New skill: the PR goal stated in one sentence, base-branch changes since the merge base read for replacements and moved invariants, a MODERNIZE / REWORK / CLOSE disposition before any push, then a worktree rebase verified with git range-diff and pushed with --force-with-lease. It never merges or closes.