| name | takeover-pr |
| description | Take over a stale PR — supersede it with requested changes applied, crediting the original author |
| argument-hint | <pr-number> |
| allowed-tools | Bash, Read, Write, Edit, Grep, Glob, mcp__github__get_pull_request, mcp__github__get_pull_request_reviews, mcp__github__get_pull_request_comments, mcp__github__create_pull_request, mcp__github__add_issue_comment, mcp__github__update_issue |
Takeover PR
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 merge or git rebase their 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 from
git 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-review does (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 ./... and go 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-summary format), 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. plus Closes #<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. to main):
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-summary Validate 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
