create-pr

カレントブランチをもとに、Conventional Commits形式のタイトルと、リポジトリに存在する PR テンプレート（ステップ 0 で動的検索）に従った説明を持つドラフトPRを作成してください。

重要: ユーザーへの確認は一切行わず、分析完了後は直接PR作成を実行すること。

Arguments

• $ARGUMENTS: ベースブランチ名（省略可）
  • 指定あり: そのブランチを base として PR を作成
  • 指定なし: リポジトリのデフォルトブランチを使用

実行手順

0. 前準備

   0a. PR テンプレートの検索 カレントブランチが属するリポジトリのテンプレートを動的に検索する（固定パス禁止）。

   • git rev-parse --show-toplevel でリポジトリルート <repo> を取得
   • 以下の優先順位で最初に存在するファイルを採用:
     1. <repo>/.github/PULL_REQUEST_TEMPLATE/engineer.md
     2. <repo>/.github/PULL_REQUEST_TEMPLATE/default.md
     3. <repo>/.github/PULL_REQUEST_TEMPLATE/ 配下の最初の *.md（アルファベット順）
     4. <repo>/.github/PULL_REQUEST_TEMPLATE.md
     5. <repo>/.github/pull_request_template.md
     6. <repo>/docs/PULL_REQUEST_TEMPLATE.md
     7. <repo>/PULL_REQUEST_TEMPLATE.md
   • 見つかったパスを控え、以降のステップ 6 で Read してセクション構成を把握
   • どれも見つからない場合はフォールバック構成（## やったこと / ## なぜやるのか / ## 動作確認結果）を使用

   0b. ベースブランチの確定

   • 引数 [base-branch] が指定されていればそれを使用
   • 指定が無ければカレントリポジトリのデフォルトブランチを取得:
     1. gh repo view --json defaultBranchRef --jq .defaultBranchRef.name（主手段）
     2. 失敗時は git symbolic-ref refs/remotes/origin/HEAD --short | sed 's@^origin/@@' にフォールバック
     3. いずれも失敗したら main を使用（最小フォールバック）
   • 以降のステップで [base-branch] と記載されている箇所は、ここで確定した値に置換して実行

1. 情報収集（並列実行） 以下のコマンドをすべて並列で実行：

   • git status（未コミットファイルの確認）
   • git branch --show-current（カレントブランチ名）
   • git log [base-branch]..HEAD --oneline（コミット一覧）
   • git diff [base-branch]...HEAD --stat（差分の概要）

   1.5. カレントブランチの妥当性検証（必須・コミット前に実行）

   ステップ 1 で取得したカレントブランチ名を、以下の判定基準で検証する。いずれかに該当する場合は新ブランチに切替必須:

   1. 同名禁止: カレントブランチが [base-branch] と同一（例: develop チェックアウト中で base が develop）
   2. 規約違反: カレントブランチ名が conventional prefix を持たない。conventional prefix は以下のいずれか:
      • feature/ / feat/
      • fix/
      • refactor/
      • docs/
      • chore/
      • test/
      • perf/
      • style/
      • ci/
      • build/
      • 例: omo/gtr-2, wip-test, tmp, worktree ディレクトリ名そのまま等は 規約違反として扱う
   3. プロジェクト規約違反: リポジトリの .github/CLAUDE.md / <repo>/CLAUDE.md / <repo>/.claude/rules/git-branch*.md にブランチ命名規約が明記されている場合、それに従わないブランチ名は規約違反として扱う（前準備として該当ファイルを Read で確認）
      • 「命名規約明記」の定義: ブランチ名の prefix / pattern / 正規表現 がファイル内で明示されていること（例: feature/機能名, ^(feat|fix|refactor)/.+）
      • base ブランチ指定のみ（例: 「PR base は develop」）は 命名規約ではないため、本判定では対象外

   該当時の自動切替手順:

   1. ステップ 1 の git diff [base-branch]...HEAD --stat と git status の出力から 変更ドメイン を推定
      • diff 取得方法: HEAD==base または uncommitted のみのケースでは git diff [base-branch]...HEAD --stat が空を返すため、git diff --stat（unstaged）と git diff --cached --stat（staged）の 合算 で最大 dir / module 名を採用
      • scope 候補の優先順位 (複数候補が同程度のとき):
        1. ユーザ向け価値を生む機能ドメイン を優先 (例: order / license / auth)
        2. 技術手段 は非優先 (例: mailer / flipper / middleware は scope にしない)
        3. モデル名 / コントローラ名の prefix がある場合はそれを採用 (ステップ 5 の scope 規則と整合)
   2. ステップ 5 の type / scope 決定ロジックを前借りして branch 名を組み立てる:

      <type>/<scope>-<short-desc-kebab-case>
      

      • <type>: ステップ 5 の type 優先順位（feat > fix > ...）から仮選定
      • <scope>: 上で推定した変更ドメイン
      • <short-desc-kebab-case>: 変更の主目的を英小文字 kebab-case で 2〜4 単語
   3. 生成例:
      • 注文確定通知メーラー追加 → feature/order-notification-mailer
      • 認証 token rotation バグ修正 → fix/auth-token-rotation
      • rubocop 違反修正 → refactor/rubocop-cleanup
   4. git switch -c <new-branch-name> を実行
   5. 切替後、ステップ 1 の git branch --show-current を再取得（以降のステップで使う）

   該当しない場合: そのまま続行（既に feature/order-notification 等で正しいブランチ名を持っている場合は no-op）

   重要事項:

   • 切替はコミット前に実行する。コミット後の rename は GitHub Branch Rename API の副作用で関連 PR が CLOSED されてしまう事故が観測されている。事後に修正する手段は「force push」または「PR 再作成」のみで、いずれも reviewable な PR 履歴を損なう
   • git switch -c で切替できる前提として、ステップ 1 の git status で worktree が clean か uncommitted のみであることを確認しておく（merge / rebase の最中などで状態が複雑な場合はユーザに状況確認を促す）

2. 未コミットファイルのコミット（必要な場合のみ） ステップ1で未コミットファイルがあれば、以下のルールに従ってコミットを作成：

   コミット粒度

   原則: 1コミット = 1〜3ファイル

   • 同一ディレクトリ・同一役割のファイル群: まとめてOK
   • 実装とテスト: 原則分離（実装 → テスト）
   • 異なるレイヤー: 分離（controller, service, model等）
   • 設定ファイル: 独立してコミット

   コミットメッセージ形式

   <type>(<scope>): <日本語の要約>
   

   • type: feat, fix, refactor, test, docs, chore
   • bodyは原則不要（粒度が小さければ不要）

   手順

   1. git diffで変更内容を確認（並列実行可）
   2. 変更を論理単位に分類
   3. 各単位ごとにgit add → git commit

3. リモートへのプッシュ

   • git push -u origin <current-branch>
   • 既にプッシュ済みならスキップ

4. コンテキスト収集（以下のサブステップを順に実施）

   4a. 差分の詳細分析（必要な場合のみ）

   • ステップ1の情報で不足があればgit diff [base-branch]...HEADで詳細確認
   • 変更の種類、影響範囲、主要な変更点を判断

   4b. 既存パターンとの比較（設計判断が必要な変更の場合）

   • 変更対象の周辺コードを確認し、既存のパターンを把握
   • 今回の実装が既存パターンと異なる場合、その理由を整理
   • 検討した代替案があれば、却下理由を整理

   4c. セッションコンテキストからのプラン情報の取得

   • 本セッション内で plan モードや設計議論を経ている場合、その会話コンテキストから以下を抽出してPR説明に反映:
     • 「概要」「背景」に相当する議論 → 「なぜやるのか」に反映
     • 「設計判断」「変更方針」に相当する議論（既存パターンとの比較・却下した代替案・トレードオフ）→ 「設計判断」に反映
     • 「やらなかったこと」「スコープ外」として明示された議論 → 「やらなかったこと」に反映
   • セッション内でプラン情報に相当する議論が無い場合はスキップ（4b の情報を使用）
   • ファイルシステム（~/.claude/plans/ 等）の走査は不要。plan → 実装は同一セッションで完結する前提

5. PRタイトルの生成

   • Conventional Commits形式：<type>(<scope>): <description>
   • タイプ: feat, fix, docs, style, refactor, perf, test, chore, ci, build
   • 72文字以内
   • 日本語で記述
   • scope の決定ルール:
     • 変更の主ドメイン名を単数形の英小文字で記述（例: contract, user, payment）。モデル名・コントローラ名の prefix を流用するのが基本
     • 複数ドメインにまたがる場合の判定: PR の中心価値を生む 1 ドメインがあれば、そのドメインを scope にする（例: auth + infra + docs に跨る PR でも、中心価値が「auth 入口の委譲」なら scope は auth）。領域が均等に跨ぎ中心価値を 1 つに絞れない場合のみ scope を省略し <type>: <description> にする
     • docs / chore / ci のようにドメインが無い変更は scope を省略する（docs(readme): のような細分化はしない）
   • 複数 type 混在の場合の type 決定:
     • 1 PR に複数の type が含まれる場合（例: feat + refactor + chore + docs）、最も大きな価値変化を生む 1 つを採用する
     • 優先順位: feat > fix > refactor > perf > test > chore > docs > style > ci > build
     • 判定基準: ユーザに体感できる新機能・挙動変化があれば feat / fix。純粋な依存削除・責務移動のみなら refactor。compose / README のみなら chore / docs。複数機能が組み合わさって 1 つの価値を生むなら feat

6. PR説明の作成

   • ステップ 0 で検出したテンプレートを Read で読み込み、そのセクション構成に従う
   • テンプレートのセクションは「簡潔」「詳細」「定型」の 3 タイプに分類して分量を決める（下記の対比表に従う）

   ◆◆ 文体原則（最優先・他のすべてのルールに優先する）◆◆

   PR description はレビュアーが最初の3秒で「読む気が起きるか」を判定する場所。 斜め読み（各セクション1行目だけ）で PR 意図が掴めない description は、その後のコードレビュー解像度を下げる（「整理せず投げる人」バイアスがかかる）。

   鉄則（この6つだけを守る）

   1. コードから読めることは書かない（最優先）: PR description はレビュアーが diff を開く前の地図。diff を見れば分かる事実（変更ファイル名・追加した関数名・パラメータ追加・import 追加・helper 名・削除した依存モジュール名など）は description に書かない。description に書くべきは コードからは読めないもの（PR 全体の意図、利用者目線の動機、設計判断の理由・代替案・トレードオフ、スコープ外と判断した範囲）に絞る。「設計判断」「やらなかったこと」の 2 セクションだけ詳細に書き、それ以外は 1 行で済ませる
   2. 斜め読みで意図が掴める構造: 各セクション1行目だけで PR の全貌を再構築できること（後述「セクション構造ルール」参照）
   3. 重複禁止: 同じ事実を2箇所に書かない。特に「やったこと」と「なぜやるのか」の言い換え重複に注意（事実=手段、なぜ=利用者目線の動機）
   4. 常体・動詞で締める: 「だ・である調」統一。「〜実装した」「〜採用した」など動詞の終止形で締める。敬体禁止
   5. 書かない勇気: 該当しないセクションは見出し+空行で残す。「特になし」「該当なし」「適切に対応」のような埋め文は禁止。原則として詳細セクション（設計判断 / やらなかったこと等）が対象だが、簡潔セクションの「動作確認結果」「レビューしてほしい観点」も trivial change（typo / コメント / 文言修正）で該当事実が自明に無い場合は固定 fallback または空欄を選んでよい（捏造的な fill-in より明示的な不在表明が信頼を生む）
   6. AI生成の初稿を声に出して読み直してから投稿: 違和感のある語を自分の言葉に直す。読み直しスキップした description は AI 臭で読まれない

   NG表現（出たら書き直し）

   • 常時禁止: 「以下に〜を示す」「具体的には」「ポイントとして」「重要なのは」「適切に」「効率的に」「最適な」「〜と考えられる」「〜と思われる」
   • 同一段落で2回以上禁止: 「〜のため」「〜することで」「〜することにより」（句読点直前の節末理由用法のみが対象。〜のために動作するのような名詞用法は対象外）
   • 装飾の機械使用禁止: ⚠️ 📝 🔧 ✅ 🎯 などをセクションマーカーとして連発しない / 「〜について」を小見出しに連発しない / **強調**: 形式の太字bullet は1セクション最大2つまで

   NG / OK 対比例（実 PR ベース）

   NG（PR #486 のオリジナル / bullet 羅列、ファイル名・技術ディテール羅列）:

   ## やったこと
   - `proxy.ts`: `/auth` を常に taimei-auth へ redirect する分岐を追加 (cookie 検証スキップ)。`signUpUrl` パラメータを追加し sign-up 完了時に `/auth/after-signup` に着地させる。`redirectToAuth` helper で URL 組み立ての重複を排除
   - `proxy.ts` + `package.json` + `bun.lockb`: `better-auth` 依存を削除。`getSessionCookie` を Next.js 標準 cookie API + cookie 名 hardcoded (auth-guard.ts と同じ pattern) で置き換え
   

   OK（bullet 列挙せず 1 行で意図のみ）:

   ## やったこと
   /auth 入口を常に taimei-auth へ委譲し、better-auth 依存と auth compose を taimei から剥がした。
   

   差分:

   • 1 行で PR 全体の意図を言い切る（タイトルの文章化）
   • 変更ファイル名・追加 helper・置換 API・削除依存などコードから読める情報は全て排除
   • 採用パターン名（auth-guard.ts と同じ pattern 等）は「設計判断」セクションへ詳細に退避、無ければ捨てる

   セクション分量対比表

   タイプ	分量目安	該当セクションの判定	空欄許容
   簡潔	全項目 1 行で完結させる（bullet を並べない）。「やったこと」「なぜやるのか」「レビューしてほしい観点」「動作確認結果」いずれも 1 文・1 段落で言い切る。コードから読める事実（変更ファイル名・関数名・パラメータ追加・import 追加など）は書かない。複数項目を列挙する見出し（複合 Issue / Design Doc リスト等）でのみ bullet を使用	ステータス報告系（関連 Issue / やったこと / なぜやるのか / レビューしてほしい観点 / 動作確認結果 等）	原則不可（必ず埋める）。ただし trivial change 例外: 変更が typo / コメント / 文言修正のみで実行検証や追加レビュー観点が自明に存在しない場合に限り、「動作確認結果」「レビューしてほしい観点」は (a) 1 行固定 fallback（動作確認結果: 目視確認のみ / レビューしてほしい観点: 自明な観点なし）、または (b) 詳細セクション同様 見出しのみ残し空欄、のいずれかを許容。「やったこと」「なぜやるのか」は trivial であっても必ず 1 行で埋める（変更意図と動機はコードから読めないため省略不可）
   詳細	「設計判断」「やらなかったこと」の 2 セクションだけ必ず詳細に書く（コードから読めない情報を持つため）。理由・代替案・トレードオフ・スコープ外の判断根拠を散文で展開。その他の詳細セクション（背景 / 影響範囲 等）は該当時のみ散文中心、太字bullet は 1セクション最大2つまで	説明・議論系（設計判断 / やらなかったこと（コードから読めない・該当事実があれば詳細記述必須）/ 背景 / 影響範囲 等）	「設計判断」「やらなかったこと」も該当事実が無ければ見出しのみ残して空欄可。「特になし」と書かない
   定型	テンプレ準拠	Revert 手順 / セルフレビューチェックリスト 等、テンプレに箇条書き・チェックリストが埋め込まれている見出し	不可

   テンプレートに無い見出しは追加しない。テンプレートに有る見出しは削除せず、空欄の場合も残す。

   ◆ テンプレート内 HTML コメント (<!-- ... -->) の扱い

   • テンプレートに含まれる <!-- ... --> コメントは 原文をそのまま残す（説明・プレースホルダ・サンプルが含まれており、削除すると後続レビュアーへの注意書きが失われる）。
   • 該当例: <!--命名が適切かなど…--> / <!--db:migrate db:migrate:down…--> / <!--以下, ロールバックが必要な場合は…--> / <!--リリースレベルに応じて…-->
   • 例外なし: migration 無しの場合でも rollback サンプル <!-- ... --> ブロックは削除しない（テンプレ構造の一部として保持）。

   ◆ テンプレートに無い見出しに相当する議論の反映先

   • セッションコンテキストに「設計判断」「やらなかったこと」相当の議論があっても、テンプレートにその見出しが存在しない場合は新規見出しを追加しない（ステップ 6 冒頭ルール）。
   • 議論内容は以下に圧縮反映する:
     • 設計判断議論 → 「レビューしてほしい観点」に 1 行で要約（例: 税率を Decimal で保持する判断が妥当か）
     • 「やらなかったこと」相当議論 → 該当見出しが無いなら反映先なし（無理に他セクションに混ぜず情報を捨てる判断）

   以下の見出し別ルールは、検出したテンプレートにその見出しが存在する場合のみ適用する。存在しない見出しについてのルールは無視する。

   ◆ 簡潔セクション（斜め読みできる構造で書く）

   各セクションの役割（混同しない）:

   見出し	答えるべきこと（役割）	NG（混同例）
   関連 Issue, Design Doc	紐付くチケット・先行PR・DDのリンク	内容を要約して書かない
   やったこと	変更の事実（何を変えたか）	動機・採用パターン・代替案を書かない
   なぜやるのか	ユースケース・利用者目線の動機（誰がなぜ困っていたか / 何を可能にしたいか）	「やったこと」を別表現で繰り返さない
   レビューしてほしい観点	不安なポイント・判断を仰ぎたい箇所	自明な「テストOK」等を書かない
   動作確認結果	確認手段と結果の事実	ケース列挙で水増ししない

   「やったこと」のセクション構造（必須）:

   • 1 行で PR 全体の意図を言い切る（50〜80字、句点で締める）。タイトルの文章化版
   • コードから読める事実は一切書かない: 変更ファイル名・追加した関数名・パラメータ追加・import 追加・helper 名・依存削除の対象モジュール名など、diff を開けば分かる情報は全て排除する
   • 禁止: 変更ファイル名の羅列、採用パターン名（...と同じ pattern）、比較対象（auth-guard.ts と同様）、hardcoded 等の理由語、(cookie 検証スキップ) のような括弧補足
   • 退避先: 上記で落とした設計理由（パターン採用の根拠・代替案の却下理由など）は「設計判断」見出しへ詳細に書く。スコープ外と判断したものは「やらなかったこと」へ。無ければ捨てる
   • trivial change の例文（変更意図と修正前後を 1 行に含める。例文の文言だけで「diff の中身」が伝わる必要はなく、何の目的の修正かが伝われば良い）:
     • typo 修正: README のセットアップ手順の表記 typo を修正した。
     • コメント修正: OrderService の責務記述コメントを実装と一致するよう更新した。
     • 文言修正: エラー画面のメッセージを「サーバーエラー」から「処理に失敗しました。時間をおいて再度お試しください」に置換した。

   「なぜやるのか」のセクション構造（必須）:

   • 1 文または 1 段落 2 行以内で済ませる。bullet 化しない
   • 「誰が・何に困っていたか / 何を可能にしたいか」だけを書く
   • 書く前に「やったこと」と1往復読み比べる。事実の言い換え（例: 「proxy で redirect する分岐を追加」⇄「stale cookie で 404 が出ていた」）になっていたら、利用者目線（誰がなぜ困っていたか）に書き直す

   「動作確認結果」のセクション構造（必須）:

   • 1 行で「手段 → 結果」を言い切る（例: curl で cookie 有/無 5 ケース全て期待通り / Chrome MCP で landing → ログイン → /setting/profile 着地まで通過）

   • ケース列挙の bullet は書かない。N 件あるなら「全 N 件期待通り」で潰す

   • diff から自明な事実は書かない: 「spec を追加した」「テストファイルを書いた」など diff を見れば分かる事実は「動作確認結果」に書かない。書くのは実行検証の手段（コマンド / ブラウザ操作 / CI run）と結果（pass / fail / 着地確認）だけ

   • 「レビューしてほしい観点」も同様に 1 行で書く

   • 判断マトリクス: change 規模 × context に検証情報があるかで以下のように決める

     change 規模	context に検証情報あり	context に検証情報なし
     trivial (typo / コメント / 文言修正)	1 行で「手段 → 結果」	目視確認のみ の固定 fallback または見出しのみ残し空欄
     非 trivial	1 行で「手段 → 結果」	ローカルで <変更箇所> を手動確認 のような 1 行宣言（捏造的な spec / CI 言及はせず手動チェック範囲を率直に書く）

   • 自明な「テスト OK」「特になし」を捻り出して埋めるくらいなら fallback / 空欄 / 1 行宣言を選ぶ

   記載例:

   • 関連 Issue: related #1234。推測不能なら related -
   • やったこと: 上記「セクション構造」に従う
   • なぜやるのか: 一覧表示が遅く既存ユーザの体感に影響していたため
   • レビューしてほしい観点: eager_loadの選択が適切か
   • 動作確認結果: RSpec 追加済み + 主要フロー手動確認済み

   記載例（複合見出しの場合、例: ## 関連 Issue, Design Doc）: 箇条書きで複数項目を列挙する。各項目は1行に収める。

   - XPROJ-444
   - depends on #1234 (UserModel)
   - DD: https://docs.google.com/document/d/xxxxx
   

   単一項目しかない場合は箇条書きにせず1行で書いてよい(例: related #1234)。

   ◆ 詳細セクション（「設計判断」「やらなかったこと」だけはコードから読めない情報なので詳細に書く）

   • 設計判断（コードから読めない情報・該当事実があれば詳細記述必須）: 次のいずれかに該当するときは本文を必ず詳細に書く。コードを読んでも「なぜそう実装したのか」「なぜ他の案を採らなかったのか」は判別できないため、ここがレビュアーに残す唯一の手がかりになる。該当事実が一切無いなら見出しだけ残し本文空欄。

     • 既存パターンと異なる実装をした場合: 違いと理由を具体的に
     • 複数の実装方法を検討した場合: 選んだ方法と代替案の却下理由をそれぞれ
     • トレードオフがある場合: 何を優先し何を犠牲にしたか、その判断根拠
     • セッションコンテキストに設計判断・変更方針の議論が含まれる場合: 議論の内容を圧縮せず反映

     書き方: 散文で詳細に書く。他の簡潔セクションが 1 行に絞られているぶん、ここではレビュアーが PR の判断根拠を追えるだけの情報を残す。優先順位は次のとおり：

     1. 第一優先: 散文で完結させる（bullet なし）。複数段落で構成してよい
     2. 第二優先: 散文 + 末尾の太字bullet 1〜2つで要点をハイライト（散文と内容が重複するなら bullet を削る）
     3. NG: bullet を3つ以上並べる、bullet だけで構成する、散文と無関係な bullet を足す、理由を 1 行で済ませる

     段落構成は次の順：1段落目で選択した結果、2段落目以降で理由・代替案・トレードオフを 1 つずつ丁寧に展開する。

     「〜のため」の使用制限（同一段落内で2回以上の「文末/節末理由節」用法を禁止）:

     • 対象: 〜のため。 〜のため、〜 のように、句点直前または読点直前で理由を表す節末として使われた場合
     • 対象外: 名詞「ため」（例: 〜のために動作する 〜のため**だ** その**ため**の対策 のように後続が助詞・助動詞・名詞として続く形）
     • 「〜することで」も同様に節末理由用法のみ対象

   • やらなかったこと（コードから読めない情報・該当事実があれば詳細記述必須）: 次のいずれかに該当するときは本文を必ず詳細に書く。コードには「やったこと」しか現れず、「触ろうと思えば触れたが意図的に触らなかった範囲」はレビュアーが推測するしかなくなる。ここを明示することでレビュー範囲の合意とフォローアップの追跡を可能にする。該当事実が一切無いなら見出しだけ残し本文空欄（推測で埋めない）。

     • セッションコンテキストに「やらなかったこと」「スコープ外」として明示された議論がある場合: それを反映
     • コミットメッセージや diff のコメントに「TODO」「後続対応」「スコープ外」と明示されている場合: それを反映
     • 関連 Issue 本文に「対象外」「別 PR で対応」と書かれている場合: それを反映
     • 上記いずれにも該当しない場合: 空欄のまま（自分の想像で補完しない）

     書き方: 散文で詳細に書く。1 項目につき以下 3 点をセットで展開する:

     1. 何を意図的にやらなかったか（範囲・対象モジュール）
     2. なぜ今回やらないと判断したか（スコープ管理上の理由・依存関係・優先度）
     3. 次にどこで扱うか（後続 PR 番号 / Jira チケット / 未定 の明示）

     複数項目があれば項目ごとに段落を分けて書く。1 段落で済ませようとして情報を圧縮しない。

     例: 本 PR では require_token? の重複解消には踏み込まない。重複の解消は auth middleware 全体のリファクタとセットで行うべきで、本 PR のスコープ（proxy 経路の一本化）を超えるため。後続 XPROJ-474 で別途対応する。

   ◆ 定型セクション

   • Revert手順（以下のルールに従う）
     • スキーマ変更がない場合：「スキーマ変更はありません. Revert PR を作成してマージしてください」にチェック
     • 不可逆な変更の場合：「Revert できません. 不可逆な変更となります」にチェック
     • migration が含まれる場合：「各環境のデータベースのロールバック...」にチェックし、以下の形式でrollbackコマンドを明記。環境名リストは ~/.claude/skills-config/environments.md の rollback_targets から取得（無ければ production / sandbox / staging のみで構成）。

       各環境にアクセスして以下を実行してください
       - production
       - sandbox
       - staging
       - <~/.claude/skills-config/environments.md の integration_envs を1行ずつ列挙、無ければ省略>
       
       # 1. 現在の状態確認
       bundle exec rails db:migrate:status
       
       # 2. ロールバック実行（新しいものから順に）
       bundle exec rails db:migrate:down VERSION=<実際のmigration VERSION>
       （複数ある場合は全て列挙）
       
       # 3. 結果確認
       bundle exec rails db:migrate:status
       

   • セルフレビューチェックリストはそのまま残す

   ◆ 空欄セクションの書式

   • 「詳細セクション」で本文を書かないと判定した場合、見出し行だけ残し、直下に空行を 1 行置く（プレースホルダやコメント等は追加しない）。

   • 空行 1 行の理由: ## 見出し\n\n## 次の見出し の形でレンダリング崩れを避けるため。

   • 日本語で記述

7. ラベルの付与

   ラベル定義は ~/.claude/skills-config/release-labels.md を Read で取得して使用する。同ファイルには以下のキーが定義されている前提:

   • productivity_labels: 開発生産性カテゴリのラベル一覧と判定基準
   • ai_contribution_labels: AI貢献度のラベル一覧（4段階推奨）と判定基準
   • release_level_labels: リリースレベルのラベル一覧（4段階推奨）と判定基準
   • core_features: プロジェクトの根幹機能リスト（ReleaseLevel 高レベル判定に使用）

   ~/.claude/skills-config/release-labels.md が見つからない場合のフォールバック: bash scripts/setup.sh の実行をユーザーに促し、ラベル付与をスキップしてドラフトPRを作成。

   a. Productivityラベル（1つ選択）: release-labels.md の productivity_labels から1つ選択。判定基準は同ファイルに従う。一般的な判定優先順位は以下（実環境のラベル名は release-labels.md を参照）:

   • ユーザーが体感する変化がある（新機能・UX 改善）
   • バグ修正・依存ライブラリ更新・責務分割リファクタ
   • 共通基盤・CI 改善・計測基盤・docs
   • 既存コードへの spec 追加・品質向上のためのリファクタ
   • 上記いずれにも当てはまらない、または Bot 生成 PR

   b. AI Contributionラベル（1つ選択）: release-labels.md の ai_contribution_labels から1つ選択。判定フローチャート（上から順に適用、最初にマッチしたもの採用）:

   1. ユーザーがセッション冒頭で level を明示指定した → その指定を優先
   2. 本セッション内で Claude（または他の AI コード生成コマンド）が 本 PR の差分コードを生成・変更した（新規ファイル作成・既存コードへの Edit/Write を行った）→ 推奨デフォルト（4段階の最高レベル）
      • 注意: 本 skill 自体は PR 作成補助であり「コード生成」には該当しない。判定対象は PR の diff に含まれるソースコードの成立経緯
   3. AI 生成がほぼ無く人間主体で書いた変更（例: typo 修正、手動 rename のみ、手動で書いた後に AI は PR 作成補助のみ使用）→ 4段階の最低レベル
   4. それ以外で判断に迷う → 推奨デフォルトを採用し、PR 本文「やったこと」の末尾に「(AI contribution 実測困難のため推定)」と 1 行添える（この 1 行は 60字制限から除外する）

   c. Release Levelラベル（1つ選択）: release-labels.md の release_level_labels から1つ選択。判定ショートカット（上から順に適用、最初にマッチしたもの採用）:

   1. db/migrate/ 配下の差分がある → 最高レベル（スキーマ変更は常に最高、不可逆扱い）
   2. 「根幹機能」に挙動を追加・変更し、既存ユーザーが体感できる挙動変化（既存フロー後の追加メール送信、既存画面の操作結果変化、外部連携の挙動変化など）を伴う → 高レベル
      • 例: 注文確定フローに通知メーラーを追加（確定後の挙動が変わる）
      • 例: 既存 API のレスポンス内容を変更
   3. 「根幹機能」エリアでも既存ユーザーの体感に影響しない後方互換変更（裏側のリファクタ、内部メソッド追加、既定無効の新機能フラグなど）、または「根幹機能」以外の後方互換変更（UI 調整、API への後方互換フィールド追加など）→ 中レベル
   4. 表示文言のみ・タイポ・パッチアップデートのみ → 最低レベル

   プロジェクトの根幹機能の判定:

   • release-labels.md の core_features リストに挙がっているドメインに触れるなら「根幹機能への影響あり」と判断
   • core_features が空の場合は対象リポジトリの CLAUDE.md / README.md 冒頭の「主要機能」「プロジェクト概要」記述から推定
   • 原則として認証・認可・決済・データ永続化・外部公開 API は「根幹機能」扱い

8. マイルストーンの設定

   • 関連Issueがありマイルストーンがあればそれを使用
   • それ以外の場合はUntrackedを設定
   • 事前確認: gh api repos/{owner}/{repo}/milestones --jq '.[].title' で Untracked マイルストーンの存在を確認し、無ければ --milestone オプション自体を省略する（存在しない値を指定すると gh pr create が失敗するため）

9. PR本文の最終チェック（投稿前必須） ステップ6で生成したPR本文を、投稿前に以下の観点で自己点検する。1つでも該当があれば修正してから次に進む。

   [A] 斜め読みテスト（最重要・最初に実施）

   • description 全文を各セクションの先頭1行目だけ読み、PR の意図と影響範囲が3秒で再構築できるか
   • 「やったこと」が 1 行で PR 全体の意図を言い切れているか（言い切れていないなら書き直す）

   [B] コードから読める情報の混入検出

   • 「やったこと」「なぜやるのか」「レビューしてほしい観点」「動作確認結果」に変更ファイル名・関数名・パラメータ追加・import 追加など diff を見れば分かる事実が書かれていないか。書かれていれば削除（設計理由は「設計判断」へ退避、スコープ外は「やらなかったこと」へ退避）

   [C] 重複・冗長検出

   • 「やったこと」と「なぜやるのか」で同じ事実が両方に書かれていないか（事実=手段、なぜ=利用者目線の動機）
   • 簡潔セクション（やったこと / なぜやるのか / レビューしてほしい観点 / 動作確認結果）にbullet list が並んでいないか。複数項目を列挙したい衝動が出ているなら 1 行に凝縮する（複合 Issue リスト等の例外を除く）
   • 「動作確認結果」がケース列挙になっていないか（「全N件期待通り」で潰せないか）
   • 逆に「設計判断」「やらなかったこと」が1〜2行で済まされていないか。該当事実があるなら理由・代替案・トレードオフ・スコープ外判断根拠を散文で詳細に展開できているか

   [D] AI臭検出

   • AI生成検出語（「以下に〜を示す」「具体的には」「適切に」「効率的に」「〜することにより」「〜と考えられる」）が含まれていないか
   • **強調**: 形式の太字bullet が1セクションに3つ以上並んでいないか
   • 機械的な絵文字（⚠️ 📝 🔧 ✅ 🎯 等）がセクションマーカーとして連発されていないか
   • 「〜のため」「〜することで」が1段落で2回以上出ていないか
   • 「特になし」「該当なし」のような中身のない埋め文が空欄セクションに書かれていないか
   • 詳細セクション（設計判断 / やらなかったこと）が箇条書きの羅列だけで散文がないか（散文ベース + 太字bullet 1〜2 つが望ましい）

   該当があれば修正。ここをスキップすると冗長な description が残ってレビュアーの読む気を削ぐ。

10. ドラフトPRの作成

• gh pr createコマンドを使用
• --draftオプションでドラフトとして作成
• --titleでタイトル設定
• --bodyで説明設定（ステップ9でチェック済みの本文）。巨大本文で --body-file を選ぶ場合は、必ず後述「作成後に PR description を更新する場合」の mktemp 規約に従う（固定パス /tmp/pr-body.md は過去セッション残骸混入の事故源）
• --labelで全てのラベル設定
• --milestoneでマイルストーン設定
• ベースブランチを指定

注意事項

• 全ての内容は日本語で記述
• 変更内容を正確に反映
• 既存のコミット全てを考慮（最新のコミットだけでなく）
• セキュリティやパフォーマンスへの影響を考慮
• PRが作成できたらURLを表示

例

# developブランチに対してPRを作成
gh pr create --draft \
  --title "feat(order): 注文確定後の通知機能を追加" \
  --body "..." \
  --label "1.Feature development,ai-contribution-level:2,ReleaseLevel-2" \
  --base develop

作成後に PR description を更新する場合

gh pr edit --body は Projects Classic deprecation エラーで失敗するため 使わない。代わりに GitHub REST API を直接叩く。

⚠️ 前提: 固定パス (/tmp/pr-body.md 等) を使わない

過去セッションが同一パスに残した body 内容 (stale content) が残置ファイルとして残り、Write の「File has not been read yet」エラーを軽視して読み込まずに gh api -F body=@<file> や gh pr create --body-file <file> で渡すと、無関係な PR 内容が投入される事故が発生する。body をヒアドキュメントで一時ファイル化する場合は、固定パスではなく mktemp でユニークパスを生成し、終了時に削除する。ランダム名のため衝突せず、rm し損ねても他セッションには影響しない。

# 1. body を一時ファイルに書き出す（mktemp でユニークパス生成）
PR_BODY_FILE=$(mktemp --suffix=.md)
cat <<'EOF' > "$PR_BODY_FILE"
## やったこと
...
EOF

# 2. gh api PATCH で body を更新
REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
PR_NUMBER=<作成した PR 番号>
gh api "repos/${REPO}/pulls/${PR_NUMBER}" --method PATCH -F "body=@${PR_BODY_FILE}"

# 3. 一時ファイル削除
rm "$PR_BODY_FILE"

• -F "body=@<path>" はファイル内容をリクエストボディの文字列値として送信する gh CLI の機能。--field の @ プレフィックスと同じ
• タイトルやラベルの更新は gh pr edit --title / gh pr edit --add-label で動作するので、description 更新時のみこの回避策を使う
• 同じ mktemp 規約は Step 10 (gh pr create) で --body ではなく --body-file を選ぶ場合にも適用する

併用推奨 skill

• /polish-before-commit — コミット前にプロジェクト規約・パターン一貫性を仕上げてから本 skill を起動する
• /finalize-plan — プランを実装可能形式に変換し、その流れで本 skill を呼ぶ