/create-draft-pr

PRを作成する。テンプレートのセクションは削らない。ただし各セクションは書きすぎない。 この2つを同時に守るのが本スキルの主眼。

引数

• ベースブランチ名（省略時: PJ CLAUDE.mdのBASE_BRANCH）
• --no-draft: Draft以外で作成する場合に指定

実行手順

1. 現在の状態確認

git branch --show-current
git status --short
git log <base-branch>..HEAD --oneline
git diff <base-branch> --stat

未コミット変更が残っていれば /commit を先に実行する（品質チェックもそこで通す）。

完了基準: 作業ブランチにいて、未コミット変更ゼロ、<base>..HEAD にコミットが1つ以上ある。

2. PRテンプレートの確認

cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || cat .github/pull_request_template.md 2>/dev/null
ls .github/PULL_REQUEST_TEMPLATE/ 2>/dev/null

CRITICAL: テンプレートが存在する場合、すべてのセクションを埋める。セクションを削除しない（レビュアーが記入を前提にした項目が欠けると差し戻しの原因になり、テンプレートの意図が損なわれるため）。該当なしのセクションも見出しを残し「特になし」と1行書く。テンプレート内のHTMLコメント（<!-- ... -->）は消す。

3. 変更内容の確認

git diff <base-branch> --name-only
git diff <base-branch>

4. 分量予算を決める（CRITICAL）

本文を書く前に上限を決める。 AIは放っておくと設計判断・トレードオフ・将来案・テスト実行数まで盛り込み、そのチームの実運用の2〜3倍に膨らむ。

予算はrepoごとに一度実測してキャッシュする。毎回のPR作成で測り直さない。

4-1. キャッシュを読む

cat ${MEMORY_DIR}/context/pr-conventions.md 2>/dev/null   # MEMORY_DIR未定義時: .local/context/
grep -n "pr-conventions\|PR 分量" CLAUDE.local.md 2>/dev/null

あればそこに書かれた上限・セクション別目安・定型フレーズをそのまま使い、4-2を飛ばす。ただし実測日が半年以上前、またはテンプレート自体が変わっている場合は再実測して上書きする。

4-2. キャッシュがなければ実測して書き出す

# 変更ファイル数と本文長の分布を見る（bot・release PRは除いて読む）
gh pr list --state merged --limit 40 --json changedFiles,body,author \
  -q '.[] | select(.body != null) | "\(.changedFiles)\t\(.body | length)\t\(.author.login)"' | sort -n

そのうえで今回と同規模（変更ファイル数が近い）のPR 2〜3件を実際に読み、粒度と長さをそれに揃える。author別に差がある場合は、レビュアー層に受け入れられている多数派に合わせる。

測った結果は ${MEMORY_DIR}/context/pr-conventions.md に次の形で残す（.local/ はglobal gitignore済みでコミット不要。CLAUDE.local.mdに直書きでもよい）:

# PR 分量規約（実測キャッシュ）

実測日: YYYY-MM-DD / 対象: <owner>/<repo> merged PR n件（bot・release除く）

## 本文長の上限（チェックリスト部を除く、実測の中央値）
| 変更ファイル数 | n | 中央値 | 上限として使う値 |
## セクション別の中央値
## テンプレの必須セクション・チェックリストの扱い
## そのrepoの定型フレーズ・PRの型

完了基準: キャッシュファイルが存在し、今回使う上限値がそこから引けている。

4-3. どちらもできないときの初期値

PRが少ない・新規repo等でキャッシュも実測もできない場合:

変更ファイル数	本文（チェックリストを除く）の上限
1-3 files	1,500字
4-9 files	2,000字
10-30 files	2,500字
31+ files	3,500字

セクション別の目安（キャッシュに記録がなければこれを使う）:

セクション	目安	書き方
概要	1〜2文	「〜する」で言い切る。背景は書かない（動機へ）
動機	1〜2段落	現状の問題 → 放置した場合の影響。自明なら1文
やったこと	3〜5項目	1変更=1行。path + 何をしたか
やらなかったこと	1〜2行	原則「特になし」。スコープ外があるときだけ理由を1行添える
影響範囲	1〜3行	画面・エンドポイント・経路の列挙。無影響なら「挙動に変化なし」
テスト方法 / 使い方	1〜3行	検証コマンド1行 or 番号手順3つまで
関連リンク	リンクのみ	チケット・スレッド・公式docs。無ければ「なし」
チェックリスト	補足なし	[x] を付けるだけ

完了基準: 書き上げた本文の文字数が上限内に収まっている。

5. PR本文の作成

テンプレートがあれば使用、なければ以下:

## 概要
[1〜2文]

## やったこと
- 変更1
- 変更2

## やらなかったこと
- スコープ外の内容（なければ「特になし」）

## 影響範囲
- 影響を受ける画面・処理

## テスト方法
[動作確認方法]

## チェックリスト
- [ ] 型チェック通過
- [ ] Lint通過
- [ ] テスト通過

文体は /ukwhatn-writing のGitHub向けガイド（PR概要欄）に従う。箇条書きは体言止め・常体、地の文は敬体。パス・関数・設定値・コマンドは ` で囲む。事実は断定、推測・提案だけぼかす。

チェックリストは事実を確認してから [x]（依存追加・スキーマ変更・環境変数・migrationの有無をdiffで確認する。虚偽チェック禁止）。補足を書くのは2ケースだけ:

• [ ] のまま残すとき（理由と後追いの合意を1行）
• 該当ありでレビュアーが判断に迷うとき（1行）

読みやすさ: 1つの箇条書きに複数の論点を詰め込まない。What+Why+詳細が1文に連なって長くなる場合は文を分割し、設定値・理由・根拠はネストした箇条書きに移す。項目が多く雑多になったら ### 小見出しでグループ化する。

6. 削る（AIの書きすぎを落とす）

書き終えたら、以下を上から順に検索して消す。いずれもレビュアーの判断材料にならず、本文を長くするだけ。

消すもの	代わりに
実装の設計判断・採用理由の解説段落	判断を仰ぐものだけ「レビュー時チェック」相当に1行
トレードオフ・将来の代替実装案（「必要になれば〜に切替可能」）	書かない。指摘されたら返信で書く
テスト実行結果の数値羅列（「N suites / M tests green」）	「関連テストgreenを確認」1行、または実行コマンド1行
やったこと各項目にぶら下げた2〜4行の解説	1項目1行。非自明な1点だけネスト1行
チェックリスト各項目への長い根拠説明	[x] のみ（例外は手順5の2ケース）
「〜することが可能です」「〜に関しまして」等の硬い言い回し	「〜できます」「〜について」
概要内の背景説明・まとめの再説明	概要は1〜2文。背景は動機に1回だけ
セクション末尾の要約・結び	書かない

完了基準: 上表8項目の該当がゼロ、かつ手順4の上限内。

7. PR作成

本文はファイルに書き出して --body-file で渡す（heredocだとバッククォートのエスケープが本文に混入することがある）。

gh pr create --draft \
  --base <base-branch> \
  --title "<タイトル>" \
  --assignee @me \
  --body-file <scratchpad>/pr-body.md

CRITICAL: --assignee @me を必ず付ける（未アサインのPRはレビュー担当・追跡の割り当てが漏れるため）。 --no-draft 引数が指定された場合のみ --draft を外す。reviewerがCODEOWNERS等で自動付与されるrepoでは --reviewer を指定しない。別ディレクトリ・worktreeから実行するときは --repo <owner>/<repo> を付ける。

完了基準: gh pr view <n> --json isDraft,assignees,baseRefName でDraft / assignee / baseを確認できている。

8. CIとconflictの確認

CIの結果とconflictの有無を自分で確認してから報告する。走行中なら完了まで監視する。失敗している・conflictがある場合は、指摘を待たず原因調査に入る。

gh pr view <n> --json mergeable,mergeStateStatus,statusCheckRollup

完了基準: CIが結論（success / failure）に達しており、mergeable を確認済み。走行中のまま報告していない。

9. 結果の報告

PRのURL、base、Draftか、本文の文字数（予算に対して）、CIとconflictの状態を1〜3行で報告する。

---

PRの型

• 同期PR（同一変更を複数ブランチへ入れる）: タイトル先頭に宛先を置き（[to main] / [to develop] 等）、本文はメインPRへのリンク1行で足りる。差分（conflict解消・追加変更）が入ったときだけ、その差分を書く。メインPR側の末尾に「同時マージ依頼」を太字で置く
• スタックPR（他PRをベースにする）: 概要直後にblockquoteでベースPRと、分けた理由を1行
• 複数repoにまたがる変更: 概要直後に相手側PRを相互リンクし、マージ順・デプロイ順の前後関係があれば1行添える
• テンプレートのないrepo: 概要 / やったこと / 影響範囲 の3見出し程度に留める
• 運用作業を伴うPR（マージ後に手動適用が必要等）: 冒頭にGitHub alertで明示する

  > [!IMPORTANT]
  > マージ後に <適用作業> を実施します
  

PJ固有の運用ルール

hotfix等で複数のベースブランチへのPR作成運用（sync PR等）、リリースPRの作成手順がPJ固有で定義されている場合は、PJ側スキル・ドキュメントの指示を優先すること。テンプレートの必須セクション・チェックリストの解釈もPJ側の規定が優先。