Create Draft Pr

---
name: create-draft-pr
description: PRを作成（原則Draft）。PRテンプレートを全セクション埋めつつ、対象repoの既存PRの実測値（MEMORY_DIR配下にキャッシュ）に分量を合わせ、AI特有の書きすぎを削る。使用タイミング: PR作成を依頼された時、実装が一段落しPR化する時、/create-draft-prで実行。引数にベースブランチを指定可能。境界: 直接gh pr createは実行せず本スキルを使う。特定レビューコメントへの対応はpr-comment、PRレビューはpr-review。
allowed-tools: Bash(git:*), Bash(gh:*), Read, Write
---

# /create-draft-pr

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

## 引数

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

## 実行手順

### 1. 現在の状態確認

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

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

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

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

```bash
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. 変更内容の確認

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

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

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

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

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

```bash
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. キャッシュがなければ実測して書き出す

```bash
# 変更ファイル数と本文長の分布を見る（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 に直書きでもよい）:

```markdown
# 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本文の作成

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

```markdown
## 概要
[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だとバッククォートのエスケープが本文に混入する事故がある）。

```bash
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 がある場合は、指摘を待たず原因調査に入る。

```bash
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側の規定が優先。