ops-merge

実行時コンテキスト

実行する前に、以下を読み込みます。

1. 設定：cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — owner、timezone、プロジェクトレジストリを読み取ります
2. デーモンのヘルス状態：cat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json — action_needed が設定されている場合は、ユーザーに知らせます
3. シークレット：GitHub トークン：環境変数 $GITHUB_TOKEN → Doppler MCP (mcp__doppler__*) → doppler secrets get GITHUB_TOKEN --plain → パスワードマネージャー

OPS ► マージ

CLI/API リファレンス

gh CLI（GitHub）

コマンド	用途	出力
gh pr list --repo <owner/repo> --json number,title,state,headRefName,statusCheckRollup,reviewDecision,mergeable,isDraft	ステータス付きで PR を一覧表示	JSON 配列
gh pr view <n> --repo <repo> --json title,body,state,mergeable,reviews	PR の詳細	JSON
gh pr checks <n> --repo <repo>	CI チェックのステータス	チェック一覧
gh pr merge <n> --repo <repo> --squash --admin	PR をスカッシュマージ	マージ結果
gh pr create --repo <repo> --title "<t>" --body "<b>" --base dev	PR を作成	PR の URL
gh run list --repo <repo> --limit 5 --json conclusion,name,headBranch	CI の実行一覧	JSON 配列
gh run view <id> --repo <repo> --log-failed	失敗した CI のログ	ログ出力
gh run watch <run-id> --repo <repo>	CI の実行をストリーミング	リアルタイム出力（Monitor と併用）
gh api repos/<repo>/pulls/<n>/comments --jq '.[].body'	PR のレビューコメント	コメント本文

---

Agent Teams のサポート

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が設定されている場合、修正エージェントには Agent Teams を使用します（フェーズ 3）。これにより、以下が可能になります。

• 優先順位が変わった場合に、作業中の修正エージェントに指示を出せます（例：重要な PR を先にマージする必要がある場合）
• 修正エージェントはブロッカーを報告でき、完了を待たずに指示を変更できます
• コンテキストを共有できます。たとえば、修正エージェント A が修正エージェント B の PR に影響する破壊的変更を見つけた場合、B に知らせることができます

チームのセットアップ（フラグが有効な場合のみ、フェーズ 3）：

TeamCreate("merge-fixers")
Agent(team_name="merge-fixers", name="fixer-[repo]", ...)

SendMessage(to="fixer-my-api", content="PR #2958 was just merged — rebase your branch") を使って調整します。

フラグが設定されていない場合は、isolation: "worktree" を指定した標準の並列サブエージェントに切り替えます。

事前に収集した PR データ

${CLAUDE_PLUGIN_ROOT}/bin/ops-merge-scan 2>/dev/null || echo '{"prs":[],"error":"merge-scan failed"}'

タスク

あなたはマージオーケストレーターです。担当するのは、オーナーのリポジトリ全体でオープン状態のすべての PR をマージすることです。その前に、マージを妨げている問題を解決します。

引数の解析

$ARGUMENTS から以下を解析します。

• --main → すべての PR を dev にマージした後、両方のブランチがあるリポジトリでは dev と main も同期します
• --repo <slug> → 1 つのリポジトリのみを対象にします（例：--repo Lifecycle-Innovations-Limited/my-api）
• --dry-run → 実行予定の内容を報告し、エージェントへの処理の振り分けやマージは行いません
• --force → マージ前の確認プロンプトを省略します
• （空）→ すべてのリポジトリを処理し、dev のみにマージします

フェーズ 1 — PR キューを分類する

事前に収集された JSON を解析します。各 PR は、すでに次のいずれかに分類されています。

分類	意味	アクション
ready	CI が成功し、承認済みで、競合なし	すぐにマージ
needs-rebase	mergeable: CONFLICTING	修正担当者を割り当てる：ベースブランチにリベース
needs-ci-fix	statusCheckRollup に CI の失敗がある	修正担当者を割り当てる：ログを調査し、修正してプッシュ
needs-review-response	reviewDecision: CHANGES_REQUESTED	修正担当者を割り当てる：コメントに対応
blocked	mergeStateStatus: BLOCKED（ブランチ保護、必須レビュー）	理由を記録してスキップ
draft	isDraft: true	スキップ — マージの準備ができていません

キューを表示します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► MERGE — PR Queue
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| Repo | PR | Title | Status | Action |
|------|----|-------|--------|--------|
| my-api | #2958 | fix(migration) | ready | merge |
| my-app | #4456 | feat(apple-04) | needs-ci-fix | dispatch fixer |
| ... | ... | ... | ... | ... |

Ready: N  |  Fix needed: N  |  Blocked: N  |  Draft: N
──────────────────────────────────────────────────────

--dry-run が指定されている場合は、ここで終了します。キューを表示して終了します。

フェーズ 2 — マージ可能な PR を確認してマージする

--force が指定されていない場合は、マージする前に AskUserQuestion で確認します。

Ready to merge N PRs:
  [repo]#[number] — [title] → [base]
  [repo]#[number] — [title] → [base]

  [Merge all N now]  [Let me pick which ones]  [Dry run — don't merge]

ユーザーが「自分で選ぶ」を選んだ場合は、各 PR に [Merge]／[Skip] の選択肢を付けて AskUserQuestion で表示します。

確認済みの各 PR に対して、次を実行します。

1. CI が引き続き成功していることを確認します：gh pr checks <number> --repo <repo>
2. 成功している場合：gh pr merge <number> --repo <repo> --squash --admin
3. 結果を報告します：✓ Merged <repo>#<number> to <base>

フェーズ 3 — 対応が必要な PR の修正担当者を割り当てる

needs-rebase、needs-ci-fix、または needs-review-response に分類された PR に対して、次を実行します。

サブエージェントを並列に割り当てます（同時実行は最大 5 件、1 エージェントにつき 1 リポジトリ）。

各修正担当エージェントにはワークツリーと次の指示を渡します。

Task: Fix PR #<number> in <repo> (<classification>)
Repo path: <path from registry>
Branch: <headRefName>

<classification-specific instructions>

For needs-rebase:
  1. Create worktree: `git worktree add /tmp/ops-rebase-<pr-number> <headRefName>`
  2. cd into worktree: `cd /tmp/ops-rebase-<pr-number>`
  3. Fetch latest: `git fetch origin`
  4. Attempt rebase: `git rebase origin/<baseBranchRef> 2>&1`
  5. If rebase SUCCEEDS (exit 0):
     - Push force-with-lease: `git push --force-with-lease origin <headRefName>`
     - Clean up worktree: `git worktree remove /tmp/ops-rebase-<pr-number> --force`
     - Report: `✓ Rebased <repo>#<number> — conflict resolved`
  6. If rebase FAILS (exit non-zero):
     - Capture the conflicting files: `git diff --name-only --diff-filter=U`
     - Show the diff: `git diff HEAD`
     - Abort the rebase: `git rebase --abort`
     - Clean up worktree: `git worktree remove /tmp/ops-rebase-<pr-number> --force`
     - Surface to orchestrator with the diff output and a structured conflict report:
       ```json
       {
         "pr": <number>,
         "repo": "<repo>",
         "status": "conflict",
         "conflicting_files": ["<file1>", "<file2>"],
         "diff_summary": "<first 500 chars of diff>"
       }
       ```

For needs-ci-fix:
  1. Get failed check logs: `gh run view <id> --repo <repo> --log-failed | tail -80`
  2. Diagnose the failure
  3. Fix the code in a worktree
  4. Commit + push --no-verify
  5. Wait for CI to re-run (or report what was fixed)

For needs-review-response:
  1. Read review comments: `gh api repos/<repo>/pulls/<number>/comments --jq '.[].body'`
  2. Address each comment in code
  3. Reply to each comment via gh api
  4. Push fixes
  5. Re-request review if needed

After fixing:
  - Report back: what was wrong, what was fixed, is CI green now?
  - Do NOT auto-merge after fixing. Report the fix and let Phase 4 handle confirmation.

すべての修正担当エージェントで model: "sonnet" を使用します。

フェーズ 4 — 表面化した競合を解決する

修正担当エージェントから status: "conflict" として返された各 PR に対して、次を実行します。

1. 競合の概要を表示します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► MERGE — Conflict in <repo>#<number>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Branch: <headRefName> → <baseBranchRef>
 Conflicting files:
   - <file1>
   - <file2>

<diff_summary>
──────────────────────────────────────────────────────

2. AskUserQuestion を使用します（選択肢は最大 4 つ — CLAUDE.md ルール 1）。

[Accept incoming (theirs)]  [Keep current branch (ours)]  [Open manual resolution]  [Skip this PR]

3. 回答に基づいて、次を実行します。
   • 相手側を採用する（theirs）：ワークツリーを作成し、競合する各ファイルで git checkout --theirs . を実行してリベースし、git add .、git rebase --continue の順に実行して、--force-with-lease でプッシュします。
   • 現在のブランチを保持する（ours）：ワークツリーを作成し、競合する各ファイルで git checkout --ours . を実行してリベースし、git add .、git rebase --continue の順に実行して、--force-with-lease でプッシュします。
   • 手動での解決を開始する：オペレーターが手動で解決するための手順を順を追って表示し、マージ処理を続行する前に git push の確認を求めます。
   • この PR をスキップする：unresolved-conflict として記録し、最終レポートに含めます。

フェーズ 5 — 結果を収集してマージを確認する

修正担当エージェントの作業完了に合わせて、次を実行します。

1. PR が成功状態になったことを確認します：gh pr checks <number> --repo <repo>
2. 成功している場合は、AskUserQuestion で確認します（--force が指定されている場合を除く）。

   Fixer resolved [repo]#[number] — [what was fixed]. CI is now green.
     [Merge now]  [Skip — I'll review manually]
   

3. まだ失敗している場合は、未解決の問題を報告し、マージしません。

フェーズ 6 — --main の同期（フラグが指定されている場合のみ）

dev と main のブランチが分かれている各リポジトリに対して、次を実行します。

1. dev が main より先行しているかを確認します：git -C <path> log main..dev --oneline | head -5
2. 先行している場合は、コミットを表示して AskUserQuestion を使用します。

   [repo]: dev is N commits ahead of main:
     [commit list]
   
     [Create sync PR and merge]  [Create PR only — I'll review]  [Skip this repo]
   

3. 確認された場合は、同期 PR を作成します：gh pr create --repo <repo> --base main --head dev --title "chore: sync dev → main"
4. CI を待ちます：gh pr checks <sync-pr-number> --repo <repo> --watch（バックグラウンドで最大 10 分）
5. CI が成功した場合：gh pr merge <sync-pr-number> --repo <repo> --merge --admin（スカッシュではなくマージコミット）
6. main を dev に取り込みます：git -C <path> fetch origin && git -C <path> checkout dev && git -C <path> merge origin/main --no-edit

フェーズ 7 — 最終レポート

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► MERGE COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| Repo | PR | Result |
|------|----|--------|
| my-api | #2958 | ✓ merged to dev |
| my-app | #4456 | ✓ fixed CI + merged |
| mise | #10 | ✗ 3 critical bugs — skipped |

Merged: N PRs across M repos
Skipped: N (blocked/draft)
Failed: N (still need manual attention)

Main sync: N repos synced (dev → main → dev)
──────────────────────────────────────────────────────

---

安全上のガードレール（絶対に違反しないでください）

• main/master への強制プッシュは絶対に行わないでください
• CI が失敗している状態でのマージは絶対に行わないでください — まず根本原因を修正してください
• 認証、支払い、PII、またはシークレットに関わる PR のレビューを絶対に省略しないでください — マージ前に security-reviewer サブエージェントによる監査が必要です
• 共有ブランチで git reset --hard を絶対に実行しないでください
• 修正には必ず worktree を使用してください（複数のエージェントが同時に作業する場合があります）
• --admin は dev へのスカッシュマージにのみ使用してください（--main フラグがない限り、main には使用しないでください）
• GitHub API のスロットリングを避けるため、1 回の実行につき PR は最大 10 件までです
• PR の変更ファイル数が 50 件を超える場合は、自動マージせず、手動レビューが必要なものとしてフラグを付けてください

---

ネイティブツールの使用

Monitor — CI のリアルタイム監視

修正担当者がプッシュした後（フェーズ 3～4）に CI の完了を待つ場合は、ポーリングの代わりに Monitor を使用して GitHub Actions の実行出力をストリーミングしてください。

Monitor(command: "gh run watch <run-id> --repo <repo>")

これにより、スリープループを避け、CI の進行状況をリアルタイムで確認できます。

Tasks — 進捗管理

マージのパイプライン全体と、PR ごとの個別タスクに対して TaskCreate を作成してください。各 PR の修正、マージ、スキップに応じて TaskUpdate で更新します。これにより、ユーザーはチェックリストをリアルタイムで確認できます。

WebSearch — CI 失敗の背景情報

修正担当エージェントが原因の分かりにくい CI 失敗に遭遇した場合は、WebSearch を使用して既知の問題（npm レジストリの停止、GitHub Actions のインシデント、不安定なテストのパターンなど）を検索してください。