gh-issues は何をしますか？
IssueからPRへの自動化に使用します。gh CLIを優先し、高レベルコマンドに必要なフィールドがない場合のみgh apiにフォールバックします。
引数
- 位置引数
owner/repo: 省略時はgit remote get-url originから推測。 --label <ラベル>: フィルタ。--limit <数>: デフォルト10。--milestone <タイトル>: フィルタ。--assignee <ログイン|@me>: フィルタ。--state open|closed|all: デフォルトopen。--fork <owner/repo>: フォークにブランチをプッシュし、ソースにPR。--watch: Issueとレビューをポーリング。--interval <分>: デフォルト5。--dry-run: 一覧表示のみ。--yes: 確認なし。--reviews-only: Issue修正をスキップし、PRレビューを処理。--cron: 起動して終了（--yesを暗黙指定）。--model <ID>: サポートされている場合、ワーカーに渡すモデル。--notify-channel <ID>: オプションの最終通知チャネル。
フェーズ1: リポジトリの解決
git remote get-url origin
if [ -z "${GH_TOKEN:-}" ]; then
CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}"
GH_TOKEN=$(jq -r '.skills.entries["gh-issues"].apiKey // empty' "$CONFIG_PATH" 2>/dev/null || true)
if [ -n "$GH_TOKEN" ]; then export GH_TOKEN; fi
fi
gh auth status
gh repo view OWNER/REPO --json nameWithOwner,defaultBranchRef
gh auth status が失敗し、GH_TOKEN がない場合は、停止してGitHub認証/設定を要求します。
導出:
SOURCE_REPO: Issueリポジトリ。PUSH_REPO: フォークが設定されている場合はフォーク、それ以外はソース。BASE_BRANCH: ユーザーが別途指定しない限り、ソースのデフォルトブランチ。PUSH_REMOTE: フォークモードではfork、それ以外はorigin。
ワーカーがコミットされていない変更を無視してよいとユーザーが確認しない限り、ダーティワークツリーでは停止。
フォークモードでは、確認前または --dry-run 中にリモートを変更しない。
認証/読み取りアクセスのみ確認:
gh auth token >/dev/null || test -n "${GH_TOKEN:-}"
gh repo view "$PUSH_REPO" --json nameWithOwner
git ls-remote --exit-code origin HEAD
フェーズ2: Issueの取得
フィルタを構築して取得:
gh issue list --repo "$SOURCE_REPO" --state open --limit 10 --json number,title,labels,url,body,assignees,milestone
--label、--milestone、--assignee、--state、--limit を必要に応じて追加。gh issue list はPRを除外します。
該当なし: 一致なしと報告。--dry-run の場合: 簡潔な一覧を表示して停止。
フェーズ3: 重複作業の回避
各候補に対して:
gh pr list --repo "$SOURCE_REPO" --search "$SOURCE_REPO#<n>" --state open --json number,url,title,headRefName
gh pr list --repo "$SOURCE_REPO" --head "fix/issue-<n>" --state open --json number,url
gh api "repos/$PUSH_REPO/branches/fix/issue-<n>" >/dev/null
オープンPR、既存ブランチ、またはアクティブなローカルクレームがある候補はスキップ。
クレームファイル:
${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/gh-issues-<owner>-<repo>.json
2時間以上経過したクレームは期限切れ。書き込み前に親ディレクトリを作成。
フェーズ4: 確認
--yes または --cron がない限り、ユーザーに選択を求める:
all- カンマ区切りのIssue番号
cancel
確認後、フォークモードでは、ワーカーに処理を委譲する前にプッシュリモートを設定:
gh auth setup-git
git remote get-url fork || git remote add fork "https://github.com/$PUSH_REPO.git"
git remote set-url fork "https://github.com/$PUSH_REPO.git"
git ls-remote --exit-code fork HEAD
フェーズ5: ワーカーの起動
最大8つのバックグラウンドワーカーを起動。--cron の場合、ワーカーごとにブロックしない。
各起動前に、SOURCE_REPO#<n> のクレームを現在のISOタイムスタンプで書き込む。ワーカーがPR/失敗を報告したら、クレームを削除または更新。これにより、ブランチやPRが存在する前のウォッチ/cronの重複を防止。
ワーカープロンプトには以下を含める:
- Issue URL、タイトル、本文、ラベル。
SOURCE_REPO、PUSH_REPO、BASE_BRANCH、PUSH_REMOTE、フォークモード。- ターゲットブランチ
fix/issue-<n>。 - 必要な証明とPR本文。
- 通知ルート。
ワーカー指示:
gh と git を使用してください。ごまかしはしないでください。
BASE_BRANCH から fix/issue-<n> をチェックアウト/作成。
最小限の修正を実装。
関連テストを実行。
従来のメッセージでコミット。
PUSH_REMOTE にプッシュ。
SOURCE_REPO BASE_BRANCH に対してPRを開く。
PR本文: この変更が解決する問題 + この変更を行った理由 + ユーザーへの影響 + 証拠 + Fixes SOURCE_REPO#<n> を可視表示。
PR URLまたは失敗理由を報告。
ルートが指定されている場合、openclaw message send で完了/失敗を送信。
利用可能な場合は coding-agent 起動ルールを使用。
フェーズ6: 収集
process またはタスクレジストリでワーカーをポーリング。報告:
- Issue番号 + タイトル。
- ステータス: PR opened、skipped、failed、timed out。
- PR URLまたは理由。
最終的な簡潔なサマリーでのみ通知チャネルに送信。
レビューのみ / レビューウォッチ
オープンPRを検出:
gh pr list --repo "$SOURCE_REPO" --state open --json number,title,url,headRefName,reviewDecision \
--jq '[.[] | select(.headRefName | startswith("fix/issue-"))]'
レビュースレッド/コメントを取得:
gh pr view <n> --repo "$SOURCE_REPO" --json url,headRefName,comments,reviews
gh api "repos/$SOURCE_REPO/pulls/<n>/comments"
gh api "repos/$SOURCE_REPO/issues/<n>/comments"
ユーザーが明示的にPR番号を指定した場合を除き、このワークフローで作成された fix/issue-* PRのみ処理。アクション可能なコメントをPRごとにグループ化。賞賛、ステータス、重複、既に対応済みのコメントは無視。スコープされたPRごとに1つのワーカーを起動（同じバックグラウンドルール）。
レビューワーカー指示:
PRブランチをチェックアウト。
すべてのアクション可能なレビューコメントを読む。
最小限の変更をパッチ。
関連テストを実行。
通常通りコミットしてプッシュ（明示的に指示されない限り force-push しない）。
対応したコメントに修正内容とコミット/ファイル参照を添えて返信。
対応・スキップしたコメントと証明を報告。
ウォッチモード
ループ:
- Issueを取得。
- 対象のIssueワーカーを起動。
- アクション可能なPRレビューを処理。
--intervalスリープ。- ユーザーが停止するまで継続。
累積サマリーは小さく保つ。