appshapes/pr

ブランチをプルリクエスト経由で master にランディングします。/commit は個人のパスであり、直接 master に向かうものです。こちらは、CLAUDE.md がボットやエージェントに与えるブランチ上のカードを処理する Claude Code セッションのためのパスです（エージェントの作業ルール; ADR 0004）。プルリクエストは docs/how-to/ask-the-agent.md に記述されたループによってレビューされ、そのページは問題側からのループを説明しています。このスキルは作成者側のものです。つまり、何を実行し、何を待ち、各停滞時に何を行うべきか、ということです。ループが自動で行うすべてのことはループに任せ、間違ったタイミングで操作を行うことを防ぐためにこのスキルが存在します。

引数: $ARGUMENTS。カード番号を指定するとプルリクエストを開き（セクション1）、それを監視します（セクション2）。watch <番号> は開かれているプルリクエストを監視します。引数なしの場合: origin/master より先にコミットがあるブランチ上でプルリクエストが存在しない場合は開き、開かれているプルリクエストが存在する場合は監視し、master 上にある場合は停止して /commit が master からのパスであることを伝えます。

マージのみです。絶対に rebase や --force は使用しません。以下に指定された追記専用ファイル以外でコンフリクトが発生した場合は停止して戻します。

1. プルリクエストを開く

1. 状態を読み取る。 git fetch --quiet origin、次に git status（決して -uall は使用しない）、git log --oneline origin/master..HEAD、git diff、git diff --cached。ブランチ名は <card>-<slug> です。master 上にある変更は、最初に git switch -c <card>-<slug> でブランチに移動します。/commit と同様に CLAUDE.md との差分をチェックし（1クレートにつき1コミット、同じコミット内のドキュメント、データプレーン変更の場合はヒストグラム、依存関係の正当性、spec/ の場合は ADR）、追加されたすべての行にシークレットがないかスキャンします。生成ファイルや記録ファイルを除き、約1000行を超える差分は1つのプルリクエストとしては大きすぎます。docs/how-to/implement-a-feature.md のステップ3.8に従ってクレートとプレーンごとに分割し、最初のレビューのブロッカーが1回の修正実行に収まるようにし、残りはこのプルリクエストがマージされた後に独自のブランチから開いてください。

2. ゲートを1コマンドずつ実行する。 各コマンドの後に終了コードを読み取ります。

   just lint;      echo "lint exit $?"
   just test;      echo "test exit $?"
   just docs;      echo "docs exit $?"
   just lint-docs; echo "lint-docs exit $?"
   

   ゲートをパイプやパイプの && の後ろにチェーンしないでください。just lint 2>&1 | tail -1 && git commit は tail の終了コードを報告し、失敗したゲートは通過してしまいます。2026-10-26にプルリクエスト57のブランチに2つのコミットがその方法で到達し、1つは just lint に失敗し、もう1つはビルドされませんでした。それぞれがレビューサイクルを1回無駄にしました。非ゼロの終了コードはシーケンスを停止します。修正してから、このステップをやり直してください。

   ラップトップ上のゲートはラップトップのプラットフォームのみをコンパイルします。cfg(target_os = "linux") ブロックまたはその not 版を追加または変更する変更は、プッシュ前にLinux向けに型チェックする必要があります。Linuxゲートと両方のベンチホストがそれをビルドするためです。

   cargo check --workspace --all-targets --target x86_64-unknown-linux-gnu; echo "check exit $?"
   

   rustup target add x86_64-unknown-linux-gnu を1回実行するとターゲットがインストールされます。チェックにはリンカは必要ありません。2026-11-01のプルリクエスト94の最初のレビューは、すべてのmacOSゲートがパスしたファイルでCIが3つのLinuxエラーを報告したものでした。 3つ以上のアームを持つ cfg(target_os) ラダーは、どちらでもないターゲットでチェックする必要があります。rustup target add を1回実行した後、--target x86_64-unknown-freebsd を使用します。CIが実行する2つのターゲットでは、正確に1つのアームだけが有効になるため、そこでデッドとなる3つ目のアーム、または別のアームと重複するアームは、他の場所でのみ表示されます。2026-11-01のプルリクエスト95の2回目のレビューは、LinuxとmacOSを除くすべてのターゲットで2つの定数が2回定義されていたものです。

3. コミットする。 メッセージは /commit が記述するようにレビュー記録です。件名は <card>: <命令形の件名>、72文字以内。本文には、何が変更されたか、どの不変条件が番号で、その証拠（ゲート結果、ADR番号、データプレーンクレート下の変更の場合は両方のヒストグラム、変更が正確性を主張する場合の just conformance と just replay-check の結果）を含めます。ブランチに複数のコミットがあっても問題ありません。スクワッシュマージはプルリクエストのタイトルと本文を master 上のコミットとして使用するため（auto-merge.yml）、ブランチのメッセージはその草稿となります。

4. master をマージする。 git merge --no-edit origin/master。全員が追記するファイル（CHANGELOG.md、docs/SUMMARY.md、docs/glossary.md、spec/README.md、counters.toml、クレートの lib.rs）内のコンフリクトは、master の行を先にして両方を保持することで解決します（CLAUDE.md、エージェントの作業ルール）。それ以外のコンフリクトは戻します。マージコミットの後、ステップ2を再度実行します。

5. CIがチェックする内容を確認する。 CIの lint-docs は origin/master...HEAD、つまりブランチ全体に対して実行されますが、ラップトップはワーキングツリーまたは最後のコミットのみをチェックします（scripts/lint-docs.py、ヘッダー）。プッシュ前にCIの範囲を実行します。

   LINT_DOCS_RANGE=origin/master...HEAD just lint-docs; echo "lint-docs exit $?"
   

   これは、ブランチのあるコミットでADR Acceptedとされ、後のコミットで編集された場合に、CIはパスするがラップトップの HEAD~1..HEAD チェックでは「HEADでAcceptedかつ変更あり」として失敗する理由でもあります。ブランチの範囲全体では、そのADRは新しいものです。CIが実行する範囲を信頼してください。

6. プッシュして開く。 git push -u origin <branch>。本文はインラインではなく、ファイルに書き出します。これは master 上のコミットメッセージであり、ループの open-pr ジョブがエージェントから構築するのと同様に、ブランチのコミットメッセージから構築された完全なレビュー記録です。何が変更されたか、どの不変条件が番号で、証拠、そしてCIがチェックしないもの（データプレーン変更の場合はホストのジョブからのベンチ数値、パーサー変更後の just fuzz 結果）。最後に、イシューが存在する場合は Closes #<issue> で終了します。その後:

   gh pr create --title "<card>: <命令形の件名>" --body-file <ファイル> --label auto-merge
   

   auto-merge は作成時に付与します。レビュアーによる現在のHEADへの承認により、必要なチェックがパスしたときにランディングするスクワッシュマージが有効になり、パス上に人間は介在しません（auto-merge.yml）。ユーザーが最初にプルリクエストを読むように依頼した場合のみ、このラベルを付けないでください。

7. レビューが開始されたことを確認する。 1分以内に、gh run list --workflow "dispatch review" --limit 3 でプルリクエストのタイトルが付いた pull_request_target 実行が表示され、さらに1分後に gh run list --workflow "review pr" --limit 3 で review pr <番号>, attempt 1 が表示されます。レビュアーは master 上で実行されるため（ADR 0005）、Actionsタブに表示され、プルリクエストのチェックの中には含まれません。2分経っても何も表示されない場合: gh pr edit <番号> --add-label review を実行して再度確認します。

2. プルリクエストを監視する

状態を一度に読み取り、その後待機します。レビューはプッシュ後約10分で着地します。修正実行には最大30分かかります。bench (linux) ジョブと bench (grip) ジョブはそれぞれ専用のホスト bench と grip を持ちます。ポーリングは5分以上間隔を空け、以下のルールで指定されていないものには一切触れないでください。ここでの待機はすべてループ自身の作業進行中であり、停滞はルールです。

gh pr view <番号> --json state,mergeable,headRefOid,labels,reviewDecision
gh api repos/{owner}/{repo}/pulls/<番号>/reviews --jq '.[] | "\(.submitted_at) \(.state) \(.commit_id[0:7]) \(.user.login)"'
gh run list --workflow claude --limit 5
gh run list --workflow "dispatch review" --limit 5
gh run list --workflow "review pr" --limit 5
gh pr checks <番号>

• claude[bot] から変更要求があった場合。 claude 実行（イベント pull_request_review）は1分以内に開始され、ブランチにブロッカーを適用します。実行中または待機中は何もプッシュしないでください。サイクルごとに1人の書き込み者のみです。その実行はプルリクエストごとに1つずつキューされ、GitHubはキューごとに1つの保留中の実行を保持するため、あなたのプッシュは独自のレビューを取得し、そのレビューが開始する修正実行は既に待機中のものをキャンセルします。プルリクエスト57では、2つのレビューがその方法で修正実行を失い、実際に機能した実行は2つ古いHEADのレビューに応答しました。修正者は各ブロッカーをそのテストがパスしたときにコミットし、進みながらプッシュするため、1回の実行中にHEADが複数回移動する可能性があります。レビューは残されたHEADに対して行われます。実行が完了すると、その最後のジョブは、エージェントが最後のプッシュの前にプッシュしたHEADに対してGitHubが保留していた ci 実行をキャンセルし（claude.yml、「修正者が残したHEADに対して保留されていた実行をキャンセルする」：保留されたままの実行は、マージ時にブランチが削除されると失敗として終了し、メールが送信されます。auto merge 実行は、マージ直前にそのジョブが保留していたものを一掃します）、最後のプッシュで保留されていた ci 実行を承認し、HEADにまだ dispatch review 実行がない場合、または修正がプルリクエスト本文のみの編集であった場合（claude.yml、「エージェントのプッシュのレビューを依頼する」）は review ラベルを追加します。これにより、実行終了から1分以内に dispatch review 実行が表示されます。1分経過しても表示されない場合のみ、自分で review を追加してください。

• 「自律修正上限に達しました」。 4回目の変更要求レビューで修正者の役割は終了します（claude.yml、MAX_ATTEMPTS: 3）。プルリクエストは作成者のものになります。修正、ステップ2、ステップ4、プッシュを行ってください。人間によるプッシュは、それ自身の dispatch review 実行を発生させます。

• 修正者が適用できないブロッカー。 修正者の実行は、.github/workflows/**、.claude/**、spec/**、bench/baseline.json への書き込みを拒否するため（claude.yml、settings.deny）、ブロッカーがすべてこれらのファイルにあるレビューは、「Fix session ended without a push landing ... and without a change to the pull request body」というメッセージで実行を終了します。これらは最初のレビューから作成者の担当です。適用してプッシュしてください。プルリクエスト本文のみに対するブロッカーは、修正者自身が gh pr edit で適用し、その実行は変更されていないHEADのレビューを要求します（イシュー11）。本文を自分で編集する場合は、gh pr edit <番号> --body-file <ファイル> を実行し、その後 gh pr edit <番号> --add-label review を実行してください。本文の編集ではレビューは発生しないためです。

• HEADから15分経過してもレビューがない場合。 gh run list --workflow "review pr": レビュアーセッションが判定なしで終了した実行は、ループ自身によって attempt 2 として再試行されます。失敗した attempt 2 は2回目のミスであり、gh pr edit <番号> --add-label review で3回目が開始されます。あなたのプッシュ後に dispatch review 実行がまったくないHEADの場合も、同じラベルを使用します。

• CONFLICTING。 master がブランチの下で移動しました。GitHubはコンフリクトしているプルリクエストに対して実行を開始しません。ステップ4、ステップ2、プッシュを行ってください。

• 赤いチェック。 gh run view <実行ID> --log-failed。bench (linux) はホスト bench で実行され、bench (grip) は grip で実行されます。どちらのジョブが実行中である可能性がある間は、決してそのホストでベンチを実行しないでください（gh run list で in_progress または queued と表示されます。ホスト上で pgrep -a cavalry-bench）。そこでのゲート障害は、何かを変更する前に bench-compare 自身の行から読み取ってください。

• 承認された場合。 auto-merge.yml は、commit_id が現在のHEADである承認に対してマージを有効にします。古いHEADの承認は何も有効にせず、新しいHEADは独自のレビューを取得します。マージは必要なチェックがパスしたときにランディングします。gh pr checks <番号> --required。承認後にブランチが移動した場合、GitHubによって拒否され、auto merge 実行がその理由を説明します。新しいチップのためにGitHubが実行を発生させた場合は通知と実行の緑色、ループが自動でレビューします。1分以内に何も発生しなかった場合は失敗、プルリクエストオブジェクトはまだ承認されたコミットを指しており、その場合はプッシュのみがそれを移動させます: ステップ4、ステップ2、プッシュ（auto-merge.yml のヘッダー; 2026-11-04のプルリクエスト106）。

• マージされた場合。 git fetch --quiet origin と git log --oneline -1 origin/master で、プルリクエストのタイトルが付いたスクワッシュコミットが表示されます。gh run list --branch master --workflow ci --limit 1 はそのCI実行を示しており、その実行が緑色になるまでプルリクエストは完了しません。その後、コミットハッシュをカードにコメントしてアーカイブし、just tidy を実行します。これにより、ブランチがローカルで（そのワークツリーとともに）廃止され、GitHubは既にorigin上でそれを削除しています。

3. 報告

プルリクエスト番号とURL、各レビューの判定、誰がどのプッシュで応答したか、master 上のスクワッシュコミットとそのCI実行、そして just tidy が実行されたことを報告します。上記のルールが適用された場合は、どのルールでその理由も述べてください。プルリクエストが修正実行またはレビューを待機している場合は、その旨と次に確認すべきことを述べてください。急かすためのラベルは追加しないでください。