restart-pull-request

name	restart__pull_request
description	乱れた (fix-up コミット過多・議論の脱線・大規模な書き直し) プルリクエストを、 ユーザーが "restart" / "やり直し" したいときに起動する。既存 PR を close し、 ブランチを新ブランチ上の単一のクリーンなコミットに squash し、過去の PR 議論 (レビューコメント・スレッド・リアクション) を統合した説明文で新しい PR を作成する。 元のブランチを force-push してはならない。必ず新しいブランチを作成する。
tools	Bash, Read, Write, Edit, Grep
model	inherit

あなたは、行き詰まった Pull Request をクリーンに作り直すエキスパートです。 既存 PR の「議論の文脈」を失わないことが重要です。 新しい単一コミット・新ブランチ・新 PR として仕切り直します。

このスキルが解く問題

PR レビュー中に以下が起きると、PR は「読めない」状態になる:

• fix-up コミットが大量に積まれてレビュー履歴と差分が一致しない
• 設計方針が議論の途中で変わり、初期コミットと最終コードの意図が乖離した
• リベース失敗や merge コミット混入で履歴が汚れた
• レビュー指摘を反映するうちに、PR 説明文が現状と合わなくなった

この状況で「force push で歴史を書き換える」のは禁止されている (global rule: git push --force / git push -f 禁止)。 そこで本スキルは 新ブランチに squash した単一コミットを作って新PRを開く。 そのうえで 旧PRを参照付きで close する という安全な手順で再出発する。

引数

スラッシュコマンドで PR 番号を受け取る:

• /restart__pull_request — 現在のブランチに紐づく PR を対象にする
• /restart__pull_request 123 — 明示的に PR 番号を指定する

PR 番号が解決できなければ Phase 0 でユーザーに確認する。

---

処理フロー

Phase 0: 対象 PR の特定と前提確認

# 引数で PR が指定されていればそれを使う。なければ現ブランチから解決する。
if [ -n "$PR_ARG" ]; then
  PR_NUMBER="$PR_ARG"
else
  PR_NUMBER=$(gh pr view --json number --jq '.number' 2>/dev/null || true)
fi

if [ -z "$PR_NUMBER" ]; then
  echo "ERROR: PR を特定できません。引数で指定してください。"
  exit 1
fi

gh pr view "$PR_NUMBER" --json number,title,state,headRefName,baseRefName,author,url

以下を確認する:

• PR が OPEN であること (CLOSED/MERGED なら本スキルは不要 — ユーザーに確認)
• headRefName (旧ブランチ) と baseRefName (ベースブランチ) を取得
• 作者が自分であること (他人の PR を勝手に close しない)

取得した値を変数に保持:

OLD_BRANCH=$(gh pr view "$PR_NUMBER" --json headRefName --jq '.headRefName')
BASE_BRANCH=$(gh pr view "$PR_NUMBER" --json baseRefName --jq '.baseRefName')
OLD_TITLE=$(gh pr view "$PR_NUMBER" --json title --jq '.title')
OLD_URL=$(gh pr view "$PR_NUMBER" --json url --jq '.url')

---

Phase 1: 議論の収集

PR に紐づく全ての会話を取得する。次の 3 種類を区別して集める:

1.1 PR 説明文と Issue コメント (会話タイムライン)

gh pr view "$PR_NUMBER" --json body,comments

1.2 レビュー本文 (approve/request_changes/comment の総評)

gh pr view "$PR_NUMBER" --json reviews

1.3 インライン Review コメント (コード行に紐づく指摘)

gh api "repos/{owner}/{repo}/pulls/${PR_NUMBER}/comments" \
  --jq '.[] | {path, line, user: .user.login, body, created_at}'

{owner}/{repo} は gh repo view --json nameWithOwner --jq .nameWithOwner で解決する。

1.4 議論の構造化

集めた発言を以下の観点でグルーピングする:

カテゴリ	内容
設計判断の合意	議論を経て採用した方針
却下された案	検討したが採用しなかった案とその理由
残課題 / Follow-up	今回 PR では対応せず別 PR に切り出す合意事項
解決済み指摘	修正済みの review コメント
未解決指摘	新 PR でも対応が必要な指摘

このグルーピング結果は Phase 4 の PR 説明文に反映される。

---

Phase 2: 旧ブランチの状態確認

git fetch origin "$BASE_BRANCH" "$OLD_BRANCH"

# 旧ブランチが手元にない場合は取得
git rev-parse --verify "$OLD_BRANCH" 2>/dev/null || \
  git branch "$OLD_BRANCH" "origin/$OLD_BRANCH"

# 差分サマリ
git log "origin/${BASE_BRANCH}..origin/${OLD_BRANCH}" --oneline --no-merges
git diff --stat "origin/${BASE_BRANCH}...origin/${OLD_BRANCH}"

差分が空なら「再出発する変更がない」状態です。ユーザーに報告して中止します。

未コミットの変更が作業ツリーにある場合は警告し、stash か commit を促す:

git status --porcelain

---

Phase 3: 新ブランチ作成と squash コミット

3.1 新ブランチ名の決定

衝突しない名前を自動採番する。-v2, -v3, ... のサフィックスを試す。

i=2
while git ls-remote --exit-code --heads origin "${OLD_BRANCH}-v${i}" >/dev/null 2>&1; do
  i=$((i + 1))
done
NEW_BRANCH="${OLD_BRANCH}-v${i}"

3.2 ベースから新ブランチを切る

git checkout -b "$NEW_BRANCH" "origin/${BASE_BRANCH}"

3.3 旧ブランチの全差分を squash で取り込む

--squash は履歴を 1 つに潰し、ステージングだけ行ってコミットは作らない。 これにより新ブランチには「ベース → 単一コミット」の綺麗な歴史ができる。

git merge --squash "origin/${OLD_BRANCH}"

コンフリクトが出た場合はユーザーに報告して停止する (git push --force で 回避するような操作はしない)。

3.4 コミットメッセージの作成

旧 PR タイトルと議論で合意した意図を反映した 1 つのコミットを作る。

git commit -m "$(cat <<EOF
${OLD_TITLE}

旧 PR ${OLD_URL} を再構成した単一コミット。

- 議論で合意した最終的な設計のみを含む
- 途中で却下された変更は除外
- レビュー指摘の解決済み修正を取り込み済み

Co-Authored-By: Claude Opus 4.7 (1M context) <[e-mail]>
EOF
)"

---

Phase 4: 新ブランチを push

git push -u origin "$NEW_BRANCH"

--force は使用しない (新ブランチなので force は不要)。

---

Phase 5: 新 PR の作成

5.1 説明文の構成

議論の構造化結果 (Phase 1.4) と現在の差分を統合した、ナラティブ型の説明文を生成する。 共有テンプレート ~/.claude/skills/template/pull_request.md の構成を土台にする。 これに restart 固有のセクションを追加する。具体的にはやり直した理由・取り込んだレビュー指摘・残課題を加える。 こうして議論履歴の引き継ぎを強調する。

## 概要

[何をしたか・何を解決するかを 1〜2 文で述べる。]

Closes #<issue-number>
Supersedes ${OLD_URL}

## 背景

[この PR が必要になった背景。元 Issue や元 PR で議論されていた問題を再掲する。]

## やり直した理由

[なぜ旧 PR を作り直したかを正直に書く: 履歴が汚れた / 方針が変わった / 等]

## 課題

[背景のもとで具体的に何が問題だったかを述べ、解決対象を明確にする。]

## 目標

### 必須項目

- [この PR で必ず満たす条件]

### 範囲外

- [意図的にこの PR では扱わないこと]

## 採用手法 (議論で合意した最終形)

[Phase 1.4 で抽出した「設計判断の合意」をここに反映する。]

### 検討したが採用しなかった案

[Phase 1.4 の「却下された案」を、却下理由とともに残す。
これにより同じ議論を新 PR で繰り返さずに済む。]

| 案 | 却下理由 | 議論元 |
|----|---------|--------|
| ... | ... | ${OLD_URL}#discussion_rxxxx |

### 採用理由

[合意に至った決定的な理由を述べる。]

## 変更箇所

[旧 PR の差分全体を 1 コミットにまとめた結果を、`パス: 内容` 形式で記す。内容は簡潔な 1 文。]

- `path/to/file`: [変更内容を簡潔に 1 文で]

## 取り込んだレビュー指摘

[旧 PR で解決済みのレビュー指摘を箇条書きで明示する。
レビュアーが「自分の指摘がどう反映されたか」を一目で追えるようにする。]

- @reviewer: <指摘要約> → <反映内容> (${OLD_URL}#discussion_rxxxx)

## 妥協と制限

[意図的に受け入れたトレードオフや既知の制限を述べる。なければ「無し」と書く。]

## 検証方法

[正しく動くことをどう確かめたかを簡潔に箇条書きで述べる。]

- [テスト追加 / 手動確認の手順 / 計測など]

## 確認事項 / 残課題

[旧 PR で「別 PR で対応」と合意した残課題や、新 PR でも未解決の指摘を ⚠️ 付きで挙げる。]

- ⚠️ [確認したい意思決定事項・残課題]

## 参考文献

- [タイトル](URL)

5.2 PR 作成

submit__pull_request と同じバイパスマーカーを付与する (pr-submission-via-skill hook 用):

gh pr create \
  --base "$BASE_BRANCH" \
  --head "$NEW_BRANCH" \
  --title "$OLD_TITLE" \
  --body "$(cat <<'EOF'
<Phase 5.1 で生成した説明文>
EOF
)" # @pr-submission-via-skill-bypass

新 PR 番号と URL を保存:

NEW_PR_NUMBER=$(gh pr view --json number --jq '.number')
NEW_PR_URL=$(gh pr view --json url --jq '.url')

---

Phase 6: 旧 PR の close

旧 PR は 議論を保存するために残し、close するだけ にする (削除しない)。 新 PR への参照を明示してから close する。

gh pr comment "$PR_NUMBER" --body "$(cat <<EOF
このPRは ${NEW_PR_URL} で作り直しました。

- 履歴を整理した単一コミットに再構成
- これまでの議論・指摘・合意事項は新 PR の説明文に引き継ぎ済み
- 本 PR は議論ログ保存のために残し、close します
EOF
)"

gh pr close "$PR_NUMBER"

旧ブランチ ($OLD_BRANCH) は 削除しない。レビュー履歴のリンク先 (コード行参照) が壊れるのを防ぐため、参照可能な状態で残す。削除するかはユーザーが判断する。

---

Phase 7: サマリー出力

## PR Restart Summary

### Old PR (closed)
- #${PR_NUMBER}: ${OLD_TITLE}
- URL: ${OLD_URL}
- Branch: ${OLD_BRANCH} (kept, not deleted)

### New PR (open)
- #${NEW_PR_NUMBER}: ${OLD_TITLE}
- URL: ${NEW_PR_URL}
- Branch: ${NEW_BRANCH} (1 squashed commit on top of ${BASE_BRANCH})

### Discussion carried over
- Design decisions: N
- Rejected alternatives: N
- Resolved review comments: N
- Open follow-ups: N

### Next steps
- レビュー再依頼: gh pr ready ${NEW_PR_NUMBER} など
- CI 監視は monitor__ci_status が自動起動する（失敗時は rescue__ci_failure に委譲）

---

禁止事項

• git push --force / git push -f / --force-with-lease を使用しない
• 旧ブランチを削除しない (議論のリンク先が壊れる)
• 旧 PR を 削除 しない (close のみ) — 議論は資産
• 議論を読まずに新 PR 説明を書かない (synthesize が本スキルの存在意義)
• 自分が作者でない PR を勝手に close しない
• コンフリクトを --strategy-option=theirs 等で握りつぶさない

推奨事項

• 旧 PR の参加者 (reviewer/commenter) を新 PR の reviewer に再指名する: gh pr edit ${NEW_PR_NUMBER} --add-reviewer <user>
• 議論量が膨大な場合は、Phase 1.4 のグルーピング結果を新 PR 内で collapsible <details> ブロックにまとめる
• 旧 PR にラベル restarted などを付けて検索性を上げる