pr-draft-summary

PR ドラフトの概要

目的

対象となる作業の完了後、このリポジトリで必要となる PR 用の概要を作成します。変更内容の簡潔な概要に加え、openai-agents-js 向けの PR タイトルとドラフト説明を用意します。

完了時の確認事項

1. 最終回答を送信する前に、実際のタスク差分を確認します。PR ドラフトを明示的に求める依頼は、以下の自動実行対象外の条件よりも優先されます。ドラフトの作成によって、ブランチの作成、コミット、プッシュ、PR の作成が許可されることはありません。
2. 差分にランタイムコード、テスト、サンプル、ビルド／テスト設定、または動作に影響するドキュメントが含まれる場合は、このスキルを実行します。変更の規模が小さいと思われることを理由に、対象となる変更を除外しないでください。
3. 必要な検証と変更履歴の作業をすべて終えた後、「作業完了」の回答を送信する前に実行します。
4. 対象ファイルに変更がない場合、変更がすべてリポジトリのメタデータまたは動作に影響しないドキュメントのみの場合、タスクが会話のみの場合、またはユーザーが明示的に不要と指定した場合に限り、省略します。

自動で収集する入力情報（ユーザーに質問しないでください）

• 現在のブランチ：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 で確認します。
• プルリクエストのベース参照（origin/main を使用してください。フィーチャーブランチの upstream は PR のベースとして使用しないでください）：
  • BASE_REF=origin/main。ローカルに存在しない場合は main を使用します。
  • BASE_COMMIT=$(git merge-base "$BASE_REF" HEAD)。
• コミット済みのブランチ差分：git diff --name-only "${BASE_COMMIT}..HEAD" と git diff --stat "${BASE_COMMIT}..HEAD"。
• ベースの分岐点より先のコミット：git log --oneline --no-merges ${BASE_COMMIT}..HEAD。
• このリポジトリの分類シグナル：ランタイム（packages/、examples/、helpers/、scripts/）、テスト（packages/**/test、integration-tests/）、ドキュメント（docs/、README.md、AGENTS.md、.github/）、ビルド／テスト設定（package.json、pnpm-lock.yaml、pnpm-workspace.yaml、tsconfig*.json、tsc-multi.json、eslint.config.*、vitest*.ts）。

タスクの所有範囲

コミット済み、ステージング済み、ステージングされていない変更、および未追跡の変更を含む、タスクが所有する差分全体を使用します。ブランチの差分をコンテキストとして確認したうえで、ユーザーの依頼とタスクの開始時点の状態、実装履歴から、タスクが所有する変更を特定します。関連のない既存のブランチ変更やワークスペース変更はドラフトに含めないでください。ブランチ全体を対象とする依頼では、そのブランチの差分全体を対象とします。所有範囲が不明確で、ドラフトの内容が大きく変わる場合は、完成版として提示する前に具体的な疑問を解消してください。

無関係なフィーチャーブランチ上で特定のトピックに絞った修正を行う場合は、修正内容を説明し、適切なブランチ名をテキストで提案します。現在のチェックアウトとブランチはそのまま維持してください。現在のブランチ名に含まれる、無関係な課題のクローズ参照を引き継がないでください。

ワークフロー

1. ユーザーに確認せず、上記のコマンドを実行します。後続のコマンドで再利用できるよう、まず BASE_REF／BASE_COMMIT を計算します。現在のブランチの上流ではなく、origin/main または main と比較します。
2. タスクに関係するコミット済み差分に、タスクに関係するステージ済み、未ステージ、および未追跡の変更を組み合わせます。その差分が空の場合は、コードの変更が検出されなかったことを簡潔に伝え、PR ブロックの出力を省略します。
3. 「Category signals」に記載された変更対象パスから変更の種類を推測し、feature、fix、refactor、docs-with-impact に分類します。後方互換性のリスクとして指摘するのは、リリース済みの公開 API、外部設定、永続化データ、またはワイヤープロトコルに差分がある場合に限ります。このリスクは、未リリースのブランチのみの変更ではなく、最新のリリースタグを基準に判断します。
4. コミット済み、ステージ済み、および未ステージの差分から、タスクに関係する最も重要なパスと統計情報を使って、変更を1～3文で簡潔にまとめます。未追跡ファイルは --stat に含まれないため、必ず明記します。コミットメッセージは補足情報として使い、コミット済み差分の確認の代わりにしてはいけません。
5. 説明文の先頭に使う動詞を選びます。feature → adds、バグ修正 → fixes、リファクタリング／パフォーマンス改善 → improves または updates、ドキュメントのみ → updates。
6. ブランチ名を提案します。すでにこのタスク用のブランチにいる場合はそのまま使い、それ以外の場合は主な対象領域に応じて feat/<slug>、fix/<slug>、または docs/<slug> を提案します（例：docs/pr-draft-summary-guidance）。
7. 現在のブランチがこのタスクに属し、issue-<number>（数字のみ）に一致する場合は、そのブランチ名を提案として維持します。イシュー番号がある場合は、同一リポジトリ内のネイティブな参照 #<number> を使い、This pull request resolves #<number>. のような自動クローズ行を含めます。イシューを取得できなくても作業を妨げないでください。
8. 以下のテンプレートを使って PR のタイトルと説明を作成します。リポジトリ全体に適用される GitHub への貼り付け準備ルールを守ります。同一リポジトリ内のイシューまたは PR には #123、別リポジトリへの参照には owner/repo#123 を正確に使います。[PR #123](https://github.com/owner/repo/pull/123)、[#123](...)、Codex ナビゲーションリンク、ローカルファイルへのリンク、Codex 専用の引用マーカーや脚注、アプリ用ディレクティブは、コピー可能なブロックに出力しないでください。API ドキュメント、設計メモ、その他のリンク先への通常の説明的なリンクは、GitHub のイシューまたは PR の参照形式でない限り、そのまま維持します。
9. ブロックを返す前に参照を正規化します。同一リポジトリの URL または openai/openai-agents-js#<number> の参照はすべて #<number> に置き換え、別リポジトリのイシューまたは PR の URL はすべて owner/repo#<number> に置き換えます。その後、ブロック全体を再確認します。Markdown リンク化されたイシューまたは PR のラベル、同一リポジトリのリポジトリ名付き参照、GitHub のイシューまたは 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: or 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 any tests you ran.>

簡潔にまとめ、ブロックの前後に冗長な文章を加えず、Changes と説明文で同じ内容を繰り返さないでください。特に依頼されない限り、テストを列挙する必要はありません。