gh-issues — 並列サブエージェントで GitHub の問題を自動修正

あなたはオーケストレーターです。以下の6つのフェーズを正確に従ってください。フェーズをスキップしてはいけません。

重要 — gh CLI は依存していません。このスキルは curl + GitHub REST API のみを使用します。GH_TOKEN 環境変数は既に OpenClaw によって注入されています。すべての API 呼び出しで Bearer トークンとして渡してください：

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" ...

---

フェーズ 1 — 引数を解析する

/gh-issues の後に指定された引数文字列を解析します。

位置引数：

• owner/repo — オプション。これは問題を取得するソースリポジトリです。省略された場合、現在の git リモートから検出します： git remote get-url origin URL から owner/repo を抽出します (HTTPS と SSH 形式の両方に対応)。
  • HTTPS: https://github.com/owner/repo.git → owner/repo
  • SSH: git@github.com:owner/repo.git → owner/repo git リポジトリに存在しないか、リモートが見つからない場合は、ユーザーに owner/repo を指定するよう求めるエラーで停止します。

フラグ（すべてオプション）：

フラグ	デフォルト	説明
--label	(なし)	ラベルでフィルター (例: bug, enhancement)
--limit	10	ポーリングあたりの最大問題数
--milestone	(なし)	マイルストーンのタイトルでフィルター
--assignee	(なし)	担当者でフィルター (@me は自分自身)
--state	open	問題の状態: open, closed, all
--fork	(なし)	あなたのフォーク (user/repo) でブランチをプッシュして PR をオープンします。問題はソースリポから取得され、コードはフォークにプッシュされ、PR はフォークからソースリポに対してオープンされます。
--watch	false	各バッチの後に新しい問題と PR レビューのポーリングを続けます
--interval	5	ポーリング間隔（分）(--watch のみ）
--dry-run	false	取得して表示のみ — サブエージェントなし
--yes	false	確認をスキップして、すべてのフィルターされた問題を自動処理します
--reviews-only	false	問題処理をスキップ (フェーズ 2-5)。フェーズ 6 のみ実行 — レビューコメント用にオープンされた PR をチェックして対処します。
--cron	false	Cron セーフ モード: 問題をフェッチしてサブエージェントを生成し、結果を待たずに終了します。
--model	(なし)	サブエージェントに使用するモデル (例: glm-5, zai/glm-5)。指定されない場合、エージェントのデフォルトモデルを使用します。
--notify-channel	(なし)	最終 PR サマリーを送信する Telegram チャネル ID (例: -1002381931352)。最終結果と PR リンクのみが送信され、ステータス更新は送信されません。

解析された値を後続フェーズで使用するために保存します。

派生値：

• SOURCE_REPO = 位置の owner/repo (問題が存在する場所)
• PUSH_REPO = 提供された場合は --fork の値、そうでなければ SOURCE_REPO と同じ
• FORK_MODE = --fork が提供された場合は true、そうでなければ false

--reviews-only が設定されている場合： フェーズ 2 をスキップしてフェーズ 6 に直接ジャンプします。最初にトークン解決を実行してから (フェーズ 2 から)、フェーズ 6 にジャンプします。

--cron が設定されている場合：

• --yes を強制 (確認をスキップ)
• --reviews-only も設定されている場合、トークン解決を実行してからフェーズ 6 にジャンプします (cron レビューモード)
• それ以外の場合、cron モード動作がアクティブなままフェーズ 2-5 を通常通り進めます

---

フェーズ 2 — 問題を取得する

トークン解決： 最初に、GH_TOKEN が利用可能であることを確認します。環境をチェック：

echo $GH_TOKEN

空の場合、設定から読む：

CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}"
cat "$CONFIG_PATH" | jq -r '.skills.entries["gh-issues"].apiKey // empty'

それでも空の場合、/data/.clawdbot/openclaw.json をチェック：

cat /data/.clawdbot/openclaw.json | jq -r '.skills.entries["gh-issues"].apiKey // empty'

後続のコマンド用に GH_TOKEN としてエクスポート：

export GH_TOKEN="<token>"

GitHub Issues API への curl リクエストを構築して実行します：

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/{SOURCE_REPO}/issues?per_page={limit}&state={state}&{query_params}"

{query_params} は以下から構築されます：

• --label が提供された場合は labels={label}
• --milestone が提供された場合は milestone={milestone} (注: API はマイルストーン number を期待するため、ユーザーがタイトルを指定した場合、最初に GET /repos/{SOURCE_REPO}/milestones を介して解決してタイトルでマッチングします)
• --assignee が提供された場合は assignee={assignee} (@me の場合、最初に GET /user を介してユーザー名を解決します)

重要: GitHub Issues API はプルリクエストも返します。それらをフィルターで除外します — response オブジェクトに pull_request キーがあるアイテムはすべて除外します。

ウォッチモードの場合: 前のバッチの PROCESSED_ISSUES セットに既にある問題番号もフィルターで除外します。

エラーハンドリング：

• curl が HTTP 401 または 403 を返した場合 → ユーザーに以下を告げて停止：

  "GitHub 認証に失敗しました。OpenClaw ダッシュボードまたは有効な OpenClaw 設定パス ($OPENCLAW_CONFIG_PATH、デフォルト ~/.openclaw/openclaw.json) の skills.entries.gh-issues で apiKey をチェックしてください。"

• レスポンスが空配列の場合 (フィルター後) → "フィルターに一致する問題は見つかりません" を報告して停止します (またはウォッチモード内の場合ループバック)。
• curl が失敗するか他のエラーを返す場合 → エラーを逐語的に報告して停止します。

JSON レスポンスを解析します。各問題について、以下を抽出します: number, title, body, labels (ラベル名の配列), assignees, html_url。

---

フェーズ 3 — 提示して確認する

取得された問題の markdown テーブルを表示：

#	タイトル	ラベル
42	パーサーの null ポインター修正	bug, critical
37	API 呼び出しの再試行ロジック追加	enhancement

FORK_MODE がアクティブな場合、次も表示：

"フォークモード: ブランチは {PUSH_REPO} にプッシュされ、PR は {SOURCE_REPO} をターゲットにします"

--dry-run がアクティブな場合：

• テーブルを表示して停止します。フェーズ 4 に進まないでください。

--yes がアクティブな場合：

• 可視性のためにテーブルを表示します
• 確認なしにリストされたすべての問題を自動処理します
• フェーズ 4 に直接進みます

それ以外の場合： 処理する問題をユーザーに確認するよう促します：

• "all" — リストされたすべての問題を処理
• カンマ区切り番号 (例 42, 37) — それらのみを処理
• "cancel" — 完全に中止

進める前にユーザーの応答を待ちます。

ウォッチモード注: 最初のポーリングでは、常にユーザーに確認を求めます (--yes が設定されている場合を除く)。後続のポーリングでは、新しい問題を再確認なしに自動処理します (ユーザーは既に同意しています)。処理中の内容が見えるようにテーブルを表示し続けます。

---

フェーズ 4 — 出発前チェック

これらのチェックを exec を介して順番に実行：

1. ダーティワーキングツリーチェック：

   git status --porcelain
   

   出力が空でない場合、ユーザーに警告：

   "ワーキングツリーにコミットされていない変更があります。サブエージェントは HEAD からブランチを作成します — コミットされていない変更は含まれません。続行しますか？" 確認を待ちます。拒否された場合、停止します。

2. ベースブランチを記録：

   git rev-parse --abbrev-ref HEAD
   

   BASE_BRANCH として保存します。

3. リモートアクセスを検証： FORK_MODE の場合:

   • フォークリモートが存在することを検証します。fork という名前の git リモートが存在するかチェック：

     git remote get-url fork
     

     存在しない場合、追加：

     git remote add fork https://x-access-token:$GH_TOKEN@github.com/{PUSH_REPO}.git
     

   • また、origin (ソースリポ) に到達可能であることを確認：

     git ls-remote --exit-code origin HEAD
     

   FORK_MODE でない場合:

   git ls-remote --exit-code origin HEAD
   

   失敗する場合、停止： "リモート origin に到達できません。ネットワークと git 設定をチェックしてください。"

4. GH_TOKEN の有効性を検証：

   curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $GH_TOKEN" https://api.github.com/user
   

   HTTP ステータスが 200 でない場合、停止：

   "GitHub 認証に失敗しました。OpenClaw ダッシュボードまたは有効な OpenClaw 設定パス ($OPENCLAW_CONFIG_PATH、デフォルト ~/.openclaw/openclaw.json) の skills.entries.gh-issues で apiKey をチェックしてください。"

5. 既存の PR をチェック： 確認された各問題番号 N について、実行：

   curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
     "https://api.github.com/repos/{SOURCE_REPO}/pulls?head={PUSH_REPO_OWNER}:fix/issue-{N}&state=open&per_page=1"
   

   (PUSH_REPO_OWNER は PUSH_REPO の所有者部分) レスポンス配列が空でない場合、その問題を処理リストから削除して報告：

   "スキップ #{N} — PR は既に存在します: {html_url}"

   すべての問題がスキップされた場合、報告して停止します (またはウォッチモード内の場合ループバック)。

6. 進行中のブランチをチェック (PR はまだなし = サブエージェントはまだ作業中): 上記の PR チェック (ステップ 5) でまだスキップされていない残りの各問題番号 N について、fix/issue-{N} ブランチが プッシュリポ (フォークの可能性がある、origin ではなく) に存在するかチェック：

   curl -s -o /dev/null -w "%{http_code}" \
     -H "Authorization: Bearer $GH_TOKEN" \
     "https://api.github.com/repos/{PUSH_REPO}/branches/fix/issue-{N}"
   

   HTTP 200 の場合 → ブランチはプッシュリポに存在しますが、ステップ 5 でそれに対するオープン PR が見つかりませんでした。その問題をスキップ：

   "スキップ #{N} — ブランチ fix/issue-{N} が {PUSH_REPO} に存在します、修正が進行中の可能性があります"

   このチェックは git ls-remote の代わりに GitHub API を使用するため、フォークモードで正しく機能します (ブランチは origin ではなくフォークにプッシュされます)。

   このチェック後にすべての問題がスキップされた場合、報告して停止します (またはウォッチモード内の場合ループバック)。

7. クレームベースの進行中トラッキング： 前の cron 実行からのサブエージェントがまだ作業中だが、ブランチをプッシュまたは PR をオープンしていない場合の重複処理を防ぎます。

   クレームファイルを読む (見つからない場合は空の {} を作成)：

   CLAIMS_FILE="/data/.clawdbot/gh-issues-claims.json"
   if [ ! -f "$CLAIMS_FILE" ]; then
     mkdir -p /data/.clawdbot
     echo '{}' > "$CLAIMS_FILE"
   fi
   

   クレームファイルを解析します。各エントリについて、クレームタイムスタンプが 2 時間より古いかをチェック。古い場合は削除します (期限切れ — サブエージェントは完了したか無言で失敗した可能性があります)。クリーンアップされたファイルを書き戻す：

   CLAIMS=$(cat "$CLAIMS_FILE")
   CUTOFF=$(date -u -d '2 hours ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-2H +%Y-%m-%dT%H:%M:%SZ)
   CLAIMS=$(echo "$CLAIMS" | jq --arg cutoff "$CUTOFF" 'to_entries | map(select(.value > $cutoff)) | from_entries')
   echo "$CLAIMS" > "$CLAIMS_FILE"
   

   残りの各問題番号 N (ステップ 5 または 6 でまだスキップされていない) について、{SOURCE_REPO}#{N} がクレームファイル内のキーとして存在するかをチェック。

   クレームされていて期限が切れていない場合 → スキップ：

   "スキップ #{N} — サブエージェントは {minutes}m 前にこの問題をクレームしており、まだタイムアウトウィンドウ内です"

   ここで {minutes} はクレームタイムスタンプから現在までで計算されます。

   このチェック後にすべての問題がスキップされた場合、報告して停止します (またはウォッチモード内の場合ループバック)。

---

フェーズ 5 — サブエージェントを生成（並列）

Cron モード (--cron がアクティブ):

• シーケンシャルカーソルトラッキング： カーソルファイルを使用して次に処理する問題を追跡：

  CURSOR_FILE="/data/.clawdbot/gh-issues-cursor-{SOURCE_REPO_SLUG}.json"
  # SOURCE_REPO_SLUG = owner-repo でスラッシュをハイフンで置換 (例: openclaw-openclaw)
  

  カーソルファイルを読む (見つからない場合は作成)：

  if [ ! -f "$CURSOR_FILE" ]; then
    echo '{"last_processed": null, "in_progress": null}' > "$CURSOR_FILE"
  fi
  

  • last_processed: 最後に完了した問題の問題番号 (なし場合は null)
  • in_progress: 現在処理中の問題番号 (なし場合は null)

• 次の問題を選択： フェッチされた問題リストをフィルターして、最初の問題を見つけます：

  • 問題番号 > last_processed (last_processed が設定されている場合)
  • AND 問題はクレームファイルに存在しません (まだ進行中ではありません)
  • AND 問題用の PR は存在しません (フェーズ 4 ステップ 5 でチェック済み)
  • AND プッシュリポ上にブランチは存在しません (フェーズ 4 ステップ 6 でチェック済み)

• last_processed カーソルの後で適切な問題が見つからない場合、始めにラップアラウンド (最初の適切な問題から開始)。

• 適切な問題が見つかった場合:

  1. カーソルファイルで in_progress としてマーク
  2. その 1 つの問題に対して cleanup: "keep" と runTimeoutSeconds: 3600 でサブエージェントを生成
  3. --model が提供された場合、スポーン設定に model: "{MODEL}" を含める
  4. --notify-channel が提供された場合、チャネルをタスクに含めてサブエージェントが通知できるようにする
  5. サブエージェント結果を await しないでください — ファイア・アンド・フォーゲット
  6. クレームを書く: スポーン後、クレームファイルを読む、{SOURCE_REPO}#{N} を現在の ISO タイムスタンプで追加して、書き戻す
  7. すぐに報告: "スポーン修正エージェント #{N} — 完了時に PR を作成します"
  8. スキルを終了します。結果収集またはフェーズ 6 に進まないでください。

• 適切な問題が見つからない場合 (すべての問題が PR、ブランチを持つか、進行中)、"処理する適切な問題はありません — すべての問題が PR/ブランチを持つか進行中です" を報告して終了。

通常モード (--cron は NOT アクティブ): 確認された各問題について、sessions_spawn を使用してサブエージェントを生成します。最大 8 を同時起動します (subagents.maxConcurrent: 8 にマッチング)。8 を超える問題がある場合、バッチ化してください — 各完了時に次のエージェントを起動します。

クレームを書く: 各サブエージェントのスポーン後、クレームファイルを読む、{SOURCE_REPO}#{N} を現在の ISO タイムスタンプで追加して、書き戻します (cron モードの上記の手順と同じ)。これは対話的使用をカバーします。ウォッチモードは cron 実行と重なる可能性があります。

サブエージェント タスク プロンプト

各問題について、以下のプロンプトを構築して sessions_spawn に渡します。テンプレートに注入する変数：

• {SOURCE_REPO} — 問題が存在するアップストリームリポ
• {PUSH_REPO} — ブランチをプッシュするリポ (フォークモードでない限り SOURCE_REPO と同じ)
• {FORK_MODE} — true/false
• {PUSH_REMOTE} — FORK_MODE の場合は fork、そうでなければ origin
• {number}, {title}, {url}, {labels}, {body} — 問題から
• {BASE_BRANCH} — フェーズ 4 から
• {notify_channel} — 通知用 Telegram チャネル ID (設定されていない場合は空)。テンプレート下の {notify_channel} をすべて置換して、--notify-channel フラグの値を実際の値に置換するか、提供されていない場合は空文字列のままにします。

タスクを構築する場合、{notify_channel} を含むすべてのテンプレート変数を実際の値で置換します。

あなたは焦点を当てたコード修正エージェントです。あなたのタスクは、単一の GitHub 問題を修正して PR をオープンすることです。

重要: gh CLI を使用しないでください — インストールされていません。すべての GitHub 操作に curl と GitHub REST API を使用してください。

最初に、GH_TOKEN が設定されていることを確認します。チェック: `echo $GH_TOKEN`。空の場合、設定から読む：
CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}"
GH_TOKEN=$(cat "$CONFIG_PATH" 2>/dev/null | jq -r '.skills.entries["gh-issues"].apiKey // empty') || GH_TOKEN=$(cat /data/.clawdbot/openclaw.json 2>/dev/null | jq -r '.skills.entries["gh-issues"].apiKey // empty')

すべての GitHub API 呼び出しでトークンを使用：
curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" ...

<config>
ソースリポ (問題): {SOURCE_REPO}
プッシュリポ (ブランチ + PR): {PUSH_REPO}
フォークモード: {FORK_MODE}
プッシュリモート名: {PUSH_REMOTE}
ベースブランチ: {BASE_BRANCH}
通知チャネル: {notify_channel}
</config>

<issue>
リポジトリ: {SOURCE_REPO}
問題: #{number}
タイトル: {title}
URL: {url}
ラベル: {labels}
本文: {body}
</issue>

<instructions>
以下のステップを順に従ってください。ステップが失敗した場合、失敗を報告して停止します。

0. セットアップ — GH_TOKEN が利用可能であることを確認：

export GH_TOKEN=$(node -e "const fs=require('fs'); const c=JSON.parse(fs.readFileSync('/data/.clawdbot/openclaw.json','utf8')); console.log(c.skills?.entries?.['gh-issues']?.apiKey || '')")

失敗した場合、次も試す：

export CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}" export GH_TOKEN=$(cat "$CONFIG_PATH" 2>/dev/null | node -e "const fs=require('fs');const d=JSON.parse(fs.readFileSync(0,'utf8'));console.log(d.skills?.entries?.['gh-issues']?.apiKey||'')")

確認: echo "Token: ${GH_TOKEN:0:10}..."

1. 信頼度チェック — 実装する前に、この問題が実行可能であるかどうかを評価します：
- 問題本文を慎重に読みます。問題は明確に説明されていますか？
- コードベースを検索 (grep/find) して、関連するコードを探します。それを見つけることができますか？
- スコープは妥当ですか？ (単一ファイル/関数 = 良い、システム全体 = 悪い)
- 特定の修正が提案されていますか、それとも曖昧な不満ですか？

信頼度を評価 (1-10)。信頼度 < 7 の場合、停止して報告：
> "スキップ #{number}: 信頼度が低い (スコア: N/10) — [理由: 要件が曖昧 | コードが見つからない | スコープが大きすぎる | 明確な修正が提案されていない]"

信頼度 >= 7 の場合のみ進みます。

1. 理解 — 問題を慎重に読みます。何を変更する必要があり、どこで変更が必要かを特定します。

2. ブランチ — ベースブランチから機能ブランチを作成：
git checkout -b fix/issue-{number} {BASE_BRANCH}

3. 分析 — コードベースを検索して関連ファイルを見つける：
- exec を使用して grep/find でコードを見つける
- 関連ファイルを読んで現在の動作を理解する
- 根本的な原因を特定

4. 実装 — 最小限で焦点を当てた修正を実施：
- 既存のコードスタイルと規約に従う
- 問題を修正するのに必要な部分のみを変更
- 無関係な変更や正当化なしに新しい依存関係を追加しない

5. テスト — 既存のテストスイートを見つけて実行：
- package.json スクリプト、Makefile ターゲット、pytest、cargo test などを探す
- 関連テストを実行
- テスト修正後に失敗する場合、修正されたアプローチで 1 回のみ再試行
- テストが失敗し続ける場合、失敗を報告

6. コミット — ステージしてコミット：
git add {changed_files}
git commit -m "fix: {short_description}

Fixes {SOURCE_REPO}#{number}"

7. プッシュ — ブランチをプッシュ：
最初に、プッシュリモートがトークン認証を使用し、認証情報ヘルパーを無効化：
git config --global credential.helper ""
git remote set-url {PUSH_REMOTE} https://x-access-token:$GH_TOKEN@github.com/{PUSH_REPO}.git
その後プッシュ：
GIT_ASKPASS=true git push -u {PUSH_REMOTE} fix/issue-{number}

8. PR — GitHub API を使用してプルリクエストを作成：

FORK_MODE が true の場合、PR はフォークからソースリポに向かいます：
- head = "{PUSH_REPO_OWNER}:fix/issue-{number}"
- base = "{BASE_BRANCH}"
- PR は {SOURCE_REPO} で作成される

FORK_MODE が false の場合:
- head = "fix/issue-{number}"
- base = "{BASE_BRANCH}"
- PR は {SOURCE_REPO} で作成される

curl -s -X POST \
  -H "Authorization: Bearer $GH_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/{SOURCE_REPO}/pulls \
  -d '{
    "title": "fix: {title}",
    "head": "{head_value}",
    "base": "{BASE_BRANCH}",
    "body": "## Summary\n\n{one_paragraph_description_of_fix}\n\n## Changes\n\n{bullet_list_of_changes}\n\n## Testing\n\n{what_was_tested_and_results}\n\nFixes {SOURCE_REPO}#{number}"
  }'

レスポンスから `html_url` を抽出 — これが PR リンク。

9. 報告 — サマリーを返す：
- PR URL (ステップ 8 からの html_url)
- 変更されたファイル (リスト)
- 修正サマリー (1-2 文)
- 注意または懸念事項

10. 通知 (notify_channel が設定されている場合) — {notify_channel} が空でない場合、Telegram チャネルに通知を送信：

メッセージツールを使用：

• action: "send"
• channel: "telegram"
• target: "{notify_channel}"
• message: "✅ PR 作成: {SOURCE_REPO}#{number}

{title}

{pr_url}

変更ファイル: {files_changed_list}"

</instructions>

<constraints>
- フォースプッシュなし、ベースブランチを変更しない
- 無関係な変更または不必要なリファクタリングなし
- 強い理由がない限り新しい依存関係なし
- 問題が不明確または修正するのに複雑すぎる場合、推測する代わりに分析を報告
- gh CLI を使用しないでください — 利用不可。すべての GitHub 操作に curl + GitHub REST API を使用
- GH_TOKEN は既に環境にあります — 認証を求めないでください
- 時間制限: 最大 60 分。徹底的に分析し、修正をテストし、急がないでください。
</constraints>

サブエージェントあたりのスポーン設定：

• runTimeoutSeconds: 3600 (60 分)
• cleanup: "keep" (レビュー用のトランスクリプトを保持)
• --model が提供された場合、スポーン設定に model: "{MODEL}" を含める

タイムアウト ハンドリング

サブエージェントが 60 分を超える場合、以下として記録：

"#{N} — タイムアウト (問題は自動修正には複雑すぎる可能性があります)"

---

結果収集

--cron がアクティブな場合： このセクション全体をスキップします — オーケストレーターは既にフェーズ 5 のスポーン後に終了しています。

すべてのサブエージェントが完了 (またはタイムアウト) 後、結果を収集します。正常にオープンされた PR のリスト (PR 番号、ブランチ名、問題番号、PR URL) を OPEN_PRS に保存して、フェーズ 6 で使用します。

サマリーテーブルを表示：

問題	ステータス	PR	注釈
#42 null ポインター修正	PR オープン	https://github.com/.../pull/99	3 ファイル変更
#37 再試行ロジック追加	失敗	--	ターゲットコードを特定できず
#15 ドキュメント更新	タイムアウト	--	自動修正には複雑すぎる
#8 競合状態修正	スキップ	--	PR は既に存在します

ステータス値:

• PR オープン — 成功、PR へのリンク
• 失敗 — サブエージェントが完了できませんでした (注釈に理由を含める)
• タイムアウト — 60 分制限を超過
• スキップ — 既存 PR が出発前チェックで検出

1 行のサマリーで終わる：

"処理完了 {N} 問題: {success} PR オープン、{failed} 失敗、{skipped} スキップ。"

チャネルに通知を送信 (--notify-channel が設定されている場合): --notify-channel が提供された場合、message ツールを使用して最終サマリーを Telegram チャネルに送信：

メッセージツールを使用:
- action: "send"
- channel: "telegram"
- target: "{notify-channel}"
- message: "✅ GitHub 問題処理完了

処理完了 {N} 問題: {success} PR オープン、{failed} 失敗、{skipped} スキップ。

{PR_LIST}"

PR_LIST には正常にオープンされた PR のみが含まれます、形式：
• #{issue_number}: {PR_url} ({notes})

その後フェーズ 6 に進みます。

---

フェーズ 6 — PR レビューハンドラー

このフェーズは、レビューコメント用にオープンされた PR (このスキルで作成されたか既存の fix/issue-* PR) を監視し、それらに対処するサブエージェントを生成します。

このフェーズが実行される場合：

• 結果収集後 (フェーズ 2-5 完了) — 新しくオープンされた PR をチェック
• --reviews-only フラグが設定されている場合 — フェーズ 2-5 をスキップして、このフェーズのみ実行
• ウォッチモード — 新しい問題をチェック後、各ポーリング周期で実行

Cron レビューモード (--cron --reviews-only): --cron と --reviews-only の両方が設定されている場合：

1. トークン解決を実行 (フェーズ 2 トークンセクション)
2. オープンな fix/issue-* PR を発見 (ステップ 6.1)
3. レビューコメントをフェッチ (ステップ 6.2)
4. コメントコンテンツの実行可能性を分析 (ステップ 6.3)
5. 実行可能なコメントが見つかった場合、未対処のコメントを持つ最初の PR 用に 1 つのレビュー修正サブエージェントを生成 — ファイア・アンド・フォーゲット (await しないでください)
   • cleanup: "keep" と runTimeoutSeconds: 3600 を使用
   • --model が提供された場合、スポーン設定に model: "{MODEL}" を含める
6. 報告: "スポーン PR #{N} 用レビューハンドラー — 完了時に修正をプッシュします"
7. スキルを直ちに終了します。ステップ 6.5 (レビュー結果) に進まないでください。

実行可能なコメントが見つからない場合、"実行可能なレビューコメントは見つかりません" を報告して終了。

通常モード (非 cron) は以下を続行：

ステップ 6.1 — 監視対象の PR を発見

レビューコメントをチェックする PR を収集：

フェーズ 5 から来た場合： 結果収集からの OPEN_PRS リストを使用します。

--reviews-only または後続のウォッチ周期の場合: fix/issue- ブランチパターンを持つすべてのオープン PR をフェッチ：

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/{SOURCE_REPO}/pulls?state=open&per_page=100"

head.ref が fix/issue- で始まる PR のみにフィルター。

各 PR について、以下を抽出: number (PR 番号), head.ref (ブランチ名), html_url, title, body。

PR が見つからない場合、"監視対象のオープン fix/ PR はありません" を報告して停止します (またはウォッチモード内の場合ループバック)。

ステップ 6.2 — すべてのレビューソースをフェッチ

各 PR について、複数のソースからレビューをフェッチ：

PR レビューをフェッチ：

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/{SOURCE_REPO}/pulls/{pr_number}/reviews"

PR レビューコメント (インラインまたはファイルレベル) をフェッチ：

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/{SOURCE_REPO}/pulls/{pr_number}/comments"

PR 問題コメント (一般的な会話) をフェッチ：

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/{SOURCE_REPO}/issues/{pr_number}/comments"

埋め込まれたレビュー用に PR 本文をフェッチ： 一部のレビューツール (Greptile など) は、PR 本文に直接フィードバックを埋め込みます。以下をチェック：

• <!-- greptile_comment --> マーカー
• PR 本文の他の構造化レビューセクション

curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/{SOURCE_REPO}/pulls/{pr_number}"

body フィールドを抽出して埋め込まれたレビューコンテンツを解析。

ステップ 6.3 — 実行可能性のためにコメントを分析

ボットの独自ユーザー名を決定 (フィルタリング用)：

curl -s -H "Authorization: Bearer $GH_TOKEN" https://api.github.com/user | jq -r '.login'

BOT_USERNAME として保存します。user.login が BOT_USERNAME に等しいコメントはすべて除外します。

各コメント/レビューについて、対処が必要かどうかを判断するのにコンテンツを分析：

実行不可能 (スキップ):

• 提案なしの純粋な承認または "LGTM"
• 情報のみのボットコメント (CI ステータス、特定のリクエストなしに自動生成されたサマリー)
• 既に対処されたコメント (ボットが "Addressed in commit..." で返信したかをチェック)
• インラインコメントなしで状態が APPROVED のレビュー

実行可能 (注意が必要):

• 状態が CHANGES_REQUESTED のレビュー
• 状態が COMMENTED で特定のリクエストを含むレビュー：
  • "このテストを更新する必要があります"
  • "修正してください"、"これを変更"、"更新"、"できますか"、"すべき"、"する必要があります"
  • "失敗します"、"壊れます"、"エラーが発生します"
  • 特定のコードの問題の言及 (バグ、エラーハンドリングの欠如、エッジケース)
• コード内の問題を指摘するインラインレビューコメント
• コード内の問題を特定する PR 本文の埋め込みレビュー：
  • 重大な問題または破壊的変更
  • 予期されるテスト失敗
  • 注意が必要な特定のコード
  • 懸念を示す信頼スコア

埋め込まれたレビューコンテンツを解析 (例: Greptile): <!-- greptile_comment --> またはそれに類するでマークされたセクションを探す。以下を抽出：

• サマリーテキスト
• "重大な問題"、"注意が必要"、"失敗します"、"テストを更新する必要があります" への言及
• 懸念を示す 4/5 未満の信頼スコア

actionable_comments リストを構築 (以下を含む)：

• ソース (レビュー、インラインコメント、PR 本文など)
• 著者
• 本文テキスト
• インラインの場合: ファイルパスと行番号
• 識別された特定のアクションアイテム

実行可能なコメントが PR 間で見つからない場合、"実行可能なレビューコメントは見つかりません" を報告して停止します (またはウォッチモード内の場合ループバック)。

ステップ 6.4 — レビューコメントを提示

保留中の実行可能なコメントを持つ PR のテーブルを表示：

| PR | ブランチ | 実行可能なコメント | ソース |
|----|--------|---------------------|---------|
| #99 | fix/issue-42 | 2 コメント | @reviewer1, greptile |
| #101 | fix/issue-37 | 1 コメント | @reviewer2 |

--yes が設定されておらず、これが後続のウォッチポーリングではない場合: ユーザーに対処する PR を確認するよう促します ("all", カンマ区切り PR 番号、または "skip")。

ステップ 6.5 — レビュー修正サブエージェントを生成 (並列)

実行可能なコメントを持つ各 PR について、サブエージェントを生成します。最大 8 を同時起動します。

レビュー修正サブエージェント プロンプト:

あなたは PR レビューハンドラーエージェントです。あなたのタスクは、プルリクエストのレビューコメントに対処するために、要求されたコミット、プッシュ更新、各コメントへの返信を行うことです。

重要: gh CLI を使用しないでください — インストールされていません。すべての GitHub 操作に curl と GitHub REST API を使用してください。

最初に、GH_TOKEN が設定されていることを確認します。チェック: echo $GH_TOKEN。空の場合、設定から読む：
CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}"
GH_TOKEN=$(cat "$CONFIG_PATH" 2>/dev/null | jq -r '.skills.entries["gh-issues"].apiKey // empty') || GH_TOKEN=$(cat /data/.clawdbot/openclaw.json 2>/dev/null | jq -r '.skills.entries["gh-issues"].apiKey // empty')

<config>
リポジトリ: {SOURCE_REPO}
プッシュリポ: {PUSH_REPO}
フォークモード: {FORK_MODE}
プッシュリモート: {PUSH_REMOTE}
PR 番号: {pr_number}
PR URL: {pr_url}
ブランチ: {branch_name}
</config>

<review_comments>
{json_array_of_actionable_comments}

各コメントは以下を持つ：
- id: コメント ID (返信用)
- user: コメントを残した人
- body: コメントテキスト
- path: ファイルパス (インラインコメント用)
- line: 行番号 (インラインコメント用)
- diff_hunk: 周囲の差分コンテキスト (インラインコメント用)
- source: コメントが来た場所 (レビュー、インラインコメント、pr_body, greptile など)
</review_comments>

<instructions>
以下のステップを順に従ってください：

0. セットアップ — GH_TOKEN が利用可能であることを確認：

export GH_TOKEN=$(node -e "const fs=require('fs'); const c=JSON.parse(fs.readFileSync('/data/.clawdbot/openclaw.json','utf8')); console.log(c.skills?.entries?.['gh-issues']?.apiKey || '')")

確認: echo "Token: ${GH_TOKEN:0:10}..."

1. チェックアウト — PR ブランチに切り替え：
git fetch {PUSH_REMOTE} {branch_name}
git checkout {branch_name}
git pull {PUSH_REMOTE} {branch_name}

2. 理解 — すべてのレビューコメントを慎重に読みます。ファイルごとにグループ化します。各レビュアーが何を求めているかを理解します。

3. 実装 — 各コメントについて、要求された変更を加える：
- ファイルを読んで関連するコードを見つけます
- レビュアーが要求した変更を加えます
- コメントが曖昧であるか同意しない場合、それでも合理的な修正を試みますが、懸念を記録します
- コメントが不可能または矛盾したことを求めている場合、スキップして返信で説明します

4. テスト — 既存のテストを実行して、変更が何も壊さないことを確認：
- テストが失敗する場合、問題を修正するか、問題のある変更をリバート
- 返信にテスト失敗を記録します

5. コミット — 単一のコミットですべての変更をステージしてコミット：
git add {changed_files}
git commit -m "fix: address review comments on PR #{pr_number}

Addresses review feedback from {reviewer_names}"

6. プッシュ — 更新されたブランチをプッシュ：
git config --global credential.helper ""
git remote set-url {PUSH_REMOTE} https://x-access-token:$GH_TOKEN@github.com/{PUSH_REPO}.git
GIT_ASKPASS=true git push {PUSH_REMOTE} {branch_name}

7. 返信 — 対処された各コメントについて、返信を投稿：

インラインレビューコメント (パス/行を持つ) の場合、コメントスレッドに返信：
curl -s -X POST \
  -H "Authorization: Bearer $GH_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/{SOURCE_REPO}/pulls/{pr_number}/comments/{comment_id}/replies \
  -d '{"body": "コミット {short_sha} で対処 — {brief_description_of_change}"}'

一般的な PR コメント (問題コメント) の場合、PR で返信：
curl -s -X POST \
  -H "Authorization: Bearer $GH_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/{SOURCE_REPO}/issues/{pr_number}/comments \
  -d '{"body": "@{reviewer} からのフィードバックに対処しました：\n\n{summary_of_changes_made}\n\nコミット {short_sha} で更新"}'

対処できなかったコメントについて、理由を説明するために返信：
"このコメントに対処できません: {reason}。これは手動レビューが必要な場合があります。"

8. 報告 — サマリーを返す：
- PR URL
- 対処されたコメント数 vs スキップされたコメント数
- コミット SHA
- 変更されたファイル
- 手動レビューが必要なコメント
</instructions>

<constraints>
- レビューコメントに関連するファイルのみを変更
- 無関連の変更を行わない
- フォースプッシュしない — 常に通常のプッシュ
- コメントが別のコメントと矛盾する場合、最も最近のものに対処してコンフリクトをフラグ
- gh CLI を使用しないでください — curl + GitHub REST API を使用
- GH_TOKEN は既に環境にあります — 認証を求めないでください
- 時間制限: 最大 60 分
</constraints>

サブエージェントあたりのスポーン設定:

• runTimeoutSeconds: 3600 (60 分)
• cleanup: "keep" (レビュー用のトランスクリプトを保持)
• --model が提供された場合、スポーン設定に model: "{MODEL}" を含める

ステップ 6.6 — レビュー結果

すべてのレビューサブエージェントが完了した後、サマリーを提示：

| PR | 対処されたコメント | スキップされたコメント | コミット | ステータス |
|----|-------------------|-----------------|--------|--------|
| #99 fix/issue-42 | 3 | 0 | abc123f | すべて対処 |
| #101 fix/issue-37 | 1 | 1 | def456a | 1 つが手動レビューが必要 |

このバッチからのコメント ID を ADDRESSED_COMMENTS セットに追加して、再処理を防ぎます。

---

ウォッチモード (--watch がアクティブな場合)

現在のバッチからの結果を提示した後：

1. このバッチからのすべての問題番号を実行中の PROCESSED_ISSUES セットに追加します。
2. すべての対処されたコメント ID を ADDRESSED_COMMENTS に追加します。
3. ユーザーに告げます：

   "次のポーリングは {interval} 分後です... (ウォッチモードを終了するには 'stop' と言ってください)"

4. {interval} 分間スリープします。
5. フェーズ 2 — 問題をフェッチ に戻ります。フェッチは自動的に以下をフィルター：
   • 既に PROCESSED_ISSUES にある問題
   • 既に fix/issue-{N} PR を持つ問題 (フェーズ 4 出発前で捕捉)
6. フェーズ 2-5 (または新しい問題がない場合) の後、フェーズ 6 を実行してすべての追跡 PR (新しく作成されたものと以前にオープンされたもの両方) の新しいレビューコメントをチェック。
7. 新しい問題がない AND 新しい実行可能なレビューコメントがない場合 → "{interval} 分後に再度ポーリング..." を報告してステップ 4 にループバック。
8. ユーザーはいつでも "stop" と言ってウォッチモードを終了できます。停止時に、すべてのバッチの最終的な累積サマリーを提示 — 処理された問題 AND 対処されたレビューコメント。

ポーリング間のコンテキスト衛生 — 重要： ポーリング周期間で以下のみを保持：

• PROCESSED_ISSUES (問題番号のセット)
• ADDRESSED_COMMENTS (コメント ID のセット)
• OPEN_PRS (追跡 PR のリスト: 番号、ブランチ、URL)
• 累積結果 (1 行あたりの問題 + 1 行あたりのレビューバッチ)
• フェーズ 1 からの解析された引数
• BASE_BRANCH, SOURCE_REPO, PUSH_REPO, FORK_MODE, BOT_USERNAME ポーリング間で問題本文、コメント本文、サブエージェント トランスクリプト、またはコードベース分析を保持しないでください。