pr-draft-summary

PR ドラフトの概要

目的

対象となるコード作業が完了した後、このリポジトリで必要な PR 用の概要を作成します。簡潔な概要に加え、PR にそのまま使えるタイトルと、「This pull request ...」で始まる説明文を作成します。このブロックは openai-agents-python の PR にそのまま貼り付けられる状態にします。

実行するタイミング

• PR ドラフトを明示的に求めるユーザーの依頼は、以下の自動実行の対象外条件より優先されます。
• 自動実行では、動作や契約を変更しない限り、実行時コードやテストのパスにおけるスペル、コメント、フォーマットのみの変更は編集上の変更です。このような変更では、自動ドラフトを作成しないでください。
• 最終回答を送る前に毎回、現在のタスクで実行時コード（src/agents/）、テスト（tests/）、サンプル（examples/）、ビルド／テスト設定、または動作に影響するドキュメントが変更されたかを確認してください。
• 該当する変更があった場合は、必要な検証を実施した後、最終回答を送る前にこのスキルを実行してください。変更の規模を判断基準にしないでください。
• ユーザーがプルリクエストの作成を依頼していない場合も、対象となるローカルのみの変更や未コミットの変更に対して実行してください。このテキストを作成しても、ブランチの作成、コミット、プッシュ、プルリクエストのオープンが許可されるわけではありません。
• 省略できるのは、些細なタスクまたは会話のみのタスク、動作に影響しないリポジトリメタデータやドキュメントのみのタスク、完全な $final-release-review レポートをリリース固有の PR 説明として使う $release-candidate-prep の明示的な引き継ぎ、またはユーザーが PR ドラフトのブロックを含めないよう明示した場合に限ります。この例外はリリース候補自体の準備に適用されます。リリース準備スキルの実装や変更には適用されません。

自動収集する入力（ユーザーに尋ねないでください）

• 現在のブランチ：git rev-parse --abbrev-ref HEAD。
• 作業ツリー：git status -sb。
• 未追跡ファイル：git ls-files --others --exclude-standard（git status -sb と併用し、表示されていることを確認してください。--stat には含まれません）。
• 変更されたファイル：git diff --name-only（ステージングされていない変更）および git diff --name-only --cached（ステージングされた変更）。サイズは git diff --stat および git diff --stat --cached で確認します。
• 最新のリリースタグ（リモートを含む検索を優先）：LATEST_RELEASE_TAG=$(.agents/skills/final-release-review/scripts/find_latest_release_tag.sh origin 'v*' 2>/dev/null || git tag -l 'v*' --sort=-v:refname | head -n1)。
• ベース参照（ブランチの upstream を使用し、なければ origin/main を使用）：
  • BASE_REF=$(git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || echo origin/main)。
  • BASE_COMMIT=$(git merge-base --fork-point "$BASE_REF" HEAD || git merge-base "$BASE_REF" HEAD || echo "$BASE_REF")。
• ベースのフォークポイント以降のコミット：git log --oneline --no-merges ${BASE_COMMIT}..HEAD。
• このリポジトリのカテゴリ判定の手掛かり：実行時コード（src/agents/）、テスト（tests/）、サンプル（examples/）、ドキュメント（docs/、mkdocs.yml）、ビルド／テスト設定（pyproject.toml、uv.lock、Makefile、.github/）。

ワークフロー

1. ユーザーに確認せず、上記のコマンドを実行します。後続のコマンドで再利用できるよう、まず BASE_REF／BASE_COMMIT を算出します。
2. ステージ済み、未ステージ、未追跡の変更がなく、${BASE_COMMIT} より先行するコミットもない場合は、コード変更が検出されなかったことを簡潔に伝え、PR ブロックの出力を省略します。
3. 「カテゴリの手がかり」に記載された変更対象パスから変更の種類を推測し、機能追加、修正、リファクタリング、影響を伴うドキュメント更新のいずれかに分類します。後方互換性のリスクを指摘するのは、差分によってリリース済みのパブリック API、外部設定、永続化データ、シリアライズされた状態、またはワイヤープロトコルが変更される場合に限ります。このリスクは、未リリースのブランチ内の変更ではなく、LATEST_RELEASE_TAG を基準に判断します。
4. 主なパス（上位 5 件）と git diff --stat の出力を使って、変更を 1〜3 文で簡潔に要約します。--stat には含まれない未追跡ファイルを、git status -sb／git ls-files --others --exclude-standard を使って明示します。作業ツリーがクリーンで ${BASE_COMMIT} より先行するコミットがある場合は、そのコミットメッセージを使って要約します。
5. 説明に使う先頭の動詞を選びます。機能追加 → adds、バグ修正 → fixes、リファクタリング／パフォーマンス改善 → improves または updates、ドキュメントのみ → updates。
6. ブランチ名を提案します。すでに main 以外のブランチにいる場合はそのブランチ名を維持します。それ以外の場合は、主な対象領域に基づいて feat/<slug>、fix/<slug>、または docs/<slug> を提案します（例：docs/pr-draft-summary-guidance）。
7. 現在のブランチ名が issue-<number>（数字のみ）に一致する場合は、そのブランチ名を維持します。利用可能であれば、GitHub API などを使って関連する Issue の情報を簡単に確認してもかまいませんが、取得できなくても処理を中断したり再試行したりしないでください。Issue 番号がある場合は、同一リポジトリ内のネイティブ参照 #<number> を使い、This pull request resolves #<number>. のような自動クローズ行を含めます。明示的な Issue の URL を追加したり、参照を Markdown リンクで囲んだりしないでください。
8. 以下のテンプレートを使って、PR のタイトルと説明を作成します。リポジトリ全体に適用される GitHub 貼り付け対応ルールに従います。同一リポジトリ内の Issue または PR には #123、別リポジトリへの参照には owner/repo#123 を正確に使ってください。[PR #123](https://github.com/owner/repo/pull/123)、[#123](...)、Codex ナビゲーションリンク、ローカルファイルへのリンク、Codex 専用の引用マーカーや脚注、アプリディレクティブは、コピーして使えるブロックに含めないでください。API ドキュメント、設計資料、その他の参照先への通常の説明的なリンクは、GitHub の Issue または PR のネイティブ構文でない限り、そのまま残します。
9. ブロックを返す前に参照を正規化します。同一リポジトリの URL または openai/openai-agents-python#<number> の参照はすべて #<number> に置き換え、別リポジトリの Issue または PR の URL はすべて owner/repo#<number> に置き換えます。その後、ブロック全体を再確認します。Markdown リンクになった Issue または PR のラベル、同一リポジトリ名付きの参照、GitHub Issue または PR の裸の URL が残っている場合は、ブロックを返さないでください。
10. 「出力形式」のブロックのみを出力します。その前に状況を伝える場合は、簡潔に英語で記載します。

出力形式

タスクの完了時には、文書化された省略ケースに該当する場合、またはユーザーが不要と指定した場合を除き、簡潔な以下の Markdown ブロックを、短い状況報告があればその後に追加します（英語のみ）。

# Pull Request Draft

## Branch name suggestion

git checkout -b <kebab-case suggestion, e.g., feat/pr-draft-summary-skill>

## Title

<single-line imperative title, which can be a commit message; if a common prefix like chore: and feat: etc., having them is preferred>

## Description

<include what you changed plus a draft pull request title and description for your local changes; start the description with prose such as "This pull request resolves/updates/adds ..." using a verb that matches the change (you can use bullets later), explain the change background (for bugs, clearly describe the bug, symptoms, or repro; for features, what is needed and why), any behavior changes or considerations to be aware of, and you do not need to mention tests you ran.>

簡潔にまとめ、ブロックの前後に冗長な説明を加えないでください。また、「Changes」と説明で同じ内容を繰り返さないようにしてください。特に求められない限り、テストを記載する必要はありません。