Create pr

create-pr

カレントブランチから Conventional Commits 形式の PR を作成する。ユーザー確認は一切行わず、分析完了後は直接 PR 作成を実行 (frontmatter の disallowed-tools: AskUserQuestion で構造的にも強制)。既定は --draft(呼び出し側が ready for review・出荷用等を明示指定した場合のみ付けない)、positional argument は [base-branch] のみ。

現在の git 状態 (skill 読み込み時に自動取得)

!git status -sb

!git log --oneline -15

上 2 行は Claude Code が skill 読み込み時に実行し結果へ置換する (読み取り専用・冪等)。バッククォート付きの生コマンド文字列のまま見えている場合 (注入非対応環境) は、Step 1 で同コマンドを Bash 実行して取得する。

Task complexity tier

Tier	判定	Step 9 セルフチェック	その他
lite	1 commit, <50 LoC, single domain, 既存 pattern 踏襲	[A] 斜め読み + [D] AI 臭 の 2 観点	Step 4b (周辺コード比較) 省略可。Pre-work 本質リストは 1-2 点
standard (default)	2-5 commits, multi-file, single domain	[A] + [B] + [C] + [D] の 4 観点 (現状)	Step 1-10 を順次実行。Pre-work 本質リストは 2-3 点
deep	multi-domain / breaking change / 6+ commits / migration	4 観点 + 関連 PR 検索 + 既存 issue リンク	Step 4c で plan 全展開、Pre-work 本質リストを 最低 5 点・上限 7 点 に拡張 (5 に届かない場合は domain ごと / PR チェーン段階ごと / migration / observability / rollout / rollback の観点で分解して 5 点まで埋める)

リスク領域 (auth / billing / payment / migration / security config) は LoC・commit 数によらず deep。draft/ready の判定は tier に依存しない (lite でも既定は --draft、呼び出し側の明示指定時のみ ready)。tier 判定の評価時点は Step 1 の git log [base-branch]..HEAD 時点 — Step 2 で未コミット分から作る commit は commit 数に数えない (数えると未コミット 1 ファイルの軽微変更が lite から外れてしまうため)。

deep tier の追加規約:

• 本質リスト 5+ の解釈: standard tier では scope 過大の兆候、deep tier では正常な分解結果。読み分けの詳細は references/description-style.md「Pre-work: 本質リスト」末尾を SSOT とする (本 tier 表は点数の SSOT)。
• BREAKING CHANGE footer 位置: PR テンプレに専用 footer 見出しがあればそこ。無ければ本文末尾の独立 footer として BREAKING CHANGE: <description> を「Revert 手順」見出しの直前に配置 (Conventional Commits の footer 慣例。## やらなかったこと の直後・本文セクション群の外側)。テンプレ内の <!-- ... --> コメントは削除しない。

Arguments

• $ARGUMENTS: [base-branch] [詳細展開指示...]（いずれも省略可）
  • 先頭トークンがリモートブランチとして存在すればベースブランチ（確認: git ls-remote --heads origin <トークン>。省略時はリポジトリのデフォルトブランチ）
  • 残り（または全体）は詳細展開指示として解釈する（例: /create-pr develop 設計判断は詳しく）。詳細展開指示はセッション中のユーザー発話でも受け付ける（Step 6 参照）
  • draft/ready 指定（例: 「ready for review で」「出荷用」）も詳細展開指示と同様、$ARGUMENTS またはセッション中の発話で自然文として受け付ける（Step 10 参照。既定は draft）

委譲実行 (subagent として起動された場合)

Task ツールで委譲された場合は、まず references/delegated-execution.md を読み、既定手順への読み替え (Step 4c/6 の情報源・AI Contribution 判定・ブランチ状態が複雑な場合・gh ホスト解決失敗時の縮退) を適用する。単独起動時の現行動作は変えない (この節はスキップしてよい)。

Quick start

最短経路:

1. Step 0: PR テンプレートを動的検索 (references/template-discovery.md) → ベースブランチ確定
2. Step 1: 冒頭の自動取得結果 (status -sb = ブランチ + 未コミット / log) を使い、base-branch 依存の git log [base-branch]..HEAD --oneline / git diff [base-branch]...HEAD --stat のみ実行 (自動取得が生コマンド文字列のままなら git status -sb / git log --oneline -15 も Bash 実行)。ローカルに [base-branch] ref が無ければ git fetch origin [base-branch] 後に origin/[base-branch] で比較する
3. Step 1.5: ブランチ妥当性検証 (references/branch-validation.md)。違反なら コミット前 に git switch -c で新ブランチ切替 (コミット後 rename は GitHub API 副作用で PR が CLOSED されるため不可)
4. Step 2: 未コミットファイルがあれば 1 コミット = 1〜3 ファイル粒度で <type>(<scope>): <日本語要約> 形式コミット
5. Step 3: git push -u origin <branch>
6. Step 4-8: タイトル / 本文 / ラベル生成 (後述)
7. Step 9 (必須): references/description-style.md のセルフチェックを tier 表の観点セットで必ず実施 (tier が指定する観点の省略禁止。観点セットと deep の関連 PR 検索は下記 Workflows Step 9)
8. Step 10: 対象ブランチに open PR が無ければ gh pr create (既定 --draft)、既に open PR があれば gh pr create はスキップし push 後 gh pr edit --body-file で本文更新 (コマンド全文と draft/ready 判定は下記 Workflows Step 10)

PR URL を表示して完了。

Workflows

Step 4: コンテキスト収集

• 4a: 不足あれば git diff [base-branch]...HEAD で詳細確認
• 4b: 周辺コードと既存パターン比較。差異あれば理由・却下した代替案を整理
• 4c: 本セッションの plan / 設計議論から「背景 / 設計判断 / やらなかったこと」を抽出 (~/.claude/plans/ ファイル走査は不要)

Step 5: タイトル生成

<type>(<scope>): <description> (72 文字以内・日本語)。

• type: feat / fix / docs / style / refactor / perf / test / chore / ci / build
• 複数 type 混在: 最も大きな価値変化を生む 1 つを採用。優先順位 feat > fix > refactor > perf > test > chore > docs > style > ci > build
• scope: 変更主ドメインの単数形英小文字 (モデル / コントローラ prefix 流用が基本)。複数ドメインなら中心価値の 1 つ、均等で絞れなければ省略。docs / chore / ci でドメイン無しなら省略
• タイトル prefix: 呼び出し側が prefix (例: [DONOTMERGE]) を明示指定した場合、<type>(...) の直前に半角スペース区切りで付与する。72 文字カウントは prefix 込みで数える

Step 6: 本文生成

検出した PR テンプレートのセクション構成に従う。下記の要点で書ける lite-tier は inline 完結でよい。standard / deep tier、または初めて本 skill を使う場合は references/description-style.md を Read（NG/OK 例対比・Pre-work の具体手順・1 行サマリーの書き方が必要になるため）。要点:

• Pre-work (mandatory): 本文を書く前に PR の本質を bullet リスト (点数は tier 表が SSOT) として scratch 出力 → 「このPRでやること」型の本質列挙系セクションがあればそこへ番号リストで貼る。無ければ tier によらず「やったこと」1 文に畳み込む (番号リスト格上げは本質列挙系セクション実在時のみ。分岐の詳細は description-style.md「Pre-work」節が SSOT)
• 6 文体鉄則: コードから読めることは書かない / 斜め読み構造 / 重複禁止 / 常体 / 書かない勇気 / 読み直し
• セクション分量 (既定 = 1 行サマリー):
  • 定型 (Revert 手順 / チェックリスト) → テンプレ準拠
  • それ以外の全セクション → 1 行サマリーのみ (bullet・複数文段落・表・コードブロックを書かない。該当事実がなければ見出し+空行)。行数の例外は本質列挙系セクションの番号リストと「やらなかったこと」の 1 項目 1 行のみ
  • 詳細展開はユーザーが明示指示したセクションだけ ($ARGUMENTS またはセッション中の発話。例: 「設計判断は詳しく」)。指示されたセクションはサマリー行の直下に散文展開を追加する。棄却案・実測表などの素材が session にあっても、自己判断では展開せず完了報告で「展開可能」と伝える (詳細は description-style.md「分量の既定」節)。指示対象のセクションが解決済みテンプレート (フォールバック構成含む) の見出し集合に無い場合は新規見出しを追加せず、references/description-style.md「テンプレートに無い見出しに相当する議論の反映先」節の手順 (代替見出しへの要約、それも無ければ本文非反映 + 完了報告での提示) に従う
• 本文冒頭の注記: 呼び出し側が本文冒頭の注記 (例: merge しない参照用) を明示指定した場合、テンプレ本文の最初の見出しより前に独立した 1 行として挿入する (新規見出しは追加しない)
• テンプレ内 <!-- ... --> コメントは削除しない (migration 無しでも rollback サンプルブロックを残す)
• テンプレに無い見出しは追加しない

Step 7-8: ラベル・マイルストーン

詳細は references/labels-and-milestones.md を参照。~/.claude/skills-config/release-labels.md を Read し以下 3 種を 1 つずつ選択:

1. Productivity ラベル (productivity_labels)
2. AI Contribution ラベル (ai_contribution_labels): セッション内で AI が PR 差分コードを生成・変更したか
3. Release Level ラベル (release_level_labels): db/migrate/ 配下があれば最高 / 根幹機能 + 体感変化なら高 / 後方互換なら中 / 表示文言のみなら最低

release-labels.md が無ければラベル付与をスキップし、設定方法を案内する (リポジトリ root の scripts/setup.sh 実行、または ~/.claude/skills-config/release-labels.md を手動作成。サンプルは examples/skills-config/。npx skills add 経由では plugin 内に scripts/ が無いため裸の相対パス案内をしない)。マイルストーンは関連 Issue 由来、それ以外は Untracked (存在確認は gh api repos/{owner}/{repo}/milestones --paginate --jq '.[].title' で行う。per_page=100 でも 100 件超リポジトリでは漏れるため --paginate 必須。無ければ --milestone 省略)。

Step 9: セルフチェック (投稿前必須)

references/description-style.md の「Step 9 セルフチェック」を tier 表の観点セット (lite = [A]+[D] のみ / standard = 4 観点 / deep = 4 観点 + 関連 PR 検索) で実施。deep の関連 PR 検索は gh pr list --state all --search "<検索語>" / gh issue list --state all --search "<検索語>" で行う (検索語 2 語 = scope の英語名 + タイトル主要名詞の日本語 × pr / issue の 2 コマンド = 計 4 回)。ヒットしたら「関連 Issue」セクションの related - を 1 行リンクで置換 (併記しない)、0 件なら本文変更なし。1 つでも該当があれば修正:

• [A] 斜め読みテスト: 各セクション 1 行目だけで PR 意図再構築可能か / 本質リスト (点数は tier 表) と一致か (判定基準は description-style.md「Pre-work」節が SSOT — 各点が分配先セクション込みで復元可能か) / plan 由来 internal 語彙 (α 層 / AC-9 / Critical-A 等) が残っていないか
• [B] コードから読める情報の混入: ファイル名・関数名・パラメータ追加・import 等が簡潔セクションに残っていないか
• [C] 分量・重複 + 「やらなかったこと」事実整合: 「やったこと」と「なぜやるのか」の事実重複 / 各セクションが 1 行サマリーを超えていないか (bullet 化・複数文段落・表・コードブロックの混入) / 詳細展開がユーザー指示なしに行われていないか (指示があったセクションは逆に 1〜2 行で済まされていないか) / 動作確認結果のケース列挙 / 「やらなかったこと」各項目が最終 diff と整合するか (スコープ外として正しいか・先送りが本 PR で確定すべきものでないか。詳細は description-style.md「投稿前の事実整合チェック」)
• [D] AI 臭: 「以下に〜を示す」「具体的には」「適切に」等の生成検出語 / 太字 bullet 3 つ以上 / 機械的絵文字 / 「〜のため」段落内 2 回以上 / 「特になし」埋め文 / 矢印チェーン等の作業中 shorthand (詳細は description-style.md [D])

Step 10: PR 作成 (新規 / 既存更新)

既存 PR の確認: gh pr list --head <branch> --state open --json number,url で対象ブランチの open PR を確認する。1 件あれば gh pr create をスキップし、push 後に gh pr edit --body-file で本文を更新する (本文更新が不要なら push のみで終える。手順は references/post-create-edit.md の gh pr edit --body-file → 失敗時のみ REST API フォールバックに従う)。0 件なら新規作成に進む。完了報告には作成 / 更新した PR の URL を含める。

draft / ready の判定: 既定は --draft。呼び出し側が「ready for review」「出荷用」等を明示指定した場合のみ --draft を付けずに作成する。

下記コマンド例の --label は 3 種のプレースホルダで、実値は Step 7-8 で Read した ~/.claude/skills-config/release-labels.md の該当リストから選んだラベル名に置き換える。

--body-file を統一採用 (--body "$(cat ...)" 経路は使わない)。$PR_BODY_FILE は mktemp でユニークパス生成 + コマンド完了後に削除 (references/post-create-edit.md の「固定パス禁止」参照)。固定パス /tmp/pr-body.md は過去セッション残骸混入事故源で禁止。

PR_BODY_FILE="$(mktemp -t pr-body-XXXXXX.md)"
# (本文を $PR_BODY_FILE に書き出した後)
gh pr create --draft \
  --title "feat(order): 注文確定後の通知機能を追加" \
  --body-file "$PR_BODY_FILE" \
  --label "<productivity-label>,<ai-contribution-label>,<release-level-label>" \
  --milestone "Untracked" \
  --base develop
rm -f "$PR_BODY_FILE"

ready 指定時は上記コマンドから --draft を省く。既存 PR を更新する場合は gh pr create の代わりに gh pr edit <number> --body-file "$PR_BODY_FILE" を使う。

Advanced

• references/template-discovery.md — PR テンプレート 7 段階優先順位 / ベースブランチ 3 段階フォールバック
• references/branch-validation.md — ブランチ妥当性検証 (同名禁止 / conventional prefix / プロジェクト規約) と自動切替
• references/description-style.md — 文体 6 鉄則 / 1 行サマリー既定と詳細展開指示 / Pre-work 本質リスト / Step 9 セルフチェック [A]-[D]
• references/labels-and-milestones.md — ラベル 3 種判定基準 / Untracked マイルストーン事前確認
• references/post-create-edit.md — 作成後の description 更新 (gh pr edit --body 失敗回避) / mktemp 規約
• references/delegated-execution.md — Task 委譲実行時の手順読み替え (情報源 / AI Contribution 判定 / gh ホスト解決失敗時の縮退)
• references/stacked-pr-base.md — 積み PR の base 選定と後始末 (retarget 確認 / reopen / rebase)

注意事項

全内容を日本語で記述 / 既存コミット全てを考慮 (最新だけでない) / セキュリティ・パフォーマンス影響を考慮 / 完了時に PR URL を表示し、詳細展開できる素材が残るセクションがあれば「設計判断: 棄却案 2 件を展開可能」のように列挙する (展開はユーザー指示後、references/post-create-edit.md の手順で本文更新)。

Gotchas（観測済みの罠 — 実測で判明したものを 1 件 1 行で追記）

• 積み PR (open PR を持つ前段ブランチから派生したブランチ) の base: base をデフォルトブランチでなく前段ブランチにすると diff が自タスク分に絞れる。ただし前段 merge 後の base 自動付け替え確認・close 時の reopen・squash merge 時の rebase が必要 (詳細は references/stacked-pr-base.md)

併用推奨 skill

• /review-plan-diff — PR 作成前に、確定プランと実装後の diff を突き合わせ、実装漏れ・計画外差異を検出しておく（前段）
• /polish-before-commit — コミット前にプロジェクト規約・パターン一貫性を仕上げてから本 skill を起動
• /finalize-plan — プランを実装可能形式に変換し、その流れで本 skill を呼ぶ
• /purge-private-vocab — PR description 生成後に plan 内造語を点検