modernize
Skill0 starsChanged 9 days agoMITView on GitHub
For getting old prs up to date. Use when asked to rebase a pr or "modernize".
11 other projects use a version of this, 5 of them edited; 2 new projects in the last 4 weeks, against 0 the 4 before.
Adopted by
Surging: 2 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- lbussell/agent-skillsword for word, first seen Nov 8, 2026
- scottwater/skillsedited, first seen Nov 8, 2026
- Belweave/hstacktheir own version, first seen Nov 8, 2026
- shubrt/skillsedited, first seen Nov 1, 2026
- zanellig/skillsedited, first seen Nov 1, 2026
- connorch/skillsword for word, first seen Nov 1, 2026
Used with
Projects with it also use takeover and unslop.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
assisjpSkilltakeover
Take over an existing branch, pull request, worktree, or agent handoff while preserving the original goal, contributor credit, and concurrent work. Use when the user asks to take over, finish, rescue, or continue someone else's implementation. Do not use to replace a clear request to start new work.
Also in 4 projects that use this
photon-groveSkillunslop
Detects and rewrites generic, overly polished, or AI-sounding prose while preserving meaning. Use when the user asks to "unslop", humanize, de-AI, tighten, or review whether writing sounds generated.
Also in 3 projects that use this
Other versions11 projects use a version of this.
Word for word · 3
- t3dotgg/tstack★ 2.5k100% same
- connorch/skills★ 2100% same
- lbussell/agent-skills★ 0100% same
Edited · 5
- mneves75/skills★ 368% same
- scottwater/skills★ 296% same
- lrstanley/skills★ 170% same
- zanellig/skills★ 192% same
- shubrt/skills★ 097% same
Wrote their own version · 3
- garrytan/gstack★ 141ksame name
- damacus/agent-skills★ 2same name
- Belweave/hstack★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- rules/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- babysit-prSkill
- beast-uiSkill
- cleanupSkill
- councilSkill
- doc-viewSkill
- featuremapSkill
- file-prSkill
- frontend-designSkill
- full-sendSkill
- full-stopSkill
- impeccableSkill
- leaving-pr-commentsSkill
- no-commentsSkill
- patrolSkill
- sol-loopSkill
- statechartSkill
- technical-writingSkill
- tldrSkill
- untangleSkill
- verify-prSkill
- whySkill
The file
We split this skill into the rules it gives an agent
12 rules. 4 are common, 6 are distinctive, and 2 are very specific to this project.
4
Common
Most of the 8 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 15
Always check to make sure you have pulled latest origin for your branch, main branch, and any other branch related to your work before …
- Common: line 17
Treat existing worktree changes as user-owned.
- Very specific: line 21
Never use an unqualified force push.
- Very specific: line 23
Do not post a PR comment unless the user asked for one.
- Common: line 44
Look beyond overlapping lines:
- Common: line 48
Do both sides now claim ownership of the same behavior or invariant?
- Distinctive: line 54
Do not describe a PR as current merely because Git reports no conflicts.
- Distinctive: line 58
Use one of these recommendations:
- Common: line 76
Create a safe local branch or disposable worktree at the recorded PR head.
- Distinctive: line 84
Run the repository's focused checks for the touched area.
- Distinctive: line 87
If the lease fails, fetch and reassess rather than overwriting new work.
- Distinctive: line 89
Do not merge the PR.
“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Modernize
Modernize the idea, not just the branch. A clean rebase does not prove that the PR still belongs in the product.
Guardrails
- Always check to make sure you have pulled latest origin for your branch, main branch, and any other branch related to your work before starting.
- Treat existing worktree changes as user-owned. Use a disposable worktree when the active worktree is dirty or is being used for other work.
- Modernizing authorizes rebasing and updating the PR branch. It does not authorize merging, closing, changing the base branch, or expanding scope.
- Never use an unqualified force push. Update a rebased branch with
--force-with-leaseagainst the head SHA observed before the rebase. - Do not post a PR comment unless the user asked for one. Use the
leaving-pr-commentsskill for every comment posted on the user's behalf.
Establish the PR's intent
Resolve the PR and record its URL, state, base, head repository and branch, current head SHA, author, checks, and review state. Read the title, body, linked issues, commits, review threads, and complete diff. State the smallest coherent goal the PR was trying to accomplish before judging its implementation.
Fetch the latest remote base and PR head. Use the PR's actual base branch,
usually main, rather than assuming the local branch is current. Record the
merge base so the original PR and subsequent base-branch changes can be
compared separately.
Check what changed around it
Inspect commits and diffs added to the base branch since the PR diverged. Search merged and open PRs when titles, code paths, or behavior suggest a replacement or competing implementation.
Look beyond overlapping lines:
- Has the same user-facing problem already been solved?
- Did APIs, types, schemas, dependencies, or architectural boundaries change?
- Do both sides now claim ownership of the same behavior or invariant?
- Was the code being changed deleted, moved, or intentionally simplified?
- Would landing the PR restore an old behavior or create two ways to do the same thing?
- Is the original benefit still large enough to justify the maintenance cost?
Do not describe a PR as current merely because Git reports no conflicts.
Choose a disposition before pushing
Use one of these recommendations:
- MODERNIZE: the goal is still useful and the implementation remains the right shape. Rebase, resolve conflicts, test, and update the branch.
- REWORK: the goal is still useful, but a mechanical rebase would preserve the wrong implementation. Explain the smallest credible rewrite and stop before pushing unless the user also asked for that rework.
- CLOSE: the PR is superseded, obsolete, directionally wrong, or no longer worth its cost. Cite concrete evidence and stop. Do not spend time rebasing an obsolete branch, and do not close it without explicit permission.
Be willing to recommend CLOSE. Age alone is not evidence, and sunk effort is
not a reason to keep a PR alive.
Rebase without losing intent
For a MODERNIZE disposition:
- Create a safe local branch or disposable worktree at the recorded PR head.
- Rebase its commits onto the freshly fetched base branch.
- Resolve each conflict according to the PR's current intent and the base branch's newer invariants. If a conflict reveals a product or architecture disagreement, stop and reconsider the disposition instead of guessing.
- Compare the pre-rebase and post-rebase commit series with
git range-diffand inspect the final diff. Confirm that no intentional behavior disappeared and no already-landed behavior was reintroduced. - Run the repository's focused checks for the touched area. Distinguish real failures from pre-existing or infrastructure failures.
- Push with
--force-with-leasetied to the previously observed remote head. If the lease fails, fetch and reassess rather than overwriting new work.
Do not merge the PR.
Report
Lead with MODERNIZE, REWORK, or CLOSE and the reason. Then summarize:
- meaningful changes on the base branch;
- conceptual conflicts or confirmation that none were found;
- the rebase and push result, if performed;
- checks run and their results;
- the remaining decision or work, with a link to the PR.
Separate observed facts from judgment. Say what could not be verified instead of manufacturing confidence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

