harnessprotocol/plugins/pr-sweep/skills/pr-sweep

Pull Request Sweep

A cross-repo PR sweep: discover → enrich → triage → review → act → report.

Announce at start: "I'm using the pr-sweep skill to sweep all open PRs."

---

Step 1: Discover All Open PRs

gh search prs \
  --author @me \
  --state open \
  --json number,title,url,isDraft,repository,headRefName,baseRefName,reviewDecision \
  --limit 100

Parse the result into a working list. Skip drafts immediately — they're not ready for action.

If you have more than 20 non-draft PRs, report the count and ask the user if they want to proceed or filter by repo.

---

Step 2: Enrich Each PR

For each non-draft PR, fetch CI and merge state in parallel (dispatch subagents or batch calls):

# CI status
gh pr checks <number> --repo <owner/repo> --json name,state,conclusion

# Merge state (up-to-date, behind, conflicting, etc.)
gh pr view <number> --repo <owner/repo> --json mergeStateStatus,mergeable

Build a status object per PR:

{
  repo, number, title, url,
  ciStatus: passing | failing | pending | none,
  mergeState: clean | behind | dirty | blocked,
  reviewDecision: APPROVED | CHANGES_REQUESTED | REVIEW_REQUIRED | null
}

---

Step 3: Triage

Classify each PR into one category (in priority order — first match wins):

| Category | Condition | |----------|-----------| | MERGE_READY | CI passing, review approved or not required, merge state clean | | PENDING_CI | CI still running, everything else clean | | NEEDS_REVIEW | No reviews yet (reviewDecision null or REVIEW_REQUIRED) | | BEHIND_BASE | Merge state is behind | | CI_FAILING | CI has failed conclusions | | CHANGES_REQUESTED | Reviewer has requested changes | | CONFLICTING | Merge state is dirty (merge conflicts) | | BLOCKED | Anything else preventing merge |

Show the triage table to the user and wait for confirmation before taking any action:

PR Triage
─────────────────────────────────────────────────────────────
MERGE_READY    owner/repo #42  feat: add caching layer
NEEDS_REVIEW   owner/repo #38  fix: auth token refresh
BEHIND_BASE    other/repo #11  refactor: split service
CI_FAILING     other/repo #9   feat: new export format
CHANGES_REQUESTED  repo #7     fix: race condition
─────────────────────────────────────────────────────────────
Plan: merge 1, review 1, rebase 1, attempt CI fix 1, flag 1.
Proceed?

Wait for the user to confirm before proceeding to Step 4. This is important — the sweep can merge multiple PRs and rebase branches across repos, so the user should know what's coming.

---

Step 4: Code Review (for NEEDS_REVIEW PRs)

For each NEEDS_REVIEW PR, invoke the review skill to review the changes.

If there are multiple NEEDS_REVIEW PRs: dispatch code review subagents in parallel — one per PR — then collect all results before proceeding to Step 5. This is the most expensive step; parallelizing keeps total time reasonable.

The review covers:

• Baseline: correctness, security, error handling, performance, naming, test coverage
• Codebase-specific: read the target repo's CLAUDE.md for any ## Code Review, ## Standards, or ## Gotchas sections

Each review produces:

[owner/repo #N] Code Review
MUST FIX: <issue> — file:line
SUGGESTION: <issue>
CLEAN — no blocking issues

After review, re-classify:

• No MUST FIX items → move to MERGE_READY (if CI also passing)
• Has MUST FIX items → move to BLOCKED (with review notes)

---

Step 5: Act

Work through categories in this order:

MERGE_READY → Merge

gh pr merge <number> --repo <owner/repo> --squash --delete-branch

BEHIND_BASE → Rebase

gh pr checkout <number> --repo <owner/repo>
BASE=$(gh pr view <number> --repo <owner/repo> --json baseRefName --jq '.baseRefName')
git fetch origin $BASE
git rebase origin/$BASE
git push --force-with-lease

Then re-check CI. If CI passes and no other blockers → merge. If CI fails → reclassify as CI_FAILING.

CI_FAILING → Attempt Quick Fix

1. Read the failure output: gh run view --log-failed --repo <owner/repo>
2. Quick fix (lint, format, import, typo): check out the PR branch, fix, commit, push
3. Complex failure: flag it — don't attempt a fix. Note it in the report.

PENDING_CI → Wait and Recheck Once

Poll using --watch with a timeout, then check the result:

gh pr checks <number> --repo <owner/repo> --watch --fail-fast

If still pending or if the command times out, leave as-is and flag in the report.

CHANGES_REQUESTED / CONFLICTING / BLOCKED → Flag Only

These require human judgment. Note them clearly in the report — no auto-action.

---

Step 6: Final Report

After all actions complete, produce a full report:

PR Sweep Complete
══════════════════════════════════════════════════════════════
MERGED (2)
  ✓ owner/repo #42  feat: add caching layer
  ✓ owner/repo #38  fix: auth token refresh — reviewed, no blockers

REBASED (1)
  ↺ other/repo #11  refactor: split service — rebased on main, CI running

FIXED & MERGED (1)
  ✓ other/repo #9   feat: new export format — lint fix applied, merged

NEEDS YOUR ATTENTION (2)
  ✗ repo #7   fix: race condition — CHANGES_REQUESTED by @alice
      Action needed: address review feedback

  ✗ repo #5   feat: dashboard — CI failing (complex: flaky integration test)
      Action needed: investigate test flakiness before merging

CODE REVIEW FINDINGS
  repo #38 — SUGGESTION: consider extracting token refresh logic to a helper
══════════════════════════════════════════════════════════════
Merged: 3  |  Pending: 1  |  Needs attention: 2

Surface suggestions from code reviews in the report even if they weren't blocking — they may inform follow-up work.

---

Rules

Never:

• Act on draft PRs
• Force-push to main/master
• Merge with failing CI
• Attempt to auto-resolve CHANGES_REQUESTED — that's a human conversation

Always:

• Triage and show the table before taking any action
• Squash merge
• Parallelize code review subagents when multiple PRs need review
• Clean up PR branches after merge (--delete-branch)

---

Future: Pairing with Loop

This skill is designed to work with /loop for ongoing PR babysitting:

/loop 30m /pr-sweep

This is not yet recommended due to token costs, but the skill is designed to be idempotent — running it multiple times is safe. Already-merged PRs won't appear in the next sweep.