pr

プルリクエストを作成する

現在のリクエストによる変更を、指定されたベース、または指定がない場合はリモートが通知するデフォルトブランチに対する、レビュー可能な状態のプルリクエストに仕上げます。 他のスキルのインストールを求めるのではなく、必要なローカル Git 作業を完了してください。

無関係な作業は保持しつつ、リクエストの変更を論理的な Conventional Commits としてコミットします。認証情報やその他の機密ファイルを履歴に含めず、リポジトリのチェックに従い、デタッチ状態または保護されたチェックアウト上での作業は、適切な名前のブランチに移してください。

取得したターゲットをベースにブランチを作成し、予期しないリモートの作業を上書きせずに公開します。同じ head と base を持つ既存のプルリクエストがあれば再利用し、変更がすでにそのリモートのベースに反映されている場合は、重複して作成せず状態を報告してください。

実際の変更内容を説明するタイトルと本文を付けて、レビュー可能な状態でプルリクエストを作成します。リポジトリの AGENTS.md または CLAUDE.md に ## Issue tracker セクションがある場合は、そのセクションと、リンクされている詳細な規約があればそれも読みます。セットアップスキルがインストールされていなくても、従来のインライン規約を使用できます。 このセクションがない場合は、以下の課題に関する手順をすべて省略し、本文を変更しないでください。

各仕様フォルダーを1つの課題にリンクする

トラッカーが設定されている場合、作成前にこのプルリクエストに含まれる仕様フォルダーを集めます。ブランチで追加または変更され、HEAD に存在するすべての docs/specs/<slug>/ フォルダーと、コミットトレーラー Spec-Folder: docs/specs/<slug>/ で指定され、HEAD に存在するすべてのフォルダーが対象です。ブランチで削除されたフォルダーは除外します。フォルダーの spec.md に Issue: <tracker>:<id> 行がある場合は、その ID を使用し、新しい課題は作成しません。

この行がない各フォルダーについて、規約の作成操作を使って課題を1件作成します。タイトルは spec.md の最初の見出しを接頭辞なしで使用し、本文は規約の仕様セクションマーカーの間にある spec.md の内容を、仕様セクション1つとしてレンダリングしたものにします。一般的なトリアージでプルリクエストがリンクする前に処理されないよう、課題には規約のレビューシグナルを付けます。このセクションには、最初のセクションの本文、残りのセクション見出し、フォルダーのパス、および Blocked by: docs/specs/<other>/ 行で指定されたフォルダーの課題を含めます。課題はそれぞれ該当フォルダー自身の Issue: 行から読み取ります。課題が記載されていないブロッカーフォルダーは、その旨を報告してください。その後、規約で定められた ID 形式の Issue: <tracker>:<id> を仕様の他のリンクと並べて記載し、同じブランチにコミットしてから公開し、プルリクエストを作成します。課題をタイトルでトラッカー検索し、既存の課題を探したり再利用したりしてはいけません。課題を作成したものの、その行をコミットできなかった場合は、プルリクエストを作成する前に停止し、作成済みの ID を報告してください。再実行時に別の課題を作成せず、その ID を記録できるようにするためです。

リンクした各課題について、後続の処理でブランチがなくてもプルリクエストを見つけられるよう、プルリクエスト本文に Issue: <tracker>:<id> 行を記載します。既知の課題を直接修正するプルリクエストに仕様フォルダーがない場合も、同じ行を記載します。プルリクエストが実際にその課題の実装を含むことが差分と検証によって確認できる場合に限り、規約のクローズ参照を本文に記載します。トレーラーや Issue: 行だけでは、実装が含まれる証拠になりません。仕様のみのプルリクエストでは課題にリンクしますが、クローズ参照は記載しません。既存のプルリクエストを再利用する場合も同じ手順を適用し、その本文を要件に合わせて更新します。マージ、必須レビュー、リリースの判断は、このスキルの権限外です。

リンクされた規約を読めない場合は、課題の操作を推測したり、課題がリンクまたはクローズされたと主張したりせず、不足している情報を報告してください。

本文を理解しやすくする

会話履歴のないレビュー担当者に向けて、問題、具体的な変更前後の動作、変更理由、検証によって確認できることを説明します。変更の規模に応じた説明にしてください。タイプミスの修正なら、簡潔な説明と関連する検証だけで十分です。変更の評価に役立つ場合は、仕組み、複雑なフローの図、実際に検討した代替案とトレードオフ、影響を受けるユーザーや連携機能、未解決の判断事項を含めます。強調した判断事項以外も含め、変更全体を理解できるようにしてください。中身のないセクションや、実際には検討していない代替案・質問は省きます。

画面に関する変更では、レビュー担当者が評価対象の動作を確認できるようにします。同じフローを実行するベースとヘッドの動作を、ビューポート、データ、状態を一致させて記録するか、それらのリビジョンと一致することを確認済みの証拠を再利用し、変更前後の動画を違いとその理由の簡潔な説明とともに埋め込みます。コピー、スタイル、静的レイアウトのように、動きが評価に役立たない場合は、代わりにスクリーンショットを横並びで比較します。こうした細かな視覚的差異に動作の変更が伴う場合は、動画に加えて静止画の比較も追加します。変更前の状態がない画面では、ヘッドの動画だけを掲載します。動画を記録できない、安全にできない、または評価対象の動作に絞って編集しても添付ファイルの上限内に収められない場合は、スクリーンショットを比較し、動画がない理由を説明します。動画には代替テキストを付けず、それぞれにリビジョン、フロー、条件を示すラベルを付け、避けられない撮影条件の違いを明記します。実際に観察した結果と、ソースコードからの推測、未検証の状態を区別します。プロトタイプは実行時の証拠ではありません。既存の PR を更新する場合は、最終的な変更に合わせて説明と証拠を更新し、古くなった視覚的な主張を置き換えます。

アップロードする前に、スクリーンショットと動画に認証情報、個人データ、非公開情報が含まれていないか確認します。安全なシードデータを使うか、メディア全体を通して該当箇所をマスキングし、比較条件と関連する変更が見える状態に保ちます。現在の環境でサポートされている方法を使い、確認済みの安全なメディアだけを GitHub の添付ファイルとしてアップロードします。GitHub CLI を使う場合は、添付ファイルのサポート状況を確認してください。対応バージョンでは、gh pr create と gh pr edit で繰り返し指定できる --attach を受け付け、--body-file 内の該当するローカルメディア参照をアップロード済み URL に書き換えます。Markdown の表を使うと、2 枚の画像を横並びにできます。各動画は ![](path) の形式で、前後に空行を入れた段落に単独で記載し、プレーヤーとして表示されるようにします。他のテキスト内に参照を記載するとリンクとして表示され、参照されていない添付ファイルは本文の末尾に配置されます。レビュー用のキャプチャはリポジトリの履歴に含めないでください。別のメディアホストは必要ありません。

ベースの実行、キャプチャ、アップロードができない場合は、具体的にどこまで可能かを述べ、取得できた証拠だけを提示します。レビュー担当者が利用できると報告する前に、リモート上の本文と添付ファイルを確認してください。ローカルパスは公開済みの添付ファイルではありません。一部のアップロードだけで PR が作成される場合もあります。その場合は PR を確認して修正し、重複して作成しないでください。リモート上の本文にあるアップロード済みの添付ファイル URL は、本文を置き換える際に引き継ぎます。復旧できない場合は、利用できないローカル参照を、正直な制約の説明に置き換えます。

完了

リモートのプルリクエストが準備完了状態で存在し、ユーザーがその URL、ベース、ヘッドブランチ、および未完了のチェックや証拠を把握したら完了です。