スタックPR
サイズ予算
1つのPRあたり約300行の変更、上限は500行を目指します。 そのサイズであれば、人間は変更全体を頭に入れて素早くレビューでき、AIレビュエージェントも表面的な指摘ではなく、明確で具体的な指摘を返します。
カウント対象： 手書きのコードとテスト。
カウント対象外： ロックファイル、生成コード（マイグレーション、コード生成、OpenAPI出力）、スナップショット、フィクスチャ、ベンダリングされたファイル。これらはざっと見るだけで、詳細には読みません。生成ファイルをPR本文にリストアップして、レビュアーがスキップすべきものを明確にします。
分割は作成前に行い、作成後に行わない。 分割は計画段階で決定します（coding-processを参照）。計画されたステージが500行を超える場合は、再計画します。一般的な分割ポイント：
- テストは独自のステージとして扱うことができます。 例：ロジックの単体テストと結合テスト、その後UIのE2Eテスト。
- スキーマまたはデータモデル、次にそれを使用するサービス、次にAPIサーフェス、最後にUI。
- 変更を容易にするリファクタリング、その後変更本体。
- 大きすぎて同梱できないドキュメント同期は、その上にドキュメント専用のステージを追加します。
真に分割不可能な変更（例：1つの一貫したマイグレーションや80ファイルにわたるリネーム）は、上限を超えても構いません。その場合はPR本文に理由を記述し、実際に読む必要がある部分をレビュアーに明示します。
各PR内ではアトミックコミットの原則は引き続き適用されます。予算はPR単位であり、コミットの衛生管理を置き換えるものではありません。
スタッキング
複数ステージの作業はPRのスタックとして出荷し、決して全体計画を1つのブランチで運んではいけません。各PRは1つのステージであり、mainではなく前のステージのブランチをターゲットにします。これにより、レビュアーが見る差分はそのステージの変更のみとなり、リスクの高いステージ（マイグレーションや認証変更など）は単独でレビューおよびリバートできます。
- 各ステージは前のステージの先端からブランチを作成します。最下部のPRのみ
mainをターゲットにします：gh pr create --base <previous-stage-branch> - 各PR本文に位置を明記します（
Stacked on #123）。これにより、順序を無視して開いたレビュアーも何を見ているか把握できます。 - ボトムアップでマージします。 ベースブランチが変更された場合（レビュー修正やベースのマージ）は、その上のブランチをリベースし、それらをフォースプッシュします。自身の未マージのスタックブランチをフォースプッシュするのは日常的な操作です。
mainや共有ブランチをフォースプッシュすることは決してありません。 - スタック内のいずれかのPRがマージされた後、次のステージを開始する前に残りのPRを新しいベースに同期します。
- レビューや検証パスからの修正は、新しいステージとして上に追加します。これにより、ビルドと修正が個別にレビュー可能な状態を維持します。
gh stack、Graphite、git-townなどのスタッキングツールはオプションです。プレーンなgitとghで十分です。
逐次レビュー
スタックは一度に1つのステージずつレビューします。 最下部のPRのみプロジェクトのレビュアーにレビューを依頼し（AGENTS.mdのプロジェクトゲートを参照）、次の手順を実行します：
- その1つのステージに対してレビューを依頼します。
- すべての指摘に対処します（以下を参照）。
- 再レビューを依頼し、そのステージが承認されるまで繰り返します。
- その後、次のステージのレビューを依頼します。
スタック全体に対して一度にレビューを依頼しないでください。ステージ1の指摘によって、ステージ2〜5に既に書かれたコメントが無効になる可能性があり、逐次レビューによりレビュアーの負担を限定できます。
ステージが停滞した場合（レビューが返ってこない、製品判断が必要な指摘があるなど）、フラグを立て、その答えに依存しない上のステージをローカルで継続して構築します。
レビュー指摘への対応（スタックPRかどうかを問わず）
- 各指摘を技術的に検証してから対応します。指摘が指すコードを読み、可能であれば問題を再現します。
- 修正するか、根拠を持って反論します。 人間でもボットでもレビュアーは通常のイベントとして自信満々に間違うことがあります。賛成するために悪い変更を行うことは、議論することより悪いです。パフォーマンス的な同意は不要です。
- 指摘を現実世界の確率で判断します。 現実的に起こり得ないシナリオに対する修正や、実質的な利益なしに複雑性を追加する提案には反論します。
- 失敗しないテストは追加しないでください。 バグの有無にかかわらずパスするテストはノイズです。最初に壊れたコードに対してテストを実行してください（
testingを参照）。 - 各指摘に返信し、レビュアーがその指摘がどうなったかを確認できるようにします：どのコミットで修正したか、またはなぜ修正しないか。