PR 作成

リポジトリ固有の PR テンプレートに沿った PR を写経なしで作成する。テンプレートが無くても汎用観点で過不足ない PR を作る。モデルが PR 作成を要する場面で自動的に参照してよく、/pr-create の明示実行でも動く。

制約（厳守）

• 確認の要否は §1 の CONFIRMATION に従う。confirm: required（head が保護ブランチ）のときだけ、push と作成の前にユーザー承認を取る（§7）。confirm: skip なら確認せずに push して作成し、作成後に報告する。
• 作成は draft が既定。「通常 PR で」の指示時のみ非 draft。
• 対象リポジトリの取り違え・文脈混入を禁止。本文・タイトルは scripts/pr-context.sh が出すこの作業ディレクトリの git 状態（REPO IDENTITY / COMMITS / DIFF）だけを根拠にする。会話履歴に残る別リポジトリ・別タスクの内容を PR 本文へ持ち込まない。スクリプトの REPO IDENTITY（repo slug / worktree-root）が、PR を作ろうとしている対象と一致することを作成前に必ず確認する。
• テンプレートは確定フォーム。骨組みを改変しない。TEMPLATE が primary/選択 multi を返したら、見出し・チェックリスト・順序を逐語で保ち、入力箇所を埋めるだけ（§4）。独自フォーマットへの差し替え・セクションの削除/追加/並べ替え・見出しの言い換えは禁止。作成前に scripts/template-check.sh の骨組み照合ゲート（§5）を必ず通す。
• PR本文にセッションURLを含めない。Claude Code の既定動作は本文末尾にセッションへのリンクを付与するが、このリポジトリでは付与しない。ローカル CLI・remote-control のどちらのセッションでも同様。

ワークフロー

1. コンテキスト収集（スクリプト）

プラットフォーム判定・ベース特定・差分・push 状態は決定論的に行えるため scripts/pr-context.sh を実行する。手で git コマンドを並べ直さない。

bash <skill-dir>/scripts/pr-context.sh [base-branch]

=== SECTION === 区切りの出力を読む:

• REPO IDENTITY = 対象リポジトリの repo slug と worktree-root。本文を起こす前にここを確認し、いま PR を作ろうとしている対象と一致することを担保する（制約「対象リポジトリの取り違え禁止」）。
• PR BODY FILE = 本文下書きの書き出し先（絶対パス）。§5 でここに本文を Write し、template-check.sh の第2引数にも同じパスを渡す。パスにはセッションごとにユニークな ID が埋まっている（worktrunk 等で複数セッションが tmp-agents/ を symlink 共有していても衝突しないよう分離済み）。自分でファイル名を決めず、必ずこの行のパスを使う。同一セッションでの再実行は同じパスに落ちるので下書きの上書き更新になる。
• PLATFORM = remote URL から判定したプラットフォームと使用 CLI・導入有無。github→gh、gitlab→glab、unknown/installed: no → 本文を提示して手動作成を案内。コマンド詳細は references/platforms.md。
• TEMPLATE = リポジトリルートから決定論検出したテンプレ。primary: が出たらそれを使う（独自フォーマット禁止）。multi: は複数テンプレなので候補提示して選んでもらう。(テンプレートなし) のときだけ §4 の汎用構成。ここで primary が出ているのに自前の見出しで書くのは規約違反。
• BASE BRANCH = リモート既定ブランチではなく、作業ブランチの分岐元をローカル探索した結果。(特定できませんでした) や誤検出が疑わしいときは引数 base-branch を渡して再実行、またはユーザーに確認。
• COMMITS / COMMIT MESSAGES = 本文の主素材。
• DIFF STAT / CHANGED FILES = 変更範囲。完全差分が要れば末尾の git diff <base>...HEAD を別途実行。
• CONFIRMATION = head が保護ブランチか。protected は静的リスト（main・master・develop・development・trunk・release・release/・releases/）に、origin/HEAD と GitHub 上（gh repo view）の既定ブランチを加えたもの。default に両者の取得結果が出る。confirm: required なら §7 で承認を取り、skip なら取らない。
• UPSTREAM / PUSH STATUS に WARNING（未 push／未 push コミットあり）が出たら記録しておき、§7 の作成直前に push する。ここではまだ push しない。

2. テンプレート確認

テンプレ検出は §1 の pr-context.sh が TEMPLATE セクションで決定論的に済ませている。手で find を打ち直さない（打ち忘れ・スキップの元）。

• primary: があり multi: が無い → そのファイルを読んで使う。
• multi: がある → 候補をユーザーに提示し、選ばれたものを使う。
• (テンプレートなし) → §4 の汎用構成へ。

配置の網羅一覧やプラットフォーム別の細部は references/platforms.md。スクリプトの検出漏れが疑わしいとき（独自配置のテンプレ等）だけ手動探索を補助に使う。

3. 言語判定

本文の言語は次の優先順で決める。①テンプレートがある → テンプレートの見出し・コメントの言語に合わせる。②無い → 直近コミットや README の言語。③不明 → ユーザーに確認。

4. 本文生成

大原則: 本文の素材は §1 スクリプトが出したこの作業ディレクトリの COMMITS / DIFF / CHANGED FILES だけ。会話に残る別リポジトリ・別タスクの記憶を素材にしない。

テンプレートあり（TEMPLATE に primary/選択した multi）: **テンプレは「確定した入力フォーム」**として扱う。テンプレ作成者が「何をどこに書くか」を既に決めているので、文脈を読んで構成を作り直す作業ではなく、決められた入力箇所を埋めるだけ。

• 骨組みは逐語で不変。見出しのテキスト・階層・順序、チェックリスト項目のラベル、HTML コメントの指示は変えない・消さない・並べ替えない・言い換えない。編集してよいのは入力箇所だけ（見出し下の空行やプレースホルダを埋める、- [ ]→- [x]）。これはモデルの無断改変を禁じるルールであり、ユーザーが骨組み変更を明示指示・許可したときは §5 の例外に従う（ユーザー指示 > このデフォルト）。
• 該当しないセクションも削らない。「今回は関係ない」と判断しても見出しは残し、中身に「該当なし」等と正直に書く。掃除・簡潔化を目的にセクションを落とさない。レビュアーはそのフォームの型で読む前提なので、型を崩すとレビュー観点が抜け落ちる。
• テンプレに無いセクションを勝手に足さない（どうしても補足が要るならテンプレ末尾に最小限）。
• <!-- ... --> は指示として読み、埋めた後の扱い（残す/消す）はテンプレ慣習・既存 PR に倣う。
• チェックリスト - [ ] は差分から確実に満たすものだけ - [x]。不明は未チェックで残し、全部チェックしない。
• 推測で事実を捏造しない。差分から読めない背景は埋めず、ユーザーに補完を促す。

生成した本文は、作成前に §5 の骨組み照合ゲートを必ず通す。

テンプレートなし: 下記の汎用構成（言語は §3 準拠、不要セクションは省く）。

## 概要
<!-- この PR で何をするか 1〜2 行 -->
## 変更内容
<!-- 主な変更点を箇条書き -->
## 変更の背景・理由
<!-- なぜ必要か。関連課題・経緯 -->
## 動作確認
<!-- どう確認したか。テスト・検証手順 -->
## 影響範囲・注意点
<!-- 影響箇所・レビュー注意点・未対応事項 -->
## 関連 Issue / リンク
<!-- Closes #xxx など -->

5. 骨組み照合（テンプレートがある場合の作成前ゲート）

テンプレ遵守を目視に委ねると、無意識にセクションを落としたり見出しを言い換えたりしやすい。決定論スクリプトで機械的に照合し、drift があれば提示前に潰す。

1. 生成した本文を §1 の PR BODY FILE が示すパスに書き出す（セッション分離済みの絶対パス。自分でファイル名を決めない）。

2. テンプレ本体と照合する（<pr-body> は §1 の PR BODY FILE のパス）:

   bash <skill-dir>/scripts/template-check.sh <テンプレのパス> <pr-body>
   

   • RESULT: OK → 骨組み一致。§7 の提示へ進む。
   • PLACEHOLDERS に仮項目（テストケース1 のような連番だけ・空・<…>・xxx 等のラベル）が出たら、それは書き換え前提の入力箇所。同じ見出しの中で実際の確認項目へ置き換える（該当が無ければ消して「該当なし」等と書く）。置き換えた項目は REPLACED に出て DRIFT にならない。仮項目をそのまま残すと PLACEHOLDER として DRIFT になる。
   • RESULT: DRIFT DETECTED → MISSING（削った見出し/項目）・EXTRA（勝手に足した見出し）・REORDER（並べ替え）・PLACEHOLDER（残った仮項目）を確認し、下書きをテンプレ構造に戻して再チェック。OK になるまで提示に進まない。骨組みを守った上で入力箇所を埋め直す（勝手にセクションを消して辻褄を合わせない）。

テンプレが無い（§4 の汎用構成）ときはこのゲートは不要。

例外: ユーザーが骨組み変更を明示許可したとき

このゲートが弾くのはモデルの無断改変。ユーザーが明示的に骨組みの変更を指示・許可した場合は別で、その変更後の本文を採用してよい（例: 「このチェック項目のラベルを実際の確認観点に書き換えてよい」「このチェック項目は棄却してよい」「ゲートを棄却する」等）。DRIFT を消すためにユーザー指示を無視してテンプレ構造へ戻してはならない（今回の逆走はこれ）。手順:

1. ユーザーの許可を1文で再言明してから本文を編集する（例:「テスト節の テストケース1 を『本番で Slack 通知を確認』に置換します。2/3 はプレースホルダのまま残します」）。解釈が割れる指示は AskUserQuestion で確定してから触る。
2. 変更後の本文を PR BODY FILE に書き出し、参考として template-check.sh を再実行する。ここで出る DRIFT は想定内なので OK にする必要はない。
3. どの項目を何に変えたかを §7 の提示でユーザーに見せ、承認を得てから作成する（無断改変との区別のため、承認前に作成しない）。
4. この「ユーザー承認済み DRIFT」であることを覚えておき、§7 の CREATE 直前ゲート（下記）でも DRIFT を許容する。

判断が曖昧なら「ユーザーが骨組み変更を許可したのか、それとも入力箇所を埋める話か」を確認する。デフォルトは骨組み不変。棄却は明示指示があるときだけ。

6. タイトル

Conventional Commits 形式（<type>(<scope>): <subject>、commit-flow スキル準拠）を基本。単一コミットはそのメッセージを流用、複数は全体を要約。既存 PR にタイトル規約があればそれを優先。

7. （確認）→ push → 作成

1. §1 の CONFIRMATION が confirm: required なら、タイトルと本文をチャットに提示し、push が要るときはその可否もあわせて AskUserQuestion で承認を取る（要点と選択肢は本文にも記載／CLAUDE.md 準拠）。拒否されたら push も作成もせず停止する。confirm: skip なら確認を取らずに次へ進む。
2. §1 の PUSH STATUS が WARNING（未 push／未 push コミットあり）なら push する。既に push 済みならこの手順は不要。
   • push の直前に bash <skill-dir>/scripts/push-arm.sh <branch> で arm する（permission-gate hook に push を通させる marker）。permission-gate は push を実行する前に判定するため、次を守らないと承認ダイアログが出る:
     • arm と push は別々の Bash 呼び出しにする（同じ呼び出しでは判定時点で marker がまだ無い）。
     • arm のパスは <skill-dir> を実パスに置き換えて書く。$(fd …) 等の置換でスクリプトを探さない。
     • push は git push [-u] origin <branch> か cd <リテラルのパス> && git push [-u] origin <branch> だけにする。;・パイプ・2>&1・| tail・引用符を付けない。
   • push に失敗したら PR の作成に進まない。
3. CREATE 直前の最終ゲート（テンプレありのとき必須）。§5 の照合は「その時点のファイル」の保証でしかなく、その後の Write や外部変更で無効化される。作成コマンドに渡すまさにそのファイルを再検証する:
   • gh pr create --body-file <PR BODY FILE> の直前に、実ファイルを cat して**§4〜§5 で確定した本文**（confirm: required ならユーザーに承認された本文）と同一内容であることを確認する（Write 成功メッセージや context 上の状態を信用せず、必ず実ファイルを読む）。食い違っていたら作成せず、正しい本文を書き直してからやり直す。
   • あわせて template-check.sh <テンプレ> <PR BODY FILE> をもう一度実行する。
     • RESULT: OK → 作成へ。
     • RESULT: DRIFT DETECTED かつ §5 の「ユーザー承認済み DRIFT」に該当しない → 作成を中止。無断改変が紛れ込んでいるので本文を戻して再照合する。
     • RESULT: DRIFT DETECTED だが §5 でユーザーが明示許可した変更そのものなら、想定内として作成してよい（許可外の drift が増えていないことは DIFF で確認）。
4. draft 作成（コマンドは references/platforms.md）→ PR の URL を報告。confirm: skip で確認を省いたときは、タイトルと本文も報告に含める。

参照

• scripts/pr-context.sh — リポジトリ同定（REPO IDENTITY）・プラットフォーム判定・テンプレ決定論検出（TEMPLATE）・ベース特定〜差分・push 状態を出す read-only スクリプト（§1）。
• scripts/template-check.sh — テンプレ本体と本文下書きの骨組み（見出し＋チェックリストのラベル）を照合し、削り・勝手追加・並べ替え・仮項目の残りを検出する作成前ゲート（§5）。仮項目の同じ見出し内での置き換えは許す。
• scripts/push-arm.sh — push 直前に permission-gate 用の marker（push-flow.armed）を置く（§7）。
• references/platforms.md — プラットフォーム別 CLI コマンド・テンプレ配置・手動作成フォールバック。