davepoon/buildwithclaude/plugins/claude-ops/skills/ops-merge/SKILL.md
ops-merge
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.
- Source repository stars
- 3,359
- Declared platforms
- 0
- Static risk flags
- 2
- Last source update
- 2026-08-24
- Source checked
- 2026-08-26
Decision brief
What it does: where it fits
Before executing, load: 1. Preferences: cat ${CLAUDEPLUGINDATADIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — read owner, timezone, project registry 2. Daemon health: cat ${CLAUDEPLUGINDATADIR}/daemon-health.json — if actionneeded set, surface to user 3.…
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/davepoon/buildwithclaude --skill "plugins/claude-ops/skills/ops-merge"Inspect the Agent Skill "ops-merge" from https://github.com/davepoon/buildwithclaude/blob/ebd20fe1d82fa74e9a2f94abfeff88090f6c758c/plugins/claude-ops/skills/ops-merge/SKILL.md at commit ebd20fe1d82fa74e9a2f94abfeff88090f6c758c. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Phase 1 — Classify the PR queue
Parse the pre-gathered JSON. For each PR, it's already classified as one of:
Parse the pre-gathered JSON. For each PR, it's already classified as one of:If --dry-run, stop here. Print the queue and exit. - 02
Phase 2 — Confirm and merge ready PRs
Unless --force was passed, use AskUserQuestion to confirm before merging:
Verify CI is still green: gh pr checks --repoIf green: gh pr merge --repo --squash --adminReport: ✓ Merged to - 03
Phase 3 — Dispatch fixers for PRs that need work
For PRs classified as needs-rebase, needs-ci-fix, or needs-review-response:
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: - 04
Phase 4 — Resolve surfaced conflicts
For each PR returned with status: "conflict" from a fixer agent:
Display the conflict summary:Use AskUserQuestion (max 4 options — CLAUDE.md Rule 1):Based on response: - 05
Phase 5 — Collect results and confirm merges
1. Verify the PR is now green: gh pr checks --repo 2. If green, use AskUserQuestion to confirm (unless --force):
Verify the PR is now green: gh pr checks --repoIf green, use AskUserQuestion to confirm (unless --force):If still red: report what's still broken, do not merge
Permission review
Static risk signals and limitations
Writes files
The documentation asks the agent to create, modify, or delete local files.
| `gh pr create --repo <repo> --title "<t>" --body "<b>" --base dev` | Create PR | PR URL |Reads files
The documentation asks the agent to read local files, directories, or repositories.
Read review comments: `gh api repos/<repo>/pulls/<number>/comments --jq '.[].body'`Writes files
The documentation asks the agent to create, modify, or delete local files.
If confirmed: create sync PR: `gh pr create --repo <repo> --base main --head dev --title "chore: sync dev → main"`Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 90/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 3,359 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- davepoon/buildwithclaude
- Skill path
- plugins/claude-ops/skills/ops-merge/SKILL.md
- Commit
- ebd20fe1d82fa74e9a2f94abfeff88090f6c758c
- License
- MIT
- Collected
- 2026-08-26
- Default branch
- main
View the original SKILL.md
Runtime Context
Before executing, load:
- Preferences:
cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json— readowner,timezone, project registry - Daemon health:
cat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json— ifaction_neededset, surface to user - Secrets: GitHub token: env
$GITHUB_TOKEN→ Doppler MCP (mcp__doppler__*) →doppler secrets get GITHUB_TOKEN --plain→ password manager
OPS ► MERGE
CLI/API Reference
gh CLI (GitHub)
| 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 |
Agent Teams support
If CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set, use Agent Teams for fixer agents (Phase 3). This enables:
- Steering fixers mid-flight if priorities change (e.g., a critical PR should be merged first)
- Fixers can report blockers and you can redirect them without waiting for completion
- Shared context: if fixer-A discovers a breaking change that affects fixer-B's PR, you can notify B
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".
Pre-gathered PR data
${CLAUDE_PLUGIN_ROOT}/bin/ops-merge-scan 2>/dev/null || echo '{"prs":[],"error":"merge-scan failed"}'
Your task
You are the merge orchestrator. Your job is to get every open PR across the owner's repos merged — fixing whatever blocks them first.
Parse arguments
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 merging- (empty) → process all repos, merge to dev only
Phase 1 — Classify the PR queue
Parse 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.
Phase 2 — Confirm and merge ready PRs
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:
- Verify CI is still green:
gh pr checks <number> --repo <repo> - If green:
gh pr merge <number> --repo <repo> --squash --admin - Report:
✓ Merged <repo>#<number> to <base>
Phase 3 — Dispatch fixers for PRs that need work
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.
Phase 4 — Resolve surfaced conflicts
For each PR returned with status: "conflict" from a fixer agent:
- Display the conflict summary:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OPS ► MERGE — Conflict in <repo>#<number>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Branch: <headRefName> → <baseBranchRef>
Conflicting files:
- <file1>
- <file2>
<diff_summary>
──────────────────────────────────────────────────────
- Use AskUserQuestion (max 4 options — CLAUDE.md Rule 1):
[Accept incoming (theirs)] [Keep current branch (ours)] [Open manual resolution] [Skip this PR]
- Based on response:
- Accept incoming (theirs): Create worktree, rebase with
git checkout --theirs .on each conflicting file,git add .,git rebase --continue, push force-with-lease - Keep current branch (ours): Create worktree, rebase with
git checkout --ours .on each conflicting file,git add .,git rebase --continue, push force-with-lease - Open manual resolution: Print step-by-step instructions for the operator to resolve manually, then check in with
git pushconfirmation before continuing the merge pipeline - Skip this PR: Note as
unresolved-conflict, include in final report
- Accept incoming (theirs): Create worktree, rebase with
Phase 5 — Collect results and confirm merges
As fixers complete:
- Verify the PR is now green:
gh pr checks <number> --repo <repo> - If green, use
AskUserQuestionto confirm (unless--force):Fixer resolved [repo]#[number] — [what was fixed]. CI is now green. [Merge now] [Skip — I'll review manually] - If still red: report what's still broken, do not merge
Phase 6 — --main sync (only if flag is set)
For each repo that has separate dev and main branches:
- Check if dev is ahead of main:
git -C <path> log main..dev --oneline | head -5 - If ahead, show the commits and use
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] - If confirmed: create sync PR:
gh pr create --repo <repo> --base main --head dev --title "chore: sync dev → main" - Wait for CI:
gh pr checks <sync-pr-number> --repo <repo> --watch(background, max 10 min) - If CI green:
gh pr merge <sync-pr-number> --repo <repo> --merge --admin(merge commit, not squash) - Pull main back into dev:
git -C <path> fetch origin && git -C <path> checkout dev && git -C <path> merge origin/main --no-edit
Phase 7 — Final report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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)
──────────────────────────────────────────────────────
Safety Rails (NEVER violate)
- NEVER force-push to main/master
- NEVER merge with red CI — fix root cause first
- NEVER bypass review on PRs touching auth, payments, PII, or secrets — these require
security-reviewersubagent audit before merge - NEVER run
git reset --hardon shared branches - ALWAYS use worktrees for fixes (multiple agents may be active)
- ALWAYS use
--adminonly for squash merges to dev (not main, unless--mainflag) - Max 10 PRs per invocation to avoid GitHub API throttling
- If a PR has > 50 files changed, flag it for manual review instead of auto-merging
Native tool usage
Monitor — live CI watching
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.
Tasks — progress tracking
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.
WebSearch — CI failure context
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).
Frequently asked questions
What to verify before installation and use
What does the ops-merge source document cover?
Before executing, load: 1. Preferences: cat ${CLAUDEPLUGINDATADIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — read owner, timezone, project registry 2. Daemon health: cat ${CLAUDEPLUGINDATADIR}/daemon-health.json — if actionneeded set, surface to user 3.…
How do I install ops-merge?
The source record exposes this install command: npx skills add https://github.com/davepoon/buildwithclaude --skill "plugins/claude-ops/skills/ops-merge". Inspect the command and pinned source before running it.
Which permission-related actions were detected?
Static rules flagged write-files, read-files in the source; the page lists the matching lines and excerpts.
Alternatives
Compare before choosing
alirezarezvani/claude-skills
app-store-optimization
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
brucesongs/kali-claw
insecure-design
Insecure Design (OWASP A06:2025) focuses on security flaws in system architecture and design phases, rather than code implementation-level bugs.
NintendaDev/unikit-ai
unikit-docs
Generate and maintain the project's TECHNICAL documentation from its codebase — scans the project structure, tech stack, and module boundaries, then writes a lean README landing page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs that are relevant. Use whenever the user wants to create, update, or validate documentation of the CODE or the project itself, e.g. "generate documentation", "create docs", "write the README", "update the project docs", "document th
K-Dense-AI/scientific-agent-skills
dask
Distributed computing for larger-than-RAM pandas/NumPy workflows. Use when you need to scale existing pandas/NumPy code beyond memory or across clusters. Best for parallel file processing, distributed ML, integration with existing pandas code. For out-of-core analytics on single machine use vaex; for in-memory speed use polars.