github

接続方法の選択

エージェントの環境で認証済みの GitHub MCP ツールが利用可能な場合は、まずそれを使用してください。特定の MCP サーバー名に依存せず、ツールの利用可否によって判断してください。以下のトークンと直接 API に関する手順は、GitHub MCP ツールが利用できない場合、または raw API や curl へのアクセスが明示的に必要な場合にのみ使用してください。

GitHub API とやり取りできる環境変数 GITHUB_TOKEN を利用できます。

`GITHUB_TOKEN` を使って `curl` で GitHub API とやり取りできます。 操作には必ず Web ブラウザーではなく GitHub API を使用してください。 プルリクエストを作成する際は、必ず `create_pr` ツールを使用してください。 ユーザーから GitHub Actions のステータスを確認するよう求められた場合は、まずワークフローの操作に `gh` を使用し、それが失敗した場合にのみ基本的な API 呼び出しに切り替えてください。 例： - ワークフローの実行を監視する `gh run watch`（https://cli.github.com/manual/gh_run_watch） - 完了まで確認する `gh pr checks 200 --watch --interval 10`。

以下の複数行シェルスニペットに相当する Windows PowerShell のコマンドは、references/windows.md にあります。

GitHub へのプッシュ時に認証の問題（パスワードの入力要求や権限エラーなど）が発生した場合、古いトークンの有効期限が切れている可能性があります。その場合は、リモート URL に現在のトークンを含めて更新してください：git remote set-url origin https://${GITHUB_TOKEN}@github.com/username/repo.git

プッシュに関する手順は以下のとおりですが、ユーザーから依頼された場合にのみ実行してください：

• main または master ブランチへ直接プッシュしないでください。
• Git の設定（ユーザー名とメールアドレス）はすでに設定されています。変更しないでください。
• openhands-workspace で始まるブランチを現在使用している場合があります。プッシュする前に、より適切な名前の新しいブランチを作成してください。
• まだプルリクエストを作成していない場合は、create_pr ツールを使って作成してください。
• 独自のブランチまたはプルリクエストを作成した後は、それを引き続き更新してください。明示的に依頼されない限り、新しいものを作成しないでください。必要に応じてプルリクエストのタイトルと説明は更新しますが、ブランチ名は変更しないでください。
• ユーザーから別途指定されない限り、ベースブランチには main ブランチを使用してください。
• プルリクエストを作成または更新した後は、プルリクエストへのリンクを添えて、ユーザーに短いメッセージを送ってください。
• ユーザーから明示的に依頼されない限り、プルリクエストをレビュー可能な状態にしないでください。
• 上記はできるだけ少ない手順で実行してください。たとえば、以下の bash コマンドを実行すれば、1 ステップで変更をプッシュできます：

git remote -v && git branch # to find the current org, repo and branch
git checkout -b create-widget && git add . && git commit -m "Create widget" && git push -u origin create-widget

プルリクエストのマージ（非同期マージ API）

重要： ユーザーから明確に依頼された場合にのみマージしてください。

GitHub は 2026 年 10 月に非同期マージ API をリリースしました。これは現在、プログラムによるマージで推奨されている方法であり、スタックされたプルリクエストをサポートする唯一のマージ API です。また、プルリクエストをマージキューに追加することもできます。PUT .../pulls/{n}/merge や GraphQL の mergePullRequest mutation よりも優先して使用してください。 GitHub MCP のマージツールは、引き続き古い同期エンドポイントを使用している場合があります。スタックされたプルリクエストやマージキューには、以下の呼び出しを使用してください。 ドキュメント：https://docs.github.com/en/rest/pulls/pulls#merge-a-pull-request-asynchronously

1. マージをリクエストします（merge_action：default は、ブランチにマージキューがあればそれを使用し、なければ直接マージします。または direct_merge / merge_queue を指定します）。merge_method、commit_title、commit_message は直接マージにのみ適用されます：

gh api -X PUT repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/merge-async -f merge_method=squash -f sha=<HEAD_SHA>

2. 202 が返された場合は details.uuid を取得し、status が pending でなくなるまで数秒おきにポーリングします：

gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/merge-async/<UUID>

最終的な status は merged（マージ済み）、enqueued（マージキューに追加済み。まだマージされていません）、または failed（details.message を確認）です。 PUT の 200 は、プルリクエストがすでにマージ済みまたはキューに追加済みであることを意味します。409 は、マージリクエストがすでに保留中であることを意味し、その UUID が返されます。

レビューコメントへの対応

• 各レビューコメントに対応する前に、内容を慎重に評価してください。すべてのフィードバックを反映する必要はありません。
  • 実際のバグを修正するものですか、それとも明確さを大幅に向上させるものですか？
  • プロジェクトのエンジニアリング原則（シンプルさ、保守性）に沿っていますか？
  • 提案された変更は効果に見合っていますか、それとも不必要に複雑になりますか？
• 明確なメリットなく冗長さを増やす提案、仮定上のエッジケースに対する過剰な設計、またはプロジェクトの実践的な方針に反する提案は、礼儀正しく断ってもかまいません。
• インラインのレビューコメントに対応した後（または対応しないと決めた後）は、該当するレビューのスレッドを解決済みにしてください。
• スレッドを解決する前に、フィードバックを却下する理由を説明するか、問題に対処した特定のコミット（コミット SHA など）を示す返信コメントを残してください。
• 修正がプッシュされるか、明確な判断が記録されてからスレッドを解決するようにしてください。
• GitHub GraphQL API を使用して、レビューのスレッドに返信し、解決してください（以下を参照）。
• PR を変更した後は、タイトルと説明が引き続き内容に合っていることを確認してください。スコープ、機能、または目的が変わった場合は更新してください。

GraphQL によるレビューのスレッドの解決

既存のレビューのスレッドをプログラムで解決するには、次の手順に従います。

1. スレッド ID を取得します（<OWNER>、<REPO>、<PR_NUMBER> を置き換えてください）。

gh api graphql -f query='
{
  repository(owner: "<OWNER>", name: "<REPO>") {
    pullRequest(number: <PR_NUMBER>) {
      reviewThreads(first: 20) {
        nodes {
          id
          isResolved
          comments(first: 1) {
            nodes { body }
          }
        }
      }
    }
  }
}'

2. フィードバックにどのように対応したかを説明する返信をスレッドに投稿します。

gh api graphql -f query='
mutation {
  addPullRequestReviewThreadReply(input: {
    pullRequestReviewThreadId: "<THREAD_ID>"
    body: "Fixed in <COMMIT_SHA>"
  }) {
    comment { id }
  }
}'

3. スレッドを解決します。

gh api graphql -f query='
mutation {
  resolveReviewThread(input: {threadId: "<THREAD_ID>"}) {
    thread { isResolved }
  }
}'

4. 失敗したワークフロー実行 ID を取得して、再実行します。

# Find the run ID from the failed check URL, or use:
gh run list --repo <OWNER>/<REPO> --branch <BRANCH> --limit 5

# Rerun failed jobs
gh run rerun <RUN_ID> --repo <OWNER>/<REPO> --failed