Smart pr

Smart PR

現在のブランチから PR を作成、または既存 PR を更新する。

引数の解析

$ARGUMENTS を以下のルールで解析する:

• -p がある場合 → -p より後の部分を {プロンプト} として保持する
• -p がない場合 → {プロンプト} は空
• {プロンプト} は PR のタイトル・本文・ラベル等に関する追加指示として使う

例: -p ドラフトで作って / -p レビュアー向け補足に移行手順を書いて

プロジェクト規約

本スキルは以下の規約に従う。詳細は references/git-conventions.md を参照（必要時のみ Read）。プロジェクト側の CLAUDE.md / AGENTS.md / README に独自規約があればそちらを優先する。

• デフォルトブランチへの直接 push 禁止。force push もしない。
• PR / Issue 作成時は作成者を自動アサイン（get_me でログイン名取得 → issue_write の assignees に渡す）。
• 既存ラベルのみ付与。新規ラベル作成は提案しない。
• issue_write の labels は上書きのため、既存ラベルを取得して結合する。
• MCP の body パラメータには実改行を含める（\n リテラルは禁止）。

ツール選択

• GitHub API 操作 → GitHub MCP ツールを優先（承認不要・パラメータ明示）。
• git 操作 → Bash。
• git remote get-url origin の出力（[email protected]:owner/repo.git または https://github.com/owner/repo.git）から owner / repo を抽出して MCP の必須パラメータに渡す。.git 拡張子は除去する。

MCP ツール名について: 本 SKILL.md では GitHub MCP サーバーが提供する list_pull_requests / pull_request_read / update_pull_request / create_pull_request / issue_write / get_me / list_issues / search_issues を short name で記載する。実際の呼び出し時は環境上のフルネーム（例: mcp__plugin_github_github__list_pull_requests 等）にマップする。複数 MCP サーバーで名前が衝突する場合はサーバー名を含む完全修飾名を使う。

手順

1. 状態確認

1-a. ローカル状態の取得（Bash 並列）

git remote get-url origin && git branch --show-current && git status --short

1-b. デフォルトブランチの検出

まず git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' を試す。空文字列が返ったら以下のフォールバックを使う:

for name in develop main master; do
  git show-ref --verify --quiet "refs/remotes/origin/$name" && echo "$name" && break
done

検出できなければユーザーに確認する。

1-c. MCP 並列呼び出し

• list_pull_requests（owner, repo, head: "<owner>:<branch>", state: "open"）で既存 PR を検索
• get_me でアサイン用ログイン名を取得

list_pull_requests レスポンスからは number / title / body / labels のみ保持し、他フィールド（タイムスタンプ・ユーザー詳細等）はコンテキストから破棄する。

1-d. 判定

• デフォルトブランチにいる → 「作業ブランチで実行してください」と案内して終了
• デフォルトブランチと差分なし → 「PR にする変更がありません」で終了
• 未コミット変更あり → ユーザーに通知（/smart-commit を提案）
• PR が存在する → 更新フロー（Step 4-U）へ
• PR が存在しない → 新規作成フロー（Step 4-N）へ

2. デフォルトブランチとの同期確認

git fetch origin
git merge-base --is-ancestor origin/<default-branch> HEAD

含まれている場合はスキップ。含まれていない場合は behind しているので以下を実行する。

2-a. behind 件数の確認とユーザー承認

git rev-list --count HEAD..origin/<default-branch>

「origin/<default-branch> に対して N コミット behind しています。マージしますか？」とユーザーに提示し、承認を得てから git merge origin/<default-branch> を実行する。件数が 0 でも提示する。

2-b. 競合発生時

git merge が非 0 で終了した場合は競合あり。以下のコマンドで一覧を取得し、ファイル名のみをユーザーに提示する（ファイル内容を全 Read しない）:

git diff --name-only --diff-filter=U

ユーザーに以下の選択肢を提示する:

1. 個別ファイルを指定してもらい、git diff <file> で該当箇所のみ Read して解決方針を相談
2. git merge --abort で merge を取り消して中断

ユーザーの承認なしに git add / git commit しない。

3. 未プッシュコミットのプッシュ

git rev-parse --verify origin/<branch> 2>/dev/null

• 存在しない（リモート未追跡） → git push -u origin <branch>
• 存在する → 未プッシュコミットがあれば git push、なければスキップ

push 後、変更概要を取得:

git log --oneline <default-branch>..HEAD
git diff <default-branch>...HEAD --stat

--stat の合計行数が 1000 を大きく超える場合は、ファイル単位でサマリを作り、各ファイルは必要に応じて部分 Read に留める（diff 全文をコンテキストに乗せない）。

---

既存 PR 更新フロー

4-U. 差分特定・分析

pull_request_read（owner, repo, pullNumber）で現在の PR を取得し、以下のフィールドのみ保持する:

{
  "number": 45,
  "title": "...",
  "body": "...",
  "labels": ["bug"]
}

他フィールド（コミット一覧・コメント・アサイン情報・タイムスタンプ等）はコンテキストから破棄する。git log <default-branch>..HEAD の出力と PR の commits との差分から、PR に未反映の新規コミットを特定する。

新規コミットがなければ「更新する変更がありません」で終了。

5-U. PR 本文の更新

既存本文を 構造解析してから新規変更を追記する:

1. 既存本文の Markdown 見出し（## 概要 / ## 変更内容 / ## レビュアー向け補足 / ## 関連 Issue 等）を正規表現で抽出する。見出しレベルが ## でない場合は本文の表記に合わせる。
2. 新規コミット種別と引数 {プロンプト} を以下のセクションへ振り分ける:

内容	振り分け先（簡易構成 / 標準構成）
機能追加・修正・テスト等のコード変更	## 変更内容 / ## 実装内容（末尾追記。標準構成で表・図があれば行・分岐の追記も検討）
引数 {プロンプト} の指示内容	{プロンプト} で指定されたセクション、未指定なら ## レビュアー向け補足 / ## 備考
設計判断・影響範囲・既知の制約	## レビュアー向け補足 / ## 設計判断（要点）（追記）
新規 Issue 紐づけ	## 関連 Issue（追記）
方向性が大きく変わる場合のみ	## 概要（提案 → 承認後更新）

3. 既存記述は変更しない（追記のみ）。ラベルも追加のみ・削除しない。タイトルは原則変更しない。

6-U. ユーザー確認 → 更新実行

更新後の本文・追加ラベルをユーザーに提示し、承認を得る。

update_pull_request（owner, repo, pullNumber, body）で本文更新。body パラメータは実改行で渡す（\n リテラル禁止 — プロジェクト規約参照）。

ラベル追加が必要な場合は issue_write の labels に既存ラベル + 追加ラベルを結合した配列を渡す（上書きされるため）。

最後に PR URL を表示。

---

新規 PR 作成フロー

4-N. 作業内容の分析

git log --oneline <default-branch>..HEAD で全コミットを取得し、git diff <default-branch>...HEAD --stat で変更規模を把握する。--stat 合計が大きい場合はファイル単位サマリに留め、Claude が必要と判断したファイルのみ git diff <default-branch>...HEAD -- <file> で個別 Read する。変更概要・影響コンポーネント・関連 Issue を把握する。

5-N. 関連 Issue 探索

優先順位:

1. ブランチ名から issue-(\d+) 正規表現で抽出（例: feature/issue-42-... → 42）
2. 1. で抽出できなければコミットメッセージ本文の #NN 表記を git log で検索
3. 2. でも見つからなければ search_issues で候補を探し、ユーザーに紐づけるか確認

Closes #XX（完全解決時。自動クローズ）または Refs #XX（参照のみ・部分対応）を本文に記載する。地の文で close / fix / resolve 系の語を Issue 番号に直接続けない（意図しない auto-close を避ける。詳細は git-conventions.md）。

6-N. ラベル選定

リポジトリの既存ラベルから変更種別に合致するものを選ぶ。既存ラベル一覧の取得手順:

• list_issues（owner, repo, state: "all", perPage: 30）で取得した結果の labels フィールドからユニーク化する（MCP に list_labels 系がないため）
• プロジェクト側に独自のラベル運用ルール（CLAUDE.md・AGENTS.md・README 等）があればそれを優先する

汎用的な対応指針:

変更種別	推奨ラベル候補（リポジトリに存在するものを使う）
新機能・機能追加	feature, enhancement
バグ修正	bug, fix
ドキュメント	documentation, docs
ビルド・CI・依存	infra, chore, ci
リファクタリング	refactor
テスト	test

リポジトリに該当ラベルが存在しない場合はラベル無しでも可。新規ラベル作成は提案しない。

7-N. PR タイトル・本文作成

タイトル: <type>(<scope>): <日本語説明> — 70文字以内（<type> は smart-commit と同じ feat/fix/docs/refactor/chore/test/perf/style/build/ci）

タイトルの例:

変更概要	タイトル
ユーザー検索 API を追加	feat(api): ユーザー検索エンドポイントを追加
バリデーションの不具合を修正	fix(validation): null 入力時のバリデーション失敗を修正
ログ整形ロジックを抽出	refactor(logger): 整形ロジックを util に抽出
README にセットアップ手順を追加	docs(readme): ローカル開発のセットアップ手順を追加

本文: assets/pr-template.md を使用。まず変更の性質から構成を選ぶ:

構成	対象	内容
標準構成（既定）	機能実装・複数ファイルにまたがる変更・設計判断を含む変更	図・表で実装内容を可視化する: クラス / ファイル構成表、主要フローの mermaid シーケンス図（分岐は alt/else）、構成図（mermaid flowchart・任意）、設計判断表（採用した方針 / 未対応 follow-up）、受入条件 ↔ 検証の対応表
簡易構成	chore / docs / typo / 依存更新・少量の変更など、レビュワー向けに細かい説明が不要な内容	概要・変更内容の箇条書きのみ。図・表などの要素は不要

• 判断に迷う場合は「レビュワーがこの説明なしで diff を読めるか」で決める（読めるなら簡易構成でよい）
• 標準構成でも、各図表は説明価値がある場合のみ使う（埋めるための図表を作らない）
• プロジェクトに PULL_REQUEST_TEMPLATE（.github/ 配下）がある場合はそのセクション構成（レビューポリシー等の独自セクション含む）を骨格にし、標準構成の図表を対応するセクションへ埋め込む

同期ノート: assets/pr-template.md と上記の構成選択ルールは、smart-issue-resolve の「収束後のコミット・PR 作成 → PR タイトル・本文」へ複製している（スキル間ファイル参照ができないため意図的に二重化）。どちらかを変更したらもう一方も同期する。

8-N. ユーザー確認 → 作成実行

タイトル・本文・ラベル・紐づけ Issue・ベースブランチを表示して承認を得る。

承認後:

1. create_pull_request（owner, repo, title, body, head, base）で作成。body は実改行で渡す（\n リテラル禁止）。
2. 戻り値の number を控える。
3. issue_write（owner, repo, issueNumber: <PR番号>, assignees: [<get_me で取得したログイン>], labels: <選定ラベル配列>）でアサインとラベルを設定。

最後に PR URL を表示。

• ドラフト PR はユーザーの明示的指示がある場合のみ（draft: true を create_pull_request に渡す）。
• GitHub Project への自動追加はしない。

コンテキスト管理

長い会話でコンテキスト圧縮が発生した場合、以下を再取得する:

• git remote get-url origin → owner/repo
• git branch --show-current → ブランチ名
• デフォルトブランチ名（Step 1-b の手順）

ただし本スキルは新規セッションでの実行を推奨しており（README 参照）、通常は圧縮が発生しない。

注意事項

• MCP ツールの body パラメータには実改行を含める（\n リテラルは GitHub 上で 1 行表示になる）。Step 6-U / Step 8-N から本注意を再参照すること。
• --no-verify は使わない。
• force push はしない。
• ドラフト PR はユーザーの明示的指示がある場合のみ。