plugins/claude-ops/skills/ops-merge/SKILL.md
Autonomous PR merge pipeline. Scans all repos for open PRs, dispatches subagents to fix CI, resolve conflicts, address review comments, then merges. Use --main to also sync dev↔main branches.
npx skillsauth add davepoon/buildwithclaude ops-mergeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Before executing, load:
cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — read owner, timezone, project registrycat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json — if action_needed set, surface to user$GITHUB_TOKEN → Doppler MCP (mcp__doppler__*) → doppler secrets get GITHUB_TOKEN --plain → password manager| Command | Usage | Output |
|---------|-------|--------|
| gh pr list --repo <owner/repo> --json number,title,state,headRefName,statusCheckRollup,reviewDecision,mergeable,isDraft | List PRs with status | JSON array |
| gh pr view <n> --repo <repo> --json title,body,state,mergeable,reviews | PR details | JSON |
| gh pr checks <n> --repo <repo> | CI check status | Check list |
| gh pr merge <n> --repo <repo> --squash --admin | Squash merge PR | Merge result |
| gh pr create --repo <repo> --title "<t>" --body "<b>" --base dev | Create PR | PR URL |
| gh run list --repo <repo> --limit 5 --json conclusion,name,headBranch | CI runs | JSON array |
| gh run view <id> --repo <repo> --log-failed | Failed CI logs | Log output |
| gh run watch <run-id> --repo <repo> | Stream CI run | Live output (use with Monitor) |
| gh api repos/<repo>/pulls/<n>/comments --jq '.[].body' | PR review comments | Comment text |
If CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set, use Agent Teams for fixer agents (Phase 3). This enables:
Team setup (only when flag is enabled, Phase 3):
TeamCreate("merge-fixers")
Agent(team_name="merge-fixers", name="fixer-[repo]", ...)
Use SendMessage(to="fixer-my-api", content="PR #2958 was just merged — rebase your branch") to coordinate.
If the flag is NOT set, fall back to standard parallel subagents with isolation: "worktree".
${CLAUDE_PLUGIN_ROOT}/bin/ops-merge-scan 2>/dev/null || echo '{"prs":[],"error":"merge-scan failed"}'
You are the merge orchestrator. Your job is to get every open PR across the owner's repos merged — fixing whatever blocks them first.
From $ARGUMENTS:
--main → after all PRs merge to dev, also sync dev↔main for repos that have both branches--repo <slug> → scope to one repo only (e.g., --repo Lifecycle-Innovations-Limited/my-api)--dry-run → report what would happen, don't dispatch agents or merge anything--force → skip the confirmation prompt before mergingParse the pre-gathered JSON. For each PR, it's already classified as one of:
| Classification | Meaning | Action |
| ----------------------- | ----------------------------------------------------------------- | ------------------------------------------- |
| ready | CI green, approved, no conflicts | Merge immediately |
| needs-rebase | mergeable: CONFLICTING | Dispatch fixer: rebase on base branch |
| needs-ci-fix | CI failures in statusCheckRollup | Dispatch fixer: investigate logs, fix, push |
| needs-review-response | reviewDecision: CHANGES_REQUESTED | Dispatch fixer: resolve comments |
| blocked | mergeStateStatus: BLOCKED (branch protection, required reviews) | Note why, skip |
| draft | isDraft: true | Skip — not ready for merge |
Print the queue:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
──────────────────────────────────────────────────────
If --dry-run, stop here. Print the queue and exit.
Unless --force was passed, use AskUserQuestion to confirm before merging:
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]
If user picks "Let me pick", show each PR with [Merge] / [Skip] options via AskUserQuestion.
For each confirmed PR:
gh pr checks <number> --repo <repo>gh pr merge <number> --repo <repo> --squash --admin✓ Merged <repo>#<number> to <base>For PRs classified as needs-rebase, needs-ci-fix, or needs-review-response:
Dispatch subagents in parallel (max 5 concurrent, one repo per agent):
Each fixer agent gets a worktree and this brief:
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.
Use model: "sonnet" for all fixer agents.
For each PR returned with status: "conflict" from a fixer agent:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OPS ► MERGE — Conflict in <repo>#<number>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Branch: <headRefName> → <baseBranchRef>
Conflicting files:
- <file1>
- <file2>
<diff_summary>
──────────────────────────────────────────────────────
[Accept incoming (theirs)] [Keep current branch (ours)] [Open manual resolution] [Skip this PR]
git checkout --theirs . on each conflicting file, git add ., git rebase --continue, push force-with-leasegit checkout --ours . on each conflicting file, git add ., git rebase --continue, push force-with-leasegit push confirmation before continuing the merge pipelineunresolved-conflict, include in final reportAs fixers complete:
gh pr checks <number> --repo <repo>AskUserQuestion to confirm (unless --force):
Fixer resolved [repo]#[number] — [what was fixed]. CI is now green.
[Merge now] [Skip — I'll review manually]
--main sync (only if flag is set)For each repo that has separate dev and main branches:
git -C <path> log main..dev --oneline | head -5AskUserQuestion:
[repo]: dev is N commits ahead of main:
[commit list]
[Create sync PR and merge] [Create PR only — I'll review] [Skip this repo]
gh pr create --repo <repo> --base main --head dev --title "chore: sync dev → main"gh pr checks <sync-pr-number> --repo <repo> --watch (background, max 10 min)gh pr merge <sync-pr-number> --repo <repo> --merge --admin (merge commit, not squash)git -C <path> fetch origin && git -C <path> checkout dev && git -C <path> merge origin/main --no-edit━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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)
──────────────────────────────────────────────────────
security-reviewer subagent audit before mergegit reset --hard on shared branches--admin only for squash merges to dev (not main, unless --main flag)When waiting for CI after a fixer pushes (Phase 3-4), use Monitor to stream the GitHub Actions run output instead of polling:
Monitor(command: "gh run watch <run-id> --repo <repo>")
This avoids sleep loops and gives real-time feedback on CI progress.
Create a TaskCreate for the overall merge pipeline and individual tasks per PR. Update with TaskUpdate as each PR is fixed/merged/skipped. This gives the user a live checklist view.
When a fixer agent encounters an obscure CI failure, use WebSearch to find known issues (e.g., npm registry outages, GitHub Actions incidents, flaky test patterns).
tools
Assesses the current state of the startup project and recommends what to focus on next. Use when there is a need or a question from the user to understand what the next steps are or what to focus on next.
data-ai
Use at the start of any conversation about a startup idea, product validation, founder strategy, or work inside a `startup/` workspace. Establishes file conventions, voice-input handling, subagent dispatch rules, and how to update each artifact safely. Activate before invoking any other startup-superpowers skill.
tools
Manages the founder's survey-based validation — crafting the right questions, deploying a survey to the internet, and analyzing results against hypotheses. Use when the founder wants to run a survey, create survey questions, validate hypotheses at scale, check how a survey is going, understand whether a survey is the right tool right now, or deploy a question set to get quantitative signal. Also bring this up if you believe that creating a survey to collect quantitative evidence may be useful at this point.
development
Guides the founder through designing and optionally building the simplest MVP or prototype that validates their current hypotheses. Use when the founder wants to build something to test assumptions, discusses what to build next, wants to interpret results from a live MVP, or is deciding whether the current approach is still right. Also use when a founder proposes something to build — the skill will check whether the proposed form is the simplest thing that generates honest signal.