/openclaw-pr-batch-sweep

name: openclaw-pr-batch-sweep
description: Select, review, repair, validate, and land batches of up to 20 low-risk OpenClaw contributor pull requests using Vincent's maintainer preferences and bounded sub-agent lanes. Use for "next 20", broad contributor PR sweeps, merge-candidate mining, or continued PR-batch work where drafts, maintainer work, trivial one-line changes, UI, security, migrations, and high-risk changes must be excluded.
license: MIT
metadata:
  source: "https://github.com/vincentkoc/dotskills"
  version: "0.2.7"
  spec: agentskills-v1

OpenClaw PR Batch Sweep

Purpose

Drive a continuing queue of real, low-risk OpenClaw contributor bug fixes through qualification, repair, proof, and landing. Work in batches of up to 20 without padding the batch with micro-patches, speculative cleanup, or risky surfaces.

Requires `ghx`, `gitcrawl`, `gwt`, and the OpenClaw maintainer, testing, autoreview, Crabbox, and ClawSweeper skills.

Read [references/operator-selection-policy.md](references/operator-selection-policy.md) before selecting candidates. Read [references/worker-contract.md](references/worker-contract.md) before spawning sub-agents. Read and update [references/decision-ledger.json](references/decision-ledger.json) so fresh runs inherit prior landed, rejected, closed, and explicitly skipped PRs.

Compose the repository skills instead of duplicating them:

• `$openclaw-pr-maintainer` for live GitHub evidence and mutations.
• `$openclaw-landable-bug-sweep` for proof, repair, and landing.
• `$gitcrawl` for discovery and duplicate clusters.
• `$openclaw-testing`, `$crabbox`, and `$autoreview` for validation.
• `$clawsweeper` for readiness labels and exact-head review evidence.

When to use

• The operator says `next 20`, `continue the PR sweep`, or asks for another batch.
• The operator wants contributor PRs reproduced, narrowed, repaired, tested, and landed.
• The queue must exclude drafts, maintainer-owned work, UI, security, SSRF, auth, config migrations, and high-risk changes.
• Prior accept/reject decisions should shape future candidate selection.
• Reuse a small retained worker pool so review scales without accumulating completed workers or creating noisy local process pressure.

Workflow

1. Recover and continue the existing queue.

• Read recent thread state and the batch ledger.
• Read `auditWatermark` when present. Use `openPrThrough` as the default floor for newly created PR discovery instead of rehydrating an unchanged live edge.
• The watermark is not a terminal decision. An older unhandled PR may re-enter only when its head SHA or risk/readiness state materially changed; terminal ledger entries never re-enter.
• Verify current `main`, live PR state, repo instructions, `VISION.md`, disk, and worktree health.
• Keep a handled set containing merged, closed, rejected, ignored, draft, and explicitly skipped PRs.
• Never recycle prior candidates merely because their metadata changed.

2. Discover broadly, then reject aggressively.

• Start with `gitcrawl`; verify live state with `ghx`. If `gitcrawl` is stale, malformed, or unavailable, fall through immediately to live `ghx`.
• Run discovery and hydration shell calls serially on the maintainer host. Do not fan out `gitcrawl`, `ghx`, or per-PR REST calls in parallel.
• Fetch at least 100 open PRs. Widen toward 1000 when the strict filter yields fewer than 20.
• Pipe discovery JSON into the ranker. It accepts a raw PR array or gitcrawl's `{ "threads": [...] }` envelope. Keep `labels_json`, `author_login`, and `is_draft` for normalization.
• Combine `handled_refs` and `explicit_skips` into comma-separated `HANDLED_PRS`. Numbers, `#123`, and full pull-request URLs are accepted.
• Pipe the first ranking into `scripts/hydrate-candidates.mjs --input -`, then rank its stdout with `--hydrated`. Hydration remains serial and includes REST metadata, paginated file deltas, live checks, and mergeability retries.
• Set `SKILL_ROOT` to this skill's directory. For live discovery, run this pipeline in Bash or Zsh:

     set -o pipefail
     ghx pr list --repo openclaw/openclaw --state open --limit 100 \
       --json number,title,url,author,labels,isDraft,state |
       node "$SKILL_ROOT/scripts/rank-candidates.mjs" \
         --limit 40 --batch-size 20 \
         --decision-ledger "$SKILL_ROOT/references/decision-ledger.json" \
         --exclude "$HANDLED_PRS" |
       node "$SKILL_ROOT/scripts/hydrate-candidates.mjs" --input - |
       node "$SKILL_ROOT/scripts/rank-candidates.mjs" --hydrated \
         --decision-ledger "$SKILL_ROOT/references/decision-ledger.json" \
         --exclude "$HANDLED_PRS"

• Treat any nonzero pipeline status as failure. Do not act on JSON from a failed pipeline.
• Retain intermediate JSON only for a concrete debugging or recovery need. Explicit `--input <file>` and hydrator `--output <file>` remain available.
• If process launch returns `EMFILE`, `Too many open files`, or another file-descriptor exhaustion error, stop spawning workers and parallel shells immediately. Let retained lanes finish, then continue from the coordinator with one shell call at a time.
• When REST returns `mergeable: null` or an unknown merge state, retry that PR fetch up to three times with a two-second delay. If GitHub still has not resolved it, carry the PR as indeterminate instead of admitting it to the final batch.
• Final ranking rejects missing author association, partial file hydration, dirty/conflicting state, failed checks, and high-risk changed paths.
• Treat pending non-routine checks as not ready. Do not admit them merely because older checks passed.
• Risk labels are routing signals, not proof of a risky surface. Exact security/auth and availability labels are hard exclusions. A compatibility label alone still requires qualification against the title and changed paths.
• Production-size and test/docs-only gates are intent