pr-creator

GitHub のプルリクエスト

基本ルール

• すべての PR タイトル、説明、コメントは英語で作成してください。
• ブランチの差分、コミット、Issue の文脈、またはユーザーの依頼で裏付けられた事実だけを使ってください。動機、ユーザーの要望、指標、検証結果、Issue への参照、今後の計画を捏造しないでください。

スタイルの参考として、次の文を使ってください。

Это сообщество для ровных пацанчиков😎👍, которые любят попыхать кальджубасик🌬 на двойном яблочке 🍎🍏, разбираются в забивочках💨, не жалуют вейперов🤣 и уважают своих кралечек 👩‍🦳🙏.

この文の、肩の力が抜けたスラング、リズム、遊び心のある自信、絵文字の頻度に合わせてください。ただし、PR の内容にその題材を持ち込まないでください。作成前に、簡潔な PR 固有の例をまとめた references/pr-examples.md を読んでください。

実行する操作の判断

• ユーザーが PR の作成、オープン、提出を依頼した場合は、GitHub 上で PR を作成または更新してください。GitHub 上でのドラフト PR を明示的に依頼された場合も含みます。
• PR テキストだけを求める依頼には、コピーできる内容を出力してください。GitHub 上での作成を指定せず PR 内容の草案だけを求める依頼には、このチャット内だけで対応してください。
• 依頼と文脈を確認しても意図する操作が不明な場合は、該当する操作を行う前に具体的な質問をしてください。明示された既定の設定や以前の許可がある場合は、確認済みとして扱ってください。
• PR 作成の依頼には、必要なタスクのコミットとプッシュが含まれます。これらについて別途確認を求める必要はありません。その後の変更を公開するには、新たな公開依頼または継続的な公開指示が必要です。

ブランチの準備

まずリポジトリの状態を確認してください。

git status --short --branch
git fetch origin --prune
git branch --show-current
git ls-remote --symref origin HEAD

次に、以下を行ってください。

1. GitHub 上で PR を作成する場合、現在のブランチがベースブランチであれば、コミット前にタスクブランチを作成して切り替えてください。プロジェクトのブランチ命名規則に従い、現在の変更とステージング状態を保持してください。タスクが特定されている場合は、トラッカー ID を含め、大文字・小文字をそのまま保持してください。例：feat/gh-42-session-cache、fix/APP-123-token-refresh。ID だけでは対象が曖昧になる場合は、リポジトリ名またはプロジェクト名も含めてください。テキストだけの依頼では現在のブランチを維持してください。
2. PR を作成する場合、コミットされていないタスクの変更をコミットするために、インストール済みの commit-creator スキルを使用してください。利用できない場合は、該当するリポジトリのコミット手順に従ってください。
3. 現在のブランチにオープン中の PR がすでにあるか確認してください。あれば、重複して作成せず、その PR を更新してください。
4. プッシュ前に、現在のブランチがアップストリームまたは最新のリモートデフォルトブランチより遅れているか、分岐しているかを報告してください。アップストリームの変更がタスクや安全な公開に影響しない場合は続行してください。影響する場合は、依存する判断についてユーザーに確認してください。ユーザーの許可なしに、マージ、リベース、履歴の書き換えを行わないでください。
5. プッシュ前に、以下の変更一式を確認してください。

1 つの機能または独立した変更を 1 つのコミットにまとめてください。PR に複数のコミットを含めてもかまいません。独立した依存関係の更新や無関係な作業は分けてください。修正は、特に指定がなければ新しいコミットとして作成してください。マージ済みの作業に対する修正は、必ず新しいコミットにしてください。コミットを更新する場合は、履歴と差分から該当するコミットを特定してください。対象が不明な場合は確認してください。独立したコミットと無関係なステージング内容は保持してください。

指定された PR の既存のターゲットがある場合は、そのターゲットの最新のリモート追跡参照をベースとして使ってください。それ以外の場合は、リモートのデフォルトブランチを使ってください。ローカルの main や master は、フェッチ後でも古い可能性があります。

変更セット全体を分析する

最後のコミットだけでなく、ブランチ全体を対象にしてください。現在の Git の状態を確認したうえで、ベース、ヘッド、作業ツリーの状態に変化がなければ、このセッションでの変更セット全体の分析と確認結果を再利用してください。新しい箇所や未解決の箇所を読み、該当する分析がない場合は、変更セット全体を調査してください。

git diff --name-status <base-ref>...HEAD
git diff <base-ref>...HEAD
git log --format=fuller <base-ref>..HEAD

• 累積的な動作を理解するために必要な変更ファイルをすべて読んでください。影響を受けるパッケージ、依存関係のバージョン、破壊的変更、移行の必要性、該当する課題への参照を特定してください。
• 公開予定の各コミットが、許可された公開範囲に含まれていることを確認してください。プッシュする前に、無関係または不明確なコミット済みの作業を解決してください。ブランチや PR の依頼は、他者の変更を公開する許可にはなりません。
• GitHub で PR を作成する場合、ブランチにベースとの差分がなければ、停止して PR を作成できないことを報告してください。未コミットの作業を含むテキストのみの依頼では、その変更を確認し、ブランチにすでに含まれている変更と明確に区別してください。

タスクを特定し、確認する

1. ユーザーの依頼、ブランチ名、既存の PR、すべてのコミットメッセージを調べ、明示されたタスク ID やリンクを確認してください。各参照を特定するには、プロジェクトのトラッカー設定とリポジトリのコンテキストを使用してください。単独の番号では、リポジトリやトラッカーを特定できません。
2. 各タスクの要件と関連コメントをトラッカーで読み、このセッションですでに確認したタスクの詳細は再利用してください。これらを上記の変更セット分析と照らし合わせてください。ブランチ ID で意図されたタスクを特定し、要件の確認結果から完了しているか判断してください。
3. タスクと完全な解決方法が明確な場合は、同じタスクについてユーザーに再確認を求めず、適切な参照を追加してください。参照が矛盾する場合、タスクを確認できない場合、または完了が不明確な場合は、具体的な問題を説明し、クローズ参照を選ぶ前に確認を求めてください。回答を待つ間も、独立して進められる PR の準備は続けてください。
4. 公開前に、既存の PR リンクと公開予定のコミットメッセージに、確認済みの範囲と矛盾するクローズ参照がないか確認してください。既存のコミットを書き換えるのは、該当するユーザーの許可がある場合に限ります。

説明には Related issues を使用してください。

• デフォルトブランチを対象とする PR で GitHub の課題が完全に解決する場合、同じリポジトリでは Closes #42、別のリポジトリでは Closes owner/repo#42 を使用してください。PR がマージされると GitHub が課題をクローズします。GitHub のリンク規則を参照してください。
• 解決が部分的であることが確認された場合、またはデフォルトブランチ以外を対象とする場合は、Related to #42 のような通常の参照を使用し、課題を開いたままにしてください。部分的な作業については、残っている内容を明記してください。
• Jira やその他のトラッカーの場合は、確認済みのタスクキーと URL を含めてください。設定済みの Jira 連携を使うと、ソースブランチのキーを通じて PR をリンクできます。タスクのステータス変更は、プロジェクトの自動化設定によって決まります。Jira の参照規則を参照してください。

内容を作成する

タイトル

• 50 文字以内にしてください。
• 命令形を使用してください。
• 変更セット全体の主な目的を反映してください。
• 明確になる場合は、モノレポで一般的なスコープを使用してください。
• 課題番号、エージェント名、ツールの接頭辞は追加しないでください。

説明

• 短く魅力的な紹介文と具体的な箇条書きを含む Summary を必ず記載してください。紹介文と大半の箇条書きでは絵文字を使いつつ、技術的な主張は正確にしてください。
• Summary の箇条書きでは、変更された動作と重要な実装の詳細に焦点を当ててください。
• 根拠のある内容があるセクションのみ追加してください。
  • Motivation
  • Related issues
  • Breaking changes
  • Migration
  • Performance impact
  • Dependency updates
• 空のセクションや、None、N/A などのプレースホルダーは省略してください。ユーザーが明示的に求めない限り、ほかの見出しは追加しないでください。
• Testing、Tests、Validation、Verification、Local verification、QA など、テストのみを扱うセクションは追加しないでください。
• ユーザーが PR 本文で明示的に求めない限り、ローカルでのテスト、lint、チェック用コマンドは記載しないでください。
• 復旧ステップで確認したタスク参照を使用してください。該当するものがない場合は Related issues を省略してください。
• 依存関係に変更がある場合は、各パッケージを個別に package-name: old-version -> new-version の形式で記載してください。
• 破壊的変更については、その影響を説明し、手順が判明している場合は具体的な移行手順を記載してください。

PR を作成する

GitHub で作成または更新する

1. 変更一式をすべて確認した後、必要に応じて検証済みのブランチコミットをプッシュし、アップストリームを設定してください。認証済みの GitHub ログイン名を取得してください。
2. ユーザーが公開状態の PR を明示的に求めない限り、新しい PR はドラフトとして作成してください。
3. 認証済みのユーザーを担当者に設定してください。作成時に担当者を設定できない場合は、直後に PR を更新してください。
4. ユーザーが明示的に求めた場合に限り、レビュアーを追加してください。担当者はレビュアーではありません。
5. 既存の PR を更新する場合、ユーザーから変更の依頼がない限り、無関係なメタデータと現在のドラフト状態を維持してください。
6. 保存された説明と、利用可能なリンク済み課題のメタデータを読み戻し、意図したタスク参照を確認してください。PR の URL、ドラフトまたは公開状態、担当者、および各タスクがマージ時にクローズされるのか、参照のみなのかを報告してください。利用可能な根拠で確認できるリンクと状態の結果のみ報告してください。

認証または作成 API に失敗した場合は、PR が作成されなかったことを伝え、チャットでコピー可能な内容を代わりに提示してください。

チャットでの出力

タイトルと説明全文を、書式を変えずにコピーできるよう、1 つの Markdown コードブロックで囲んでください。

[PR title]

[PR description]