Takeover Pr

---
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

```bash
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](../../../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:

1. 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`
2. Implement the accepted items on the new branch
3. Run `go build ./...` and `go test ./...`
4. 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:

1. **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
2. **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
3. 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:

1. Push the branch with an explicit refspec and set tracking explicitly (a
   worktree branch mis-tracks with `git push -u`, e.g. to `main`):
   ```bash
   git push origin feature/<slug>:refs/heads/feature/<slug>
   git branch --set-upstream-to=origin/feature/<slug> feature/<slug>
   ```
2. Confirm the successor PR body passes the `/pr-summary` **Validate Format**
   checklist, then create the PR (`mcp__github__create_pull_request`)
3. Post the closing comment on the original PR
   (`mcp__github__add_issue_comment`), then close it:
   `gh pr close <number>`
4. 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