Takeover PR
SkillDev toolsTake over a stale PR — supersede it with requested changes applied, crediting the original author
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Takeover PR skill
What this skill tells your AI
The instructions your AI receives, as published by gittower/git-flow-next in .claude/skills/takeover-pr/SKILL.md and read by ahel’s review.
Execute the review response window policy from CONTRIBUTING.md: when a contributor has not responded to requested changes within 7 days, close their PR and land a successor PR based on their work with the requested changes applied on top — crediting them. All public actions (push, new PR, closing comment) wait for user confirmation.
Arguments
/takeover-pr <pr-number>
Instructions
1. Verify Eligibility — Strictly
Fetch the PR, its reviews, comments, and commits. The takeover is only legitimate if all of these hold:
- The latest maintainer review is
REQUEST_CHANGES(or explicitly requests changes in its body) - 7 or more days have passed since that review was submitted
- The author has not responded since: no commits pushed, no comments, no review replies after the review's timestamp. Any author activity — even "I need more time" — resets the window per CONTRIBUTING.md
If any condition fails, stop and report why (including the exact dates). Do not proceed on a technicality; when the situation is ambiguous (e.g., the author reacted with an emoji, or pushed to a different branch), surface it to the user instead of deciding alone.
2. Preserve the Contributor's Work
git fetch origin pull/<number>/head:takeover/pr-<number>
git checkout main && git pull
git worktree add -b feature/<slug> ../git-flow-next.worktrees/<slug> main
cd ../git-flow-next.worktrees/<slug>
Derive <slug> from the linked issue or PR title, following the usual
branch naming; the worktree uses the sibling-root convention (see
DEV_WORKFLOW.md §3). Then bring in the
contributor's commits:
- Preferred:
git mergeorgit rebasetheir commits onto the new branch unchanged — original authorship is preserved automatically - If their commits must be reworked (squashed, split, or amended to meet
COMMIT_GUIDELINES.md): add
Co-authored-by: <name> <email>trailers to every commit that contains their work. Get name/email fromgit log --format='%an <%ae>'on their commits
3. Apply the Requested Changes
Use the review-feedback machinery rather than improvising:
- Evaluate the review comments exactly as
/address-reviewdoes (read.claude/skills/address-review/SKILL.md, steps 4–6): verdict + severity per comment, written to.ai/pr-<number>/review-plan-<sha>.md - Implement the accepted items on the new branch
- Run
go build ./...andgo test ./... - Commit per COMMIT_GUIDELINES.md — takeover fixes are your commits; the contributor's credit stays on their preserved commits
4. Local Review
Run /code-review (read the skill) on the new branch vs main. Fix any
must-fix findings before proceeding.
5. Draft the Public Actions
Prepare, but do not execute:
- Successor PR title and body (per
/pr-summaryformat), including a credit paragraph:This PR supersedes #<number> by @<author>, whose commits are included <unchanged | with Co-authored-by attribution>. It adds the changes requested in review.plusCloses #<issue>for the underlying issue - Closing comment for the original PR: courteous and factual — thank the author, link the successor PR, reference the CONTRIBUTING.md response window policy, invite them to review the successor
- Whether CONTRIBUTORS.md needs the author added (check if they're already listed)
6. Confirmation Gate
Present to the user:
- The eligibility evidence (review date, days elapsed, no author activity)
- Commits on the new branch (
git log --oneline main..HEAD) showing preserved authorship - The review-plan verdicts and what was implemented
- The full successor PR body and the closing comment
Ask: "Push, open the successor PR, and close the original?"
7. Execute
After confirmation:
- Push the branch with an explicit refspec and set tracking explicitly (a
worktree branch mis-tracks with
git push -u, e.g. tomain):git push origin feature/<slug>:refs/heads/feature/<slug> git branch --set-upstream-to=origin/feature/<slug> feature/<slug> - Confirm the successor PR body passes the
/pr-summaryValidate Format checklist, then create the PR (mcp__github__create_pull_request) - Post the closing comment on the original PR
(
mcp__github__add_issue_comment), then close it:gh pr close <number> - Update CONTRIBUTORS.md if drafted in step 5 (commit on the new branch or main per project practice)
8. Report
- Successor PR URL, original PR closed
- How the contributor was credited
- Any review findings deferred to follow-up
Signals
- GitHub stars
- 439
- Forks
- 28
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
takeover-pr- Source
- github.com/gittower/git-flow-next