land

マージ

目標

• PR が main と競合していないことを確認します。
• CI をグリーンに保ち、失敗した場合は修正します。
• チェックに合格したら、PR をスカッシュマージします。
• PR がマージされるまでユーザーに返答せず、ブロックされない限り監視ループを実行し続けます。
• マージ後にリモートブランチを削除する必要はありません。リポジトリが head ブランチを自動削除します。

前提条件

• gh CLI で認証済みであること。
• PR ブランチにチェックアウトしており、作業ツリーがクリーンであること。

手順

1. 現在のブランチに対応する PR を見つけます。
2. プッシュする前に、すべてのチェックがローカルでグリーンであることを確認します。
3. 作業ツリーに未コミットの変更がある場合は、commit スキルでコミットし、push スキルでプッシュしてから次に進みます。
4. main に対するマージ可能性と競合を確認します。
5. 競合がある場合は、pull スキルを使って origin/main を取得してマージし、競合を解決してから、push スキルを使って更新済みのブランチを公開します。
6. Codex のレビューコメントがある場合は、それらに対応し、マージ前に必要な修正を行います。
7. チェックが完了するまで監視します。
8. チェックに失敗した場合は、ログを取得して問題を修正し、commit スキルでコミットし、push スキルでプッシュして、チェックを再実行します。
9. すべてのチェックがグリーンになり、レビューのフィードバックに対応したら、PR のタイトルと本文をマージの件名と本文に使用してスカッシュマージし、ブランチを削除します。
10. コンテキストガード： レビューのフィードバックを実装する前に、それがユーザーの明示した意図やタスクのコンテキストに反しないことを確認します。反する場合は、理由を添えてインラインで返信し、コードを変更する前にユーザーに確認します。
11. 異議申し立てのテンプレート： 同意できない場合は、受け止め＋理由＋代替案を含めてインラインで返信します。
12. 曖昧さの確認： 曖昧さによって作業が進められない場合は、確認フローを使用します（PR を現在の GH ユーザーに割り当て、そのユーザーにメンションして、返答を待ちます）。曖昧さが解消されるまで実装しないでください。
    • レビュアーよりも自分の判断が正しいと確信できる場合は、ユーザーに確認せずに進めてもかまいませんが、その理由をインラインで返信してください。
13. コメントごとの対応モード： 各レビューコメントについて、「受け入れる」「確認する」「異議を申し立てる」のいずれかを選びます。コードを変更する前に、インライン（Codex のレビューの場合はイシュースレッド）で対応モードを明記して返信します。
14. 変更前に返信： コード変更をプッシュする前に、必ず実施予定の対応を伝えます（レビューコメントにはインラインで、Codex のレビューにはイシュースレッドで返信します）。

コマンド

# Ensure branch and PR context
branch=$(git branch --show-current)
pr_number=$(gh pr view --json number -q .number)
pr_title=$(gh pr view --json title -q .title)
pr_body=$(gh pr view --json body -q .body)

# Check mergeability and conflicts
mergeable=$(gh pr view --json mergeable -q .mergeable)

if [ "$mergeable" = "CONFLICTING" ]; then
  # Run the `pull` skill to handle fetch + merge + conflict resolution.
  # Then run the `push` skill to publish the updated branch.
fi

# Preferred: use the Async Watch Helper below. The manual loop is a fallback
# when Python cannot run or the helper script is unavailable.
# Wait for review feedback: Codex reviews arrive as issue comments that start
# with "## Codex Review — <persona>". Treat them like reviewer feedback: reply
# with a `[codex]` issue comment acknowledging the findings and whether you're
# addressing or deferring them.
while true; do
  gh api repos/{owner}/{repo}/issues/"$pr_number"/comments \
    --jq '.[] | select(.body | startswith("## Codex Review")) | .id' | rg -q '.' \
    && break
  sleep 10
done

# Watch checks
if ! gh pr checks --watch; then
  gh pr checks
  # Identify failing run and inspect logs
  # gh run list --branch "$branch"
  # gh run view <run-id> --log
  exit 1
fi

# Squash-merge (remote branches auto-delete on merge in this repo)
gh pr merge --squash --subject "$pr_title" --body "$pr_body"

非同期監視ヘルパー

推奨：asyncio ウォッチャーを使用して、レビューコメント、CI、ブランチの更新を並行して監視します。

python3 .agents/skills/land/land_watch.py

終了コード：

• 2：レビューコメントを検出（フィードバックに対応）
• 3：CI チェックに失敗
• 4：PR の head が更新（自動修正のコミットを検出）

失敗への対応

• チェックに失敗した場合は、gh pr checks と gh run view --log で詳細を確認し、ローカルで修正して、commit スキルでコミットし、push スキルでプッシュしてから、監視を再実行します。
• 失敗が不安定なものかどうかは、状況に応じて判断してください。失敗が不安定なもの（例：1 つのプラットフォームだけでタイムアウトが発生した場合）であれば、修正せずに進めてもかまいません。
• CI が自動修正コミット（GitHub Actions が作成者）をプッシュしても、新たな CI 実行は開始されません。PR の最新コミットを検出し、ローカルに取り込んで、必要に応じて origin/main をマージし、実際の作成者によるコミットを追加してから、CI を再実行するために強制プッシュし、チェックのループを再開します。
• マージコミットで破損した pnpm ロックファイルのエラーが原因ですべてのジョブが失敗した場合は、最新の origin/main をフェッチしてマージし、強制プッシュして、CI を再実行します。
• マージ可能性が UNKNOWN の場合は、待ってから再確認します。
• 人間または Codex のレビューコメントが未対応の間は、マージしないでください。
• Codex のレビュージョブは失敗時に再試行され、ブロック要因にはなりません。レビューのフィードバックが利用可能になったことを示すのはジョブのステータスではなく、## Codex Review — <persona> という issue コメントの有無です。
• 自動マージは有効にしないでください。このリポジトリでは必須チェックがないため、自動マージによってテストがスキップされる可能性があります。
• 自分が以前に行った強制プッシュやマージによってリモートの PR ブランチが進んでいる場合は、不要なマージを避け、必要であればローカルでフォーマッターを再実行してから、git push --force-with-lease を実行します。

レビュー対応

• Codex のレビューは、GitHub Actions によって投稿される Issue コメントとして届くようになりました。コメントは ## Codex Review — <persona> で始まり、使用されたレビュー手法とガードレールが記載されています。これらは、マージ前に対応を表明する必要があるフィードバックとして扱ってください。
• 人間によるレビューコメントはブロッキング要件であり、新たなレビューを依頼したりマージしたりする前に、対応（返信と解決）する必要があります。
• 同じスレッドで複数のレビュアーがコメントした場合は、スレッドを閉じる前に各コメントへ返信してください（まとめて返信してもかまいません）。
• gh api でレビューコメントを取得し、接頭辞を付けて返信してください。
• インラインのフィードバックを確認するには、Issue コメントではなくレビューコメントのエンドポイントを使用してください。
  • PR のレビューコメントを一覧表示する：

    gh api repos/{owner}/{repo}/pulls/<pr_number>/comments
    

  • PR の Issue コメント（トップレベルのディスカッション）：

    gh api repos/{owner}/{repo}/issues/<pr_number>/comments
    

  • 特定のレビューコメントに返信する：

    gh api -X POST /repos/{owner}/{repo}/pulls/<pr_number>/comments \
      -f body='[codex] <response>' -F in_reply_to=<comment_id>
    

• in_reply_to には、GraphQL のノード ID（例：PRRC_...）ではなく、数値のレビューコメント ID（例：2710521800）を指定する必要があります。また、エンドポイントには PR 番号（/pulls/<pr_number>/comments）を含めてください。
• GraphQL のレビュー返信ミューテーションが禁止されている場合は、REST を使用してください。
• 返信時の 404 は通常、エンドポイントの誤り（PR 番号がない）またはスコープ不足を示します。まずコメント一覧を取得して確認してください。
• このエージェントが生成する GitHub コメントには、すべて [codex] を付けてください。
• Codex レビューの Issue コメントには、レビュー用スレッドではなく Issue のスレッドで [codex] を付けて返信し、フィードバックに今すぐ対応するのか、延期するのか（その理由も含めて）を明記してください。
• フィードバックへの対応に変更が必要な場合：
  • インラインのレビューコメント（人間によるもの）には、レビューコメントのエンドポイントと in_reply_to を使い、元のレビューコメントへのインライン返信として、実施する修正内容を返信してください（Issue コメントは使用しないでください）。
  • 修正を実装し、コミットして、プッシュしてください。
  • フィードバックを受け付けたのと同じ場所（Codex レビューには Issue コメント、レビューコメントにはインライン返信）に、修正の詳細とコミット SHA を含めて返信してください（[codex] ...）。
  • land watcher は、指摘を受け付けたことを示す新しい [codex] Issue コメントが投稿されるまで、Codex レビューの Issue コメントを未解決として扱います。
• 再実行が必要な場合（新しいコミットの後など）に限り、新しい Codex レビューを依頼してください。前回のレビュー以降に変更がない状態で依頼してはいけません。
  • 新しい Codex レビューを依頼する前に、land watcher を再実行し、未対応のレビューコメントがゼロ（すべてに [codex] のインライン返信がある状態）であることを確認してください。
  • 新しいコミットをプッシュすると、PR の同期時に Codex レビューワークフローが再実行されます（またはワークフローを手動で再実行できます）。レビュアーに最新の差分が伝わるよう、トップレベルに簡潔な概要コメントを投稿してください。

    [codex] Changes since last review:
    - <short bullets of deltas>
    Commits: <sha>, <sha>
    Tests: <commands run>
    

  • 前回の依頼以降に少なくとも 1 つ新しいコミットがある場合に限り、新しいレビューを依頼してください。
  • マージする前に、次の Codex レビューコメントを待ってください。

スコープと PR メタデータ

• PR のタイトルと説明には、直近の修正だけでなく、変更の全範囲を反映してください。
• レビューのフィードバックによってスコープが広がった場合は、今回対応するか、後回しにするかを判断してください。フィードバックは受け入れることも、後回しにすることも、却下することもできます。後回しにする場合や却下する場合は、理由（スコープ外、意図と矛盾する、不要など）を簡潔に添えて、ルートレベルの [codex] 更新で明記してください。
• レビューコメントで指摘された正確性の問題には対応してください。正確性に関する懸念を後回しにする、または却下する場合は、まず検証し、その懸念が当てはまらない理由を説明してください。
• 各レビューコメントを、正確性、設計、スタイル、明確化、スコープのいずれかに分類してください。
• 正確性に関するフィードバックについては、対応を完了する前に、具体的な検証結果（テスト、ログ、または根拠）を提示してください。
• フィードバックを受け入れる場合は、ルートレベルの更新に理由を一行で記載してください。
• フィードバックを却下する場合は、簡潔な代替案、または再検討する条件を提示してください。
• 小さな更新を何度も行うより、修正をまとめて行った後に、ルートレベルのコメントで「レビュー対応済み」と一度に報告することを推奨します。
• ドキュメントに関するフィードバックでは、ドキュメントの変更が実際の動作と一致していることを確認してください（レビューに応えるためだけに、ドキュメントのみを変更しないでください）。