pr

プルリクエスト

人間のレビュアーが変更を理解できるようにします。問題、実現した動作、重要な判断、評価に必要な根拠を明確にしてください。

このスキルは、公開と PR の提示を担当します。commit はアトミックなコミットを担当し、stacked-pr はスタックの構成、送信、連鎖的なリベースを担当し、pr-followup はフィードバック、CI の修復、ドラフトからレビュー可能な状態への移行を担当します。これらの担当スキルは、現在のリクエストまたは継続的な指示に含まれる作業に限って使用してください。承認を受けた呼び出し元に戻る場合は、そのワークフローを継続します。このフェーズを完了しても、上位タスクは終了しません。 issue-workflow は、利用側プロジェクトの標準的な遷移ポリシーに沿った、リンク済みチケットの同期を担当します。

操作を判断する

• 作成： リクエストがあり、該当する PR が存在しない場合、対象のコミットを公開して PR を作成します。ユーザーがレビュー可能な状態を希望していない限り、デフォルトではドラフトにします。 PR の作成リクエストがあった場合、同一のオープン PR がすでに作成要件を満たしている場合も含め、公開後に Drive モードで pr-followup も実行します。
• 更新： 既存の承認の範囲内で、既存のオープン PR を更新します。公開済みの最終差分全体に基づいて本文を書き直し、有効な根拠と必須のテンプレート内容は保持してください。更新リクエストに対して、再度承認を求める必要はありません。
• ドラフトのみ： コミット、プッシュ、GitHub への変更を行わず、依頼された文章の作成または確認のみを行います。その成果物に必要な読み取りだけを行ってください。
• 上限の確認： 共通のサイズ確認のみを行い、判定結果を返します。是正、公開、その後の処理は呼び出し元が担当します。この操作では、他の PR フェーズに進みません。

該当する PR がクローズ済みまたはマージ済みの場合、それは履歴上の状態です。URL と状態を示し、ユーザーがその操作を選択していない限り、編集、再オープン、置き換えは行わないでください。未解決の重要な判断についてのみ確認し、すでに承認済みの操作については確認を求めないでください。ブロッカーがある場合は、依存する作業を一時停止します。役立つ場合は、独立した準備作業を完了してください。

ID と対象範囲を確定する

現在のブランチ、ステータス、リモート、上流ブランチ、HEAD を確認します。次の項目を特定してください。

1. プッシュ先のリポジトリ、リモート、参照： ブランチの検証済み上流ブランチ、または指定された送信先を使用します。リモート URL を実際の GitHub リポジトリに対応付けてください。リモート名はヒントにすぎません。ブランチの上流ブランチはプッシュ先であり、PR のベースではありません。
2. 対象リポジトリ： 指定された PR URL または明示された対象を優先します。フォークから上流へコントリビュートする場合、誤ってフォークを選ばず、検証済みの親リポジトリを使用してください。フォークと親リポジトリのどちらかが重要な点で曖昧なままなら、確認してください。
3. 該当する PR： 関連するすべての結果を次のコマンドで照会します。 gh pr list --repo <target> --state all --head <branch> --json number,url,state,headRefName,headRepository,headRepositoryOwner,baseRefName,isDraft ここで --head に指定するのはブランチであり、owner:branch ではありません。ブランチとヘッドリポジトリの ID の両方で絞り込んでください。照会が失敗または不完全な場合、結果がないとは判断できません。指定された URL があれば、直接確認してください。該当する PR が複数ある場合は、どれを対象とするか確認が必要です。
4. ベース： 既存の PR では実際のベースを維持します。新しい PR では、明示的に指定され検証済みのベース、または対象リポジトリのデフォルトブランチを使用してください。依存関係のあるブランチを検出し、構成に関する判断は stacked-pr に引き継ぎます。対象リポジトリの SSH リモートを使って選択したベースをフェッチし、ローカルの main を鵜呑みにせず、その ID を検証してください。
5. リビジョン： 説明する対象のヘッドを特定します。作成や公開では選択したローカルコミット、メタデータのみの作業では公開済みヘッドが対象です。ベースとヘッドの SHA を記録してください。無関係な作業中の変更やステージ済み変更は保持します。これらはメタデータのみの更新を妨げず、その変更内容の説明に含めてはいけません。

ホストのチェックアウト所有権と PR リンク要件に従ってください。チェックアウトの切り替えが必要な場合は、ホストの引き継ぎ手順を使用し、worktrunk に引き継ぎます。ホストに実際の PR を登録する機能がある場合は、その PR を登録してください。

変更内容とリポジトリを理解する

実質的な主張をする前に、references/claims.md を読んでください。<base-ref>..<head> のすべてのコミットと、<base-ref>...<head> の全差分を調べたうえで、重要な動作を現在のコード、ゲート、失敗経路までたどってください。生成物、バイナリ、依存関係、移行に関する変更も考慮してください。テストが存在することをテストが通過したことと同一視したり、イシューの意図を実際の成果と同一視したりしないでください。

独立した懸念事項を個別にレビュー、リバートできるか確認してください。分割が実質的に役立つ場合は分割を推奨してください。ただし、公開済みの履歴を書き換えたり、スタックの順序を入れ替えたり、差分を短くするためだけに動作とそのリグレッションテストを分離したりしないでください。必要な生成物を自動的にノイズと見なさないでください。

本文を作成する前に、以下を読んでください。

• リポジトリの指示と CONTRIBUTING.md に記載された PR ルール。
• 解決済みのベースにあるルート、docs/、.github/ およびそれらの PULL_REQUEST_TEMPLATE/ ディレクトリ内のテンプレート。このブランチによって変更されたテンプレートは、既存の慣例を示すものではありません。変更内容とリポジトリのルールに適したテンプレートを選び、選択に影響する不明点が残る場合に限り質問してください。
• 最近マージされた PR を最大 10 件。本文を 3 件、3 件未満の場合はすべて読んでください。関連する最近の例は文体の参考にし、記載されたルールより優先しないでください。

必要な証拠にアクセスできなかった場合は、失敗した検索内容を正確に示し、判明していないものとして記録してください。入手できた証拠で裏付けられる作業は続け、欠けている慣例を捏造しないでください。

レビューサイズの上限を確認する

リクエスト、プロジェクトルール、またはタスク記録で PR サイズの上限が定められている場合は、この確認を行ってください。選択したベースとヘッドを正確な SHA に解決し、適用される上限を記録してください。上限確認のリクエストでリビジョンまたは上限が不足している場合は、unverified とします。

テスト、生成されたテキスト、ロックファイルを含む、完全な <base-sha>...<head-sha> 差分の追加行数と削除行数を測定してください。合計には Git の --shortstat を使い、バイナリエントリの特定には --numstat を使ってください。純増行数、コミットごとの合計、除外したパスは使わないでください。コミットを分割しても PR の規模は小さくなりません。

正確なリビジョン、行数、上限、バイナリのレビュー負担を含め、結果を within-cap、over-cap、unverified のいずれかで返してください。差分を取得できない場合は unverified です。プッシュまたは PR 作成の前に、最新の結果が within-cap であることを必須としてください。ベースまたはヘッドが変更された場合、それ以前の件数は無効になります。上限を超えた作業は、公開担当者が task-breakdown に送り、作業単位を見直します。上限を黙って免除したり、公開済みの履歴を書き換えたりしないでください。ドラフトのみ、またはメタデータのみの作業では、コードを追加で出荷せずに違反を報告できます。

レビュー用の作成

タスク、ブランチ、コミット、または PR 本文でチケットに言及している場合は、PR との関連付けを作成する前に、Inspect モードで issue-workflow を使用してください。提示されたチケットまたは検索の手がかり、正確なリポジトリ、ベース、および完了または貢献の関連付けを裏付ける根拠を渡してください。チケットの識別情報と関連付けを確認し、紐付けられたチケットがない場合は not applicable を返します。確認済みのチケットについては、プロジェクトで許可されているリンク形式とイベントポリシーを返します。Update では有効なリンクを維持してください。トラッカーへの書き込みを許可するものではありませんが、Draft のみの場合も対象です。QA のために課題をオープンのままにするポリシーの場合は、チケットをでっち上げたり、クローズを示すキーワードを使用したりしないでください。

タイトルまたは本文を作成する際は、すべて references/review-packet.md を読んでください。変更されたインターフェース、フロー、または構造を視覚的に確認しやすい場合は、references/visual-evidence.md を読んでください。必要最小限で有用な図、実際のスクリーンショット、または測定に基づく比較を使用してください。

目に見える UI の変更については、アプリ、キャプチャツール、アップロード経路を利用できる場合、該当するアプリの状態をキャプチャして添付してください。変更リビジョンに一致する、すでに検証済みのキャプチャがある場合は、それを使用してください。PR 本文にアップロードするには、references/attachments.md に従ってください。ローカルのスクリーンショットパスは添付ファイルではありません。前提条件を利用できない場合は、どの前提条件が利用できないのか、またどの証拠を保持したのかを報告してください。

テンプレートに記載されたガイダンスを含むリポジトリの要件に従い、意味のあるテンプレート項目を維持してください。スタイル規約によって有用な背景情報が省かれる場合は、簡潔な追記が適切です。重大な逸脱については説明してください。ユーザーが明示的に上書きしない限り、厳密に強制される形式には引き続き従ってください。本文の長さはレビューの判断に見合ったものにしてください。

Update の場合は、これまでの修正履歴を追記するのではなく、公開済みの変更全体に基づいて下書きを作成し、古くなった主張を置き換えてください。引き継ぐ前に、有用なリンク、スクリーンショット、完了済みのチェックリスト項目を再検証してください。技術的な意味を損なわずに明確な文章を書くため、利用可能な場合は communicate-clearly を使用してください。

公開と検証

Git または GitHub に変更を加える場合は、 references/publication.mdをお読みください。この文書では、ID の確認、 SSH による公開、非対話型コマンド、ドラフトの状態、書き込み後の検証を扱います。 上限のある作業では、選択した公開リビジョンを使って、プッシュまたは PR の作成直前に 共通のサイズ確認を行ってください。 確認可能なタイトルと本文、および必要な検証を完了してから、残る承認を求めてください。 既存の依頼と継続的な承認は、一律の確認を要求するソースワークフローより優先されます。

フェーズが正常に完了した場合、正確な PR URL、想定される head と base、 検証済みのタイトルと本文、意図した状態、および依頼されたメタデータの変更のみが揃っています。 添付したキャプチャについては、アップロード先の参照が検証され、表示とアクセスの結果が記録されています。 書き込みに失敗した場合、確認するまでは結果不明として扱ってください。タイムアウト時は、重複作成や成功したという報告を避けてください。 チケットが紐づく作成依頼では、検証済みの pr-created イベント、チケット URL、正確な PR/head/base、 ドラフト状態、完了との関連を指定して、issue-workflow を実行してください。 ドラフトも対象に含めます。プロジェクトで pr-ready が選択されており、この検証済み PR がすでにドラフトではない場合は、 今すぐ pr-ready を調整してください。発生しないドラフトから準備完了への遷移を待たないでください。 それ以外の場合は、設定された準備完了イベントを保留のままにしてください。作成依頼が、作成条件をすでに満たす 特定のオープン PR に対するものである場合も同様です。この場合は、過去の遷移をそのまま再実行せず、現在の状態ガードを使います。 単独の Update では、作成イベントを生成しません。同期結果は別途返してください。トラッカーの遷移がブロックされても、公開は取り消されず、 独立した後続処理も停止しません。issue-workflow が見つからない場合は、その不足を報告し、 状態を推測せず、再開に備えてイベントを保持してください。 作成依頼では、結果を返す前に Drive モードで pr-followup を続行してください。 正確な PR URL、head/base の SHA、ドラフト状態、検証結果、既知の保留作業を渡してください。 関連する場合は、検証済みのチケットとの関連、遷移結果、および issue-workflow で指定されたマージ配信の担当者または未対応のイベントも渡してください。 このフェーズでは、同じ依頼の下でフィードバック／CI の修正、準備完了、準備完了後の観察を扱います。 作成結果の要約だけで終了しないでください。明示的な作成のみの指示がある場合は、公開後に戻ってください。 明示的なドラフト維持の指示は pr-followup に渡してください。準備完了への遷移なしで Drive が実行されます。 作成依頼を満たす Update も Drive に続行します。単独の Update と Draft-only では Drive を開始しません。 フォローアップから呼び出された Update は、既存のループに戻ります。公開の副作用としてマージを行ってはいけません。 pr-followup を利用できない場合は、検証済みの公開結果を報告し、続行を妨げるスキルの不足を明記してください。

返却

created、updated、draft-only、blocked のいずれかを報告し、判明している場合は PR URL、 head/base、ドラフト状態、関連する検証結果、残作業、および本文とは別に保持した調整事項を記載してください。 実際のコマンドとその結果を含め、今回の実行内容と過去の記録を区別してください。 draft-only の場合は、依頼された文面を提示し、変更が行われていないことを明記してください。 ブロッカーがある場合は、満たせなかった前提条件または未解決の判断事項を示し、完了済みの作業を保持してください。 検証済みの ID、リビジョン、公開状態を、権限のある呼び出し元に引き継いでください。

ソースの保守を依頼された場合は、origin.txt と references/upstream-updates.mdを使って agent-instructions を実行してください。