github

GitHub

GitHub には gh を使用します。ローカルのコミット／ブランチ／プッシュ／プルには git を使用します。詳細なレビューにはコード読み取りツールを使用します。

認証

gh auth status
gh auth login

ゲートウェイの HOME は、オペレーターの HOME と異なる場合があります。gh の認証情報が別の場所にある場合は、ゲートウェイサービスの環境変数に GH_CONFIG_DIR を設定して再起動します。

PR

gh pr list --repo owner/repo --json number,title,state,author,url
gh pr view 55 --repo owner/repo --json title,body,author,files,commits,reviews,reviewDecision
gh pr checks 55 --repo owner/repo
gh pr diff 55 --repo owner/repo
gh pr create --repo owner/repo --title "feat: title" --body-file /tmp/pr.md

PR の本文を作成または更新するときは、Runtime 行に sessionUrl=<exact-url> が指定されている場合に限り、最後に次のフッターを追加します。<sessionUrl> はその URL そのままに置き換えてください。URL を作成したり変更したりしないでください。sessionUrl は、明示的に公開されたセッションでのみ指定されます。指定がない場合はフッターを省略してください。非公開チャットの URL を代わりに使ったり、URL を取得するために共有を有効にしたりしないでください。公開マーカーがある場合はその後に置き、フッターは 1 つだけにして、必ず最後に配置してください。

---
[View the OpenClaw team session](<sessionUrl>)

URL はそのまま使用できます：gh pr view https://github.com/owner/repo/pull/55。

非同期マージ

リポジトリでネイティブのランディングワークフローが提供されている場合は、それを使用してください。それ以外で、プログラムによるマージが許可されている場合は、GitHub の非同期マージ APIを gh api 経由で使用してください。gh pr merge はこの API を選択しません。レビュー済みの head SHA を指定し、必須のレビュー／チェックを維持してください。また、スタックの構成を最初に確認してください。スタックされた PR を送信すると、開いている下位スタックの PR もマージまたはキューに追加されます。それらにも個別のレビューと承認が必要です。

gh api -H 'X-Octopool-Require: merge-async-v1' \
  --method PUT repos/owner/repo/pulls/55/merge-async \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  -f sha=REVIEWED_HEAD_SHA -f merge_method=squash -f merge_action=direct_merge
gh api -H 'X-Octopool-Require: merge-async-v1' \
  repos/owner/repo/pulls/55/merge-async/REQUEST_UUID \
  -H 'X-GitHub-Api-Version: 2026-03-10' -H 'Cache-Control: max-age=0'

Octopool のガードヘッダーは、api の直後に必ず配置してください。保護された古いラッパーは、マージ権限を書き換える前にこのヘッダーを拒否します。拒否された場合は、非同期ガードを含む Octopool ビルドを使用してください。サポート対象のラッパーは SHA／method／action／bypass を維持し、コミット文のみを書き換えます。ネイティブの gh ではヘッダーを渡せます。拒否を回避するためにヘッダーを削除したり、ポリシーを無効にしたり、raw バイナリを選択したりしないでください。

202 応答から details.uuid を保持してからポーリングしてください。pending は待機を意味します。merged には details.sha が含まれますが、最終的な PR／head の検証が必要です。enqueued はキューに追加されたことを意味し、マージ済みではありません。PR 自体を監視してください。設定済みのキューに従うには、merge_action=default（または明示的にキューへ追加する場合は merge_queue）を使用し、直接マージ専用の method／title／message フィールドは省略します。承認なしに bypass_rules を有効にしないでください。

failed の場合は details.message を報告してください。409 は既存のリクエストがあることを示します。再送信せずに、その UUID とオプションを確認してください。応答の消失、ポーリングエラー、24 時間経過後の結果期限切れが発生した場合は、盲目的な再試行や同期方式へのフォールバックではなく、状態を照合してください。待機時間に上限を設け、最新の読み取り結果を使ってポーリングしてください。非同期処理では、未完了のチェックに対する自動マージは設定されません。その動作が承認されている場合は、ネイティブのワークフローまたは gh pr merge --auto を使用してください。

ランディングの完了条件

ユーザーから PR のランディングまたはマージを求められた場合、最終的な完了条件は、レビュー、ワーカーの処理、CI の確認の終了ではなく、検証済みの PR の GitHub 上の状態です。

• gh pr view ... --json state,mergedAt,mergeCommit で state が MERGED と確認できるまで、ジョブを継続してください。
• レビューでの指摘、マージコンフリクト、失敗したチェック、変更要求が作業範囲内にある場合は、継続作業として扱ってください。修正し、必要なゲートを再実行して、更新後の head を正確に再評価してください。
• 保留中のチェックは待機状態であり、完了ではありません。リポジトリでサポートされている待機またはマージのワークフローを使用してください。一部のチェックが成功しただけで成功を報告しないでください。
• 作業を永続セッションに委任し、その実行がマージ前に停止した場合は、報告を最終結果と見なさず、同じセッションを継続してください。
• 継続に新たな権限、利用できない認証情報、または安全に推測できない製品上の判断が必要な場合に限り、ブロック状態として停止してください。具体的な阻害要因を報告し、PR は未マージのままにしてください。

Issue

gh issue list --repo owner/repo --state open --json number,title,labels,url
gh issue view 42 --repo owner/repo --json title,body,comments,labels,state
gh issue create --repo owner/repo --title "Bug: ..." --body-file /tmp/issue.md
gh issue comment 42 --repo owner/repo --body-file /tmp/comment.md
gh issue close 42 --repo owner/repo --comment "Fixed in ..."

CI／実行

gh run list --repo owner/repo --limit 10
gh run view <run-id> --repo owner/repo --json status,conclusion,headSha,url
gh run view <run-id> --repo owner/repo --log-failed
gh run rerun <run-id> --repo owner/repo --failed

API

gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'
gh api repos/owner/repo/labels --jq '.[].name'
gh api --cache 1h repos/owner/repo --jq '{stars: .stargazers_count, forks: .forks_count}'

構造化出力には --json と --jq を使用してください。バッククォート、シェルスニペット、環境変数名、ユーザーテキストを含むコメント／本文には --body-file を使用してください。