ce-pr-description

CE PR 説明

プルリクエストの作業内容を説明する、Conventional Commits 形式のタイトルと価値を先に伝える本文を生成します。呼び出し元が適用できるよう、構造化された {title, body_file} を返します。このスキルは gh pr edit や gh pr create を実行せず、対話形式での確認も求めません。

個別のスキルに分けている理由：ce-commit-push-pr にある単一 PR 用の対話型の枠組みを使わずに、複数の呼び出し元で同じ文章作成ロジックを利用する必要があるためです。ce-pr-stack の分割ワークフローでは、各レイヤーについてバッチ処理としてこのスキルを一度実行します。ce-commit-push-pr では、フルフローモードと更新モードの経路内で実行します。切り出すことで、文章作成の原則を一元管理できます。

命名の理由： git-pr-description ではなく ce-pr-description です。スタッキングと PR の作成は GitHub の機能であり、名前に含まれる「PR」は GitHub の成果物を指します。ce- プレフィックスを使うことで、すべてのスキルにおけるプラグインの命名規則に合わせています。

---

入力

入力は自由形式のプロンプトです。次の2つに分けて解釈してください。

• PR 参照（含まれている場合）。 次のいずれかの形式に該当します。GitHub PR の完全な URL（https://github.com/owner/repo/pull/NN）、pr:<number> または pr:<URL>、ハッシュマークのみの形式（#NN）、あるいは引数が数字のみ（561）の場合です。PR 参照を抽出し、引数の残りを方向づけのテキストとして扱います。
• それ以外はすべて方向づけのテキストです（「ベンチマークを強調して」や「パフォーマンスの説明をうまく書いて」など、焦点を示すヒント）。PR 参照と組み合わせても、単独で指定してもかまいません。

特定の文法は不要です。引数を自然言語として読み、含まれている PR 参照を特定してください。PR 参照がない場合は、現在のブランチの説明を作成します。

モードの選択

呼び出し元から渡される内容	モード
PR 参照なし（引数が空、または方向づけのテキストのみ）	現在のブランチモード — HEAD 上のコミットとリポジトリのデフォルトベースとの差分を説明します
PR 参照あり（URL、pr:、#NN、または数字のみ）	PR モード — 指定された PR を説明します

方向づけのテキストは常に任意です。指定されている場合は、差分から導き出した説明に加味してください。ただし、価値を先に伝える原則に反したり、差分に裏付けられていない内容を作り出したりしてはいけません。

任意の base:<ref> 上書き（現在のブランチモードのみ）。 呼び出し元が意図したベースブランチをすでに把握している場合（例：ce-commit-push-pr が origin/develop または origin/release/2026-04 を対象ブランチとして検出した場合）、base:<ref> を渡してベースを明示できます。この ref はローカルで解決できる必要があります。現在のブランチモードでは自動検出より優先されます。PR モードでは無視されます（PR には baseRefName によって独自のベースが定義されているためです）。ほとんどの呼び出しでは不要です。一般的なケースは、自動検出（既存 PR の baseRefName → origin/HEAD）で対応できます。

例：

• ce-pr-description → 現在のブランチ、焦点なし、ベースを自動検出
• ce-pr-description emphasize the benchmarks → 現在のブランチ、焦点 = "ベンチマークを強調して"
• ce-pr-description base:origin/develop → 現在のブランチ、ベースを origin/develop に固定
• ce-pr-description base:origin/develop emphasize perf → 同上＋焦点
• ce-pr-description pr:561 → PR #561、焦点なし
• ce-pr-description #561 do a good job with the perf story → PR #561、焦点 = "パフォーマンスの説明をうまく書いて"
• ce-pr-description https://github.com/foo/bar/pull/561 emphasize safety → foo/bar の PR #561、焦点 = "安全性を強調して"

出力

次の2つのフィールドを含む構造化された結果を返します。

• title — conventional-commit 形式：type: description または type(scope): description。72文字未満にしてください。意図に基づいて type を選択してください（feat/fix/refactor/docs/chore/perf/test）。最も具体的で有用な scope（スキル名またはエージェント名、CLI 領域、または共通ラベル）を選び、単一のラベルでは明確さが増さない場合は省略してください。
• body_file — OS の一時ファイルの絶対パス（mktemp で作成）を指定します。以下の記述原則に従った本文の Markdown を格納してください。本文を戻り値に直接含めないでください。

呼び出し元は、適用するかどうかを判断し、body_file から本文を読み取って gh pr edit、gh pr create、または破棄を行います（例：--body "$(cat "$BODY_FILE")"）。このスキル自体は、これらのコマンドを実行しません。クリーンアップは不要です。mktemp ファイルは OS の一時ストレージに作成され、OS が独自のスケジュールで削除します。

---

このスキルが行わないこと

• 対話形式の確認プロンプトは表示しません。差分の重要な点（例：フォーカスのヒントと実際の変更内容）が曖昧な場合は、その曖昧さを戻り値で示すか、呼び出し元に伝えてください。ユーザーに直接質問しないでください。
• ブランチをチェックアウトしません。カレントブランチモードでは、ユーザーの現在のチェックアウトにある HEAD の内容を説明します。PR モードでは、指定された PR の内容を説明します。どちらのモードでも、別のブランチをチェックアウトしません。
• 比較して確認する説明（「前のバージョンから何が変わったか」）は行いません。説明では最終状態を記述します。比較して確認する説明を含めるかどうかは、呼び出し元が判断します。
• gh pr edit または gh pr create による自動適用は行いません。結果を返したら終了します。

対話形式の準備（確認プロンプト、比較して確認する説明、適用手順）は呼び出し元の責任です。

---

手順 1：差分とコミット一覧を解決する

入力を解析し（上記の「入力」を参照）、選択されたモードに応じて処理します。

カレントブランチモード（PR の参照が指定されていない場合の既定値）

比較対象のベースを、次の優先順位で決定します。

1. 呼び出し元が指定した base:<ref> — 指定されている場合は、その値をそのまま使用します。呼び出し元が正しいベースを指定したものとします。参照先がローカルで解決可能である必要があります。
2. 既存の PR の baseRefName — 現在のブランチに、このリポジトリ上のオープンな PR がすでにある場合は、その PR のベースを使用します。PR がすでに開かれている際に、デフォルト以外のベース（例：develop）を対象とするフィーチャーブランチにも対応します。
3. リポジトリのデフォルト（origin/HEAD） — PR がまだなく、呼び出し元からベースも指定されていないブランチでは、これを使用します。

# Detect current branch (fail if detached HEAD)
CURRENT_BRANCH=$(git branch --show-current)
if [ -z "$CURRENT_BRANCH" ]; then
  echo "Detached HEAD — current-branch mode requires a branch. Pass a PR reference instead."
  exit 1
fi

# Priority: caller-supplied base: > existing PR's baseRefName > origin/HEAD > origin/main
if [ -n "$CALLER_BASE" ]; then
  BASE_REF="$CALLER_BASE"
elif EXISTING_PR_BASE=$(gh pr view --json baseRefName --jq '.baseRefName'); then
  BASE_REF="origin/$EXISTING_PR_BASE"
elif DEFAULT_HEAD=$(git rev-parse --abbrev-ref origin/HEAD); then
  BASE_REF="$DEFAULT_HEAD"
else
  BASE_REF="origin/main"
fi

「未設定」の経路では gh pr view と git rev-parse --abbrev-ref origin/HEAD の両方がゼロ以外で終了します。elif チェーンでは、抑制された標準エラー出力ではなく終了コードを基準に処理を分岐します。PR が見つからない場合や origin/HEAD を解決できない場合の標準エラー出力は情報提供用であり、問題ありません。

$BASE_REF がローカルで解決できない場合（git rev-parse --verify "$BASE_REF" が失敗した場合）は、呼び出し元（またはユーザー）が先に取得する必要があります。"Base ref $BASE_REF does not resolve locally. Fetch it before invoking the skill." と出力して正常に終了してください。復旧を試みないでください。

マージベース、コミット一覧、および完全な差分を取得します。

MERGE_BASE=$(git merge-base "$BASE_REF" HEAD) && echo "MERGE_BASE=$MERGE_BASE" && echo '=== COMMITS ===' && git log --oneline $MERGE_BASE..HEAD && echo '=== DIFF ===' && git diff $MERGE_BASE...HEAD

コミット一覧が空の場合は、"No commits between $BASE_REF and HEAD" と報告して正常に終了してください。説明する内容はありません。

手順 1 で既存の PR が見つかった場合は、手順 3 で根拠を保持できるよう、その PR の本文も取得してください。

PR モード（入力に PR への参照が含まれていた場合）

gh pr view が受け付ける形式に参照を正規化します。単独の番号（561）、完全な URL（https://github.com/owner/repo/pull/561）、または pr:561 や #561 から抽出した番号を使用します。gh pr view の位置引数が受け付けるのは、単独の番号、URL、ブランチ名です。owner/repo#NN 形式の省略表記は受け付けません。URL を使わず、別リポジトリの番号を参照する場合は、呼び出し元が -R owner/repo を使用します。このスキルでは、別リポジトリを最も簡単に指定できる完全な URL を受け付けます。ほとんどの呼び出し元がこの形式を使用します。

gh pr view <pr-ref> --json number,state,title,body,baseRefName,baseRefOid,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository,commits,url

主な JSON フィールド：headRefOid（PR の head SHA。commits のインデックス参照より優先）、baseRefOid（ベースブランチの SHA）、headRepository と headRepositoryOwner（PR のソースリポジトリ）、isCrossRepository。baseRepository フィールドはありません。ベースリポジトリは、gh pr view 自体が照会したリポジトリです。

返された state が OPEN でない場合は、"PR <number> is <state> (not open); cannot regenerate description" と報告し、出力せずに正常終了します。{title, body_file} を想定する呼び出し元は、この空のケースを処理する必要があります。

PR が現在の作業ディレクトリのリポジトリにあるかどうかを判定します。 URL の <owner>/<repo> のパス部分を解析し、git remote get-url origin と比較します（.git サフィックスを除去し、[email protected]:owner/repo 形式と https://github.com/owner/repo 形式の両方に対応します）。URL のリポジトリが origin のリポジトリと一致する場合は、ローカル Git パス（ケース A）を使用します。それ以外の場合は、API のみを使うパス（ケース B）を使用します。単独の番号と #NN 形式は、暗黙的に現在のリポジトリを対象とするため、ケース A を使用します。

ケース A からケース B へのフォールバック： URL のリポジトリが origin と一致していても、この PR の参照にローカルクローンを使用できないことがあります。浅いクローン、ベースブランチがない detached 状態、オフライン、認証の問題、GHES 固有の挙動などが原因です。ケース A のフェッチまたは git merge-base が失敗した場合は、スキルを失敗させるのではなく、ケース B にフォールバックします。呼び出し元向けの出力に、フォールバックしたことを記載します。

ケース A — PR が現在のリポジトリにある場合：

上記の JSON レスポンスにある headRefOid から、PR の head SHA を直接読み取ります。ベース参照と head SHA を 1 回の呼び出しでフェッチします（参照がすでにローカルにある場合、フェッチを繰り返しても影響はありません）。

PR_HEAD_SHA=<headRefOid from JSON>
git fetch --no-tags origin <baseRefName> $PR_HEAD_SHA

後続のコマンドで明示的な $PR_HEAD_SHA を使用すると、FETCH_HEAD の複数参照の順序に関する問題を回避できます（git rev-parse FETCH_HEAD が返すのは、最初にフェッチされた参照の SHA だけです。そのため、複数参照のフェッチが気付かないうちに失敗します）。

MERGE_BASE=$(git merge-base origin/<baseRefName> $PR_HEAD_SHA) && echo "MERGE_BASE=$MERGE_BASE" && echo '=== COMMITS ===' && git log --oneline $MERGE_BASE..$PR_HEAD_SHA && echo '=== DIFF ===' && git diff $MERGE_BASE...$PR_HEAD_SHA

明示的な SHA のフェッチが拒否された場合（GitHub ではまれですが、tip 以外の SHA のフェッチを禁止する一部の GHES 設定では起こり得ます）、refs/pull/<number>/head をフェッチし、pull-ref のパターンを使って .git/FETCH_HEAD から PR の head SHA を読み取る方法にフォールバックします。

git fetch --no-tags origin "refs/pull/<number>/head"
PR_HEAD_SHA=$(awk '/refs\/pull\/[0-9]+\/head/ {print $1; exit}' "$(git rev-parse --git-dir)/FETCH_HEAD")

ケース B — PR が別のリポジトリにある場合：

ローカル Git は一切使用しません。差分とコミット一覧を API から読み取ります。

gh pr diff <pr-ref>
gh pr view <pr-ref> --json commits --jq '.commits[] | [.oid[0:7], .messageHeadline] | @tsv'

分類、構成、執筆のパイプラインは同じです。API にフォールバックしたことを、呼び出し元向けの出力に記載します。

また、ステップ 3 で証拠を保持できるよう、既存の PR 本文も取得します（どちらのケースでも必要です）。

---

ステップ 2：執筆前にコミットを分類する

コミット一覧を確認し、各コミットを分類します。

• 機能コミット -- PR の目的を実現するコミット（新機能、意図的なリファクタリング、設計変更）。説明の中心となります。
• 修正コミット -- 反復作業に関するコミット（コードレビューの修正、リントの修正、テストの修正、リベース時の競合解消、スタイルの整理）。読者には見せません。

説明の分量を決める際は、修正コミットを差し引いて考えます。12 件のコミットがあっても、そのうち 9 件が修正コミットなら、3 件のコミットからなる PR として扱います。

ステップ 3：証拠を提示するか判断する

ブランチ全体の差分から証拠を取得できるか判断します。

証拠を提示できるのは、ワークスペースで実証できる観察可能な動作に変更がある場合です。たとえば、UI、CLI 出力、実行可能なコードによる API の動作、生成された成果物、ワークフローの出力などです。

証拠を提示できないのは、次の場合です。

• ドキュメントのみ、Markdown のみ、変更履歴のみ、リリースメタデータのみ、CI／設定のみ、テストのみ、または純粋な内部リファクタリング
• 利用できない認証情報、有料／クラウドサービス、ボットトークン、デプロイ専用のインフラストラクチャ、または提供されていないハードウェアを必要とする動作

このスキルは、証拠の取得をユーザーに促しません。判断ロジックは次のとおりです。

1. PR モードでの呼び出し（単独の番号、#NN、pr:<N>、完全な URL など、取得した本文が存在する PR に解決される形式すべて）で、既存の本文に画像の埋め込みを含む ## Demo または ## Screenshots セクションがある場合は、更新または削除を指示するステアリングテキストがない限り、そのまま保持します。返す本文には保持したブロックを含めてください。呼び出し元がどの入力形式を使ったかにかかわらず、PR が存在し、その本文を読み取ったことが条件です。
2. 現在のブランチモード、または証拠ブロックのない PR モードでは、証拠セクションを完全に省略します。呼び出し元が証拠の取得を希望する場合は、ce-demo-reel を別途実行して結果を組み込むか、取得後に更新されたステアリングテキストを指定してこのスキルに再生成を依頼してください。

テスト出力に「Demo」や「Screenshots」というラベルを付けないでください。保持した証拠ブロックは、Compound Engineering バッジの前に配置してください。

---

ステップ 4：規模を見積もる前に説明の枠組みを定める

PR の説明の枠組みを明確にします。

1. 変更前：何が壊れていたか、制限されていたか、または不可能でしたか？（1 文）
2. 変更後：何が可能になったか、または改善されましたか？（1 文）
3. スコープの理由（分けられそうな懸念事項が 2 つ以上ある場合のみ）：なぜこれらをまとめてリリースするのですか？（1 文）

この枠組みを説明の冒頭にします。小規模で単純な PR なら、「変更後」の文だけで説明全体を構成してもかまいません。

---

ステップ 5：変更の規模を見積もる

規模（ファイル数、差分量）と複雑さ（設計上の判断、トレードオフ、複数領域にまたがる懸念事項）を評価し、説明の深さを選択します。

変更のプロファイル	説明の方針
小規模で単純（誤字、設定、依存関係の更新）	1～2 文、見出しなし。約 300 文字未満。
小規模だが単純ではない（バグ修正、動作変更）	短い説明、約 3～5 文。別個の懸念事項が 2 つある場合を除き、見出しは不要です。
中規模の機能またはリファクタリング	説明の枠組み（変更前／変更後／スコープ）を示したうえで、何をなぜ変更したかを説明します。設計上の判断を明記します。
大規模、またはアーキテクチャ上重要	説明の枠組みと、最大 3～5 件の設計判断に関する説明、1～2 文のテスト概要、主要なドキュメントへのリンクを含めます。目安は約 100 行、上限は 150 行です。仕組みが多数ある PR では、「Summary」レベルの表に一覧をまとめます。仕組みごとに H3 の小見出しを作成しないでください。レビュアーが精査するのは設計上の判断であり、項目の一覧ではありません。詳細は差分と仕様ファイルで確認できます。小見出しが 10 個以上になりそうなら、表にまとめてください。
パフォーマンスの改善	可能であれば、変更前と変更後の測定値を含めます。Markdown の表が適しています。

迷った場合は、短いほうを選んでください。説明の分量を変更の規模に合わせます。大規模な PR では、内容を増やすのではなく、より厳選してください。

---

ステップ 6：文章作成の原則を適用する

文章のトーン

リポジトリのコンテキストに文体の指針が記載されている場合は、それに従います。それ以外の場合は、次の原則に従ってください。

• 能動態を使います。ダッシュや -- で代用せず、句点、読点、コロン、または括弧を使います。
• 文の長さに変化をつけます。似た長さの文を 3 文続けて書かないでください。
• 主張を述べて、直後にその説明を加える書き方は避けます。読者を信頼してください。
• 平易な英語を使います。技術用語は問題ありませんが、ビジネス用語は避けてください。
• 「注目すべき点として」「重要なのは」「本質的には」「するために」「活用する」などの冗長な表現は避けます。
• 数字は単語ではなく数字で表記します（「3 files」であり、「three files」ではありません）。

執筆の原則

• 価値を先に伝える：何が変更されたかではなく、何ができるようになったか、何が修正されたかから書き始めます。より見落としやすい失敗は、成果ではなく仕組みから書き始めることです（「ハードコードされたキャプチャーブロックを段階的なスキルに置き換える」ではなく、「エビデンスのキャプチャーがウェブアプリだけでなく、CLI ツールやライブラリでも機能するようになりました」）。
• 導入段落を見出しなしで孤立させない：説明のどこかに ## 見出しを使う場合は、冒頭も見出しの下に置きます（例：## Summary）。セクションのない短い説明なら、見出しなしの段落で構いません。
• 経緯ではなく最終的な結果を説明する：説明するのは最終状態であり、そこに至るまでの経緯ではありません。反復の履歴、デバッグ手順、途中段階での失敗、開発中に発見して修正したバグは含めません。既存の PR を再生成する場合も同様です。前のバージョンから何が変わったかの記録ではなく、現在の状態に基づいて書き直します。例外は、設計上の選択を理解するために欠かせないプロセスの詳細です。
• コミットの説明が食い違う場合は、最終的な差分を優先する：コミット一覧は補足情報であり、正しい情報の基準ではありません。後で修正または取り消された途中段階の変更をコミットが説明している場合は、ブランチ全体の差分に基づいて最終状態を説明します。
• 自明でない点を説明する：差分を見れば明らかなことは説明しません。そのアプローチを選んだ理由、採用しなかった案、レビュアーが注意すべき点など、差分だけでは分からないことに紙幅を割きます。
• 必要な場合に構成を使う：見出し、箇条書き、表は理解を助けるために使うものであり、必須のテンプレート項目ではありません。
• データには Markdown の表を使う：変更前後の比較、パフォーマンスの数値、選択肢のトレードオフは、表で示すと分かりやすくなります。
• 中身のないセクションを作らない：該当しないセクションは省略します。「該当なし」や「なし」とは書きません。
• テスト計画は、テスト内容が自明でない場合に限る：レビュアーが思いつかないエッジケース、確認が難しい動作、特別なセットアップが必要な場合に記載します。「テストを実行する」以外に有用な案内がない場合は省略します。ブランチでテストファイルを追加する場合は、そのテストが対象とする内容とともにファイル名を記載します。
• 「コミット」セクションを作らない：GitHub にはコミット一覧を表示する専用タブがあります。PR 本文に「コミット」セクションを設けても、同じ情報が重複するだけで、新たな文脈は加わりません。コミットの順序や出荷の理由を説明する注釈が必要な場合を除き、省略します。
• レビューやプロセスのセクションを作らない：レビュアーがどのようにレビューすべきかを説明するセクション（確認項目のチェックリストやプロセスの箇条書き）は含めません。プロセスの説明は、レビュアーがコードを評価する助けになりません。特に注意して確認すべき、自明でない点があれば、該当する変更の説明に含めます。

視覚的な説明

変更が構造的に十分複雑で、文章だけではレビュアーがメンタルモデルを再構成するのに苦労する場合に限り、視覚的な補助を含めてください。

中心となる区別 — 構造と並列的な差異：

• 変更にトポロジーがある場合（有向関係を持つコンポーネント：呼び出し、フロー、依存関係、状態遷移、データ経路）は、Mermaid ダイアグラムを使います。ダイアグラムを使えば、「A は B と通信し、B は C と通信するが、C は A に応答しない」という関係を、表では表せない形で示せます。
• 変更に単一の形状における並列的な差異がある場合（同じ属性を持つ N 個の項目が、それぞれ異なる値を持つ）は、Markdown テーブルを使います。表を使えば、「オプション 1 のコストは X、オプション 2 のコストは Y、オプション 3 のコストは Z」という内容を簡潔に示せます。

アーキテクチャの変更にはほぼ必ずトポロジーが含まれるため、通常は Mermaid が適切です。「相互に作用するコンポーネント」を並べた表では関係が失われ、単なる一覧になってしまいます。表は、変更前後の測定値、オプション間のトレードオフ、フラグのマトリクス、設定項目の一覧など、本当に並列的なデータに限って使ってください。

視覚的な補助を含める場合（アーキテクチャやフローには表ではなく Mermaid を優先）：

PR の変更内容…	視覚的な補助
3 つ以上のコンポーネントが相互に作用するアーキテクチャ（コンポーネント間に有向関係があること — 誰が誰を呼び出すか、誰が何を所有するか、どのスキルがどこに委譲するか）	Mermaid のコンポーネント図またはインタラクション図。表で代用しないでください。表では関係を示せません。
複数の手順を含み、順序が自明でないワークフローまたはデータフロー	Mermaid のフロー図
3 つ以上の状態と、単純でない遷移を持つステートマシン	Mermaid の状態遷移図
3 つ以上の関連エンティティを含むデータモデルの変更	Mermaid の ERD
変更前後のパフォーマンスまたは動作の測定値（同じ指標で値が異なる）	Markdown テーブル
オプションまたはフラグのトレードオフ（同じ属性で各バリエーションを評価する）	Markdown テーブル
機能マトリクス／互換性グリッド	Markdown テーブル

迷った場合は、次のように考えてください。「情報にはエッジ（A → B）があるのか、それとも行（属性 × バリエーション）があるのか？」 エッジなら Mermaid、行なら表です。アーキテクチャには、ほぼ定義上、エッジがあります。

視覚的な補助を省略する場合：

• 規模が「1〜2 文」で済む場合
• 文章だけですでに明確に伝わる場合
• ダイアグラムが差分を視覚的に言い換えるだけになる場合
• 機械的な変更（名前変更、依存関係の更新、設定、フォーマット）の場合

形式の詳細：

• Mermaid（トポロジーには標準）。通常は 5〜10 ノード、真に複雑な変更では最大 15 ノードです。方向は TB を使ってください。ソースは代替手段として読みやすい形にしてください。
• ASCII ダイアグラムは、ボックス内に豊富な注釈を含める必要があるフローに使います。最大 80 桁です。
• Markdown テーブルは、並列的な差異のデータに限って使ってください。
• 関連する箇所にインラインで配置し、独立したセクションにはしないでください。
• 視覚的な表現と食い違う場合は、文章を優先してください。

生成したダイアグラムは、含める前に変更内容と照合してください。

番号付けと参照

PR の説明では、リスト項目の先頭に # を付けないでください。GitHub は #1、#2 を issue への参照と解釈し、自動的にリンクします。

実際の GitHub issue や PR に言及する場合は、org/repo#123 または完全な URL を使ってください。確認が取れていない限り、#123 だけの表記は使わないでください。

フォーカスヒントの適用

focus: ヒントが指定されている場合は、差分から導かれる説明に沿えて反映してください。フォーカスは方向付けとして扱い、上書きには使わないでください。差分で裏付けられない内容を作り上げたり、フォーカスに記載がないという理由だけで差分が求める重要な内容を省いたりしないでください。フォーカスと差分に実質的な食い違いがある場合（例：フォーカスでは「ベンチマークを含める」とあるが、差分にはベンチマークがない）は、内容を捏造するのではなく、呼び出し元が確認できる形で不一致を示してください（簡潔なインライン注記を残すか、呼び出し元に伝えてください）。

Step 7: タイトルを作成する

タイトルの形式：type: description または type(scope): description。

• type は、ファイル拡張子や差分の形ではなく、変更の意図に基づいて選びます。新機能には feat、バグ修正には fix、動作を維持する変更には refactor、ドキュメントのみの変更には docs、ツールやメンテナンスには chore、パフォーマンス改善には perf、テストのみの変更には test を使います。fix と feat のどちらにも見える場合は、原則として fix を使います。壊れた動作や不足している動作を改善する変更は、コードを追加して実装する場合でも fix です。feat は、これまでユーザーが実現できなかった機能に限定します。ユーザーが指定を上書きする場合があります。
• scope（任意）は、スキル／エージェント名、CLI の領域、共有領域など、役立つ範囲で最も狭いラベルにします。明確さにつながる単一のラベルがない場合は省略します。
• description は命令形で、小文字にし、全体を 72 文字未満にします。末尾にピリオドは付けません。
• リポジトリの最近のコミットにタイトルの規則が見られる場合は、それに合わせます。

破壊的変更には ! を使う（例：feat!: ...）か、本文に BREAKING CHANGE: フッターを記載します。

---

Step 8: 本文を作成する

本文を次の順序で組み立てます。

1. 冒頭 -- Step 4 の説明的な導入を、Step 5 で選んだ深さで記述します。説明に ## 見出しがほかにもある場合は、見出し（例：## Summary）の下に置きます。それ以外の場合は、見出しなしの段落にします。
2. 本文セクション -- この変更に必要なセクションだけを含めます。変更内容と理由、設計上の決定、データを示す表、複雑さに応じた視覚資料などを記載します。空のセクションは省略します。
3. テスト計画 -- 執筆方針に照らして自明でない場合に限ります。それ以外は省略します。
4. エビデンスブロック -- Step 3 で保持したブロックがある場合に限り含めます。捏造したり、プレースホルダーを入れたりしないでください。
5. Compound Engineering バッジ -- --- 区切り線を挟んで、フッターにバッジを追加します。既存の本文（pr: 入力の場合）にすでにバッジが含まれている場合は省略します。

バッジ：

---

[![Compound Engineering](https://img.shields.io/badge/Built_with-Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin)
![HARNESS](https://img.shields.io/badge/MODEL_SLUG-COLOR?logo=LOGO&logoColor=white)

ハーネスの照合表：

ハーネス	LOGO	COLOR
Claude Code	claude	D97757
Codex	（logo パラメーターを省略）	000000
Gemini CLI	googlegemini	4285F4

モデルスラッグ： スペースをアンダースコアに置き換えます。コンテキストウィンドウと推論レベルが分かっている場合は、かっこ内に追記します。例：Opus_4.6_(1M,_Extended_Thinking)、Sonnet_4.6_(200K)、Gemini_3.1_Pro。

---

Step 8b: 圧縮パス

本文を一時ファイルに書き込む前に、組み立てた本文を読み返し、以下の削除を適用します。

• 本文のセクションが ## Summary の内容を繰り返している場合は、そのセクションを削除します。Summary と差分があれば、読み手に必要な情報は伝わります。
• 「Testing」または「Test plan」が 2 段落を超える場合は、箇条書きにまとめます。
• 「Commits」セクションでコミット履歴を列挙している場合は、削除します。GitHub には専用のタブがあります。
• 「Review」またはプロセスに関するセクションでレビュー方法を列挙している場合は、削除します。真に自明でないレビュー上のヒントは、関連する変更の説明に組み込みます。
• 本文に、単一の仕組みをそれぞれ説明する H3 小見出しが 5 つ以上ある場合は、1 つの見出しの下に、仕組みごとに 1 行の表にまとめます。H3 の説明は、真に重要な設計上の決定を 2～3 件示す場合に限って使います。
• 本文がサイズ表の目標を 30% 以上超える場合は、Summary 以外で最も長いセクションを半分に圧縮します。

価値を先に示すチェック。 Summary の最初の文を読み返します。何かを移動、改名、追加したことを説明している場合（「この PR では 3 段階の自動修正を導入します……」など）は、何が可能になったか、あるいは何が壊れていて今は修正されたかを先に示す表現に書き換えます（「ドキュメントのレビューでは、ユーザーの判断が必要な指摘が 14 件以上出ていました。この PR により 4～6 件に減ります。」など）。

大きな PR では、網羅性よりも取捨選択が重要です。

ステップ 9：{title, body_file} を返す

作成した本文を OS の一時ファイルに書き込み、タイトルとファイルパスを返します。gh pr edit、gh pr create、その他の変更を加えるコマンドは実行しないでください。ユーザーに確認を求めないでください。適用するかどうかは呼び出し元が判断します。

BODY_FILE=$(mktemp "${TMPDIR:-/tmp}/ce-pr-body.XXXXXX") && cat > "$BODY_FILE" <<'__CE_PR_BODY_END__' && echo "$BODY_FILE"
<the composed body markdown goes here, verbatim>
__CE_PR_BODY_END__

引用符で囲んだセンチネル '__CE_PR_BODY_END__' を使うことで、本文内の $VAR、バッククォート、${...}、リテラルの EOF が展開されたり、終端記号と競合したりするのを防ぎます。mktemp や書き込みが失敗したときに、存在しないファイルのパスを伴う成功終了ステータスが返されないよう、echo "$BODY_FILE" は && で連結したままにしてください。

呼び出し元が簡単に抽出できるよう、明確なラベルを付けたブロック形式で返します。

=== TITLE ===
<title line>

=== BODY_FILE ===
<absolute path to the mktemp body file>

返却ブロックに本文の Markdown を出力しないでください。呼び出し元が BODY_FILE から読み取ります。

ステップ 1 が正常に終了した場合（PR がクローズ済み／マージ済み、範囲が無効、コミットリストが空）、本文ファイルは作成せず、理由の文字列だけを返します。

返却ブロックは引き継ぎであり、タスクの完了ではありません。 親スキル（例：ce-commit-push-pr）から呼び出された場合は、返却ブロックを出力した後、親の残りのステップ（通常は、返されたタイトルと本文ファイルを使った gh pr create または gh pr edit）の実行を続けてください。親のワークフローなしでユーザーから直接呼び出された場合を除き、返却ブロックの後で停止しないでください。

---

クロスプラットフォームに関する注意事項

このスキルは直接質問しません。差分に、呼び出し元が判断すべき曖昧な点がある場合（例：意図と実際の変更に食い違いがある、または証拠を技術的に取得できるものの、呼び出し元が事前にステージングしていない場合）は、返却内容または呼び出し元への短いメモで曖昧さを示してください。プラットフォームの質問ツールは呼び出さないでください。

ユーザーへの質問が必要な呼び出し元は、それぞれのプラットフォームでブロッキング質問ツールを使用してください。Claude Code では AskUserQuestion（スキーマが読み込まれていない場合は、先に ToolSearch で select:AskUserQuestion を指定して呼び出します）、Codex では request_user_input、Gemini では ask_user、Pi では ask_user（pi-ask-user 拡張機能が必要です）を使用します。ハーネスにブロッキングツールがない場合、または呼び出しに失敗した場合（例：Codex の編集モード）に限り、チャットで番号付きの選択肢に切り替えてください。スキーマの読み込みが必要という理由だけで切り替えてはいけません。質問を黙って省略しないでください。