OpenClaw Landable Bug Sweep

Autonomous maintainer workflow for producing five landable OpenClaw bugfix PR URLs. Use for broad issue/PR sweeps where the bar is high and the output is PRs, not notes. Do not use for plugin SDK/API boundary work; those need separate architecture review.

Target

Return exactly five PR URLs, each with:

• bug summary
• why the fix is low-risk
• proof: rebased-head local/Testbox/live commands or run IDs
• autoreview: clean result on the exact head being shown
• CI green on the exact pushed PR head
• issue/duplicate cleanup done or still pending

The five URLs may be existing PRs that were reviewed/fixed, or new PRs created from issues/clusters. Do not present a PR URL to the maintainer until it has been refreshed on current main, left-tested, autoreviewed clean, pushed, and verified green in live GitHub CI. If code, tests, changelog, PR body, or branch base changes after autoreview, rerun autoreview before showing the URL.

Companion Skills

Use $gitcrawl for discovery/clustering, $openclaw-pr-maintainer for live GitHub mutation rules, $github-author-context when contributor trust matters, $openclaw-testing for proof choice, $autoreview before publishing/landing, and $crabbox for broad/E2E/live proof.

Candidate Bar

Accept only when all are true:

• bug or paper cut, not feature/product/support/docs-only
• root cause is proven in current code
• dependency behavior checked via upstream docs/source/types when relevant
• production/runtime diff is small, ideally much smaller than 500 LOC and always below 500 LOC
• tests may be larger, but focused
• no new dependency
• no new config option
• no backward-incompatible behavior
• no security/product/owner-boundary decision needed
• no plugin SDK, public plugin API, or src/plugin-sdk/** boundary change
• no broad refactor smell
• focused proof is feasible
• branch can be rebased/refreshed and pushed, or a replacement PR can be created

Good examples:

• provider parameter mismatch proven against dependency/API contract
• CLI command diverges from adjacent command behavior
• narrow runtime state/serialization bug with failing test
• issue already fixed on current main, with proof and closeable duplicates

Reject:

• feature requests, new knobs, migrations, release work, workflow policy, support
• plugin SDK/API boundary changes, including compatibility shims, new SDK methods, SDK exports, or plugin-facing channel/provider seams
• auth/security boundary changes unless explicitly assigned
• bugs needing live credentials that are unavailable
• PRs with red CI unless you fix, rebase, push, and recheck them green
• PRs you only reviewed locally but did not refresh/push/check live
• PRs whose final head has not passed $autoreview
• fixes whose clean shape is a larger architecture move
• speculative reports without reproducible/provable cause
• UI/UX changes requiring product judgment

Sweep Loop

1. Start clean:
   • git status -sb
   • git pull --ff-only
   • verify branch is expected, usually main
2. Build candidate clusters:
   • gitcrawl open issues/PRs, neighbors, and search
   • live gh issue/pr view
   • include PRs linked from issues and duplicates
3. For each cluster:
   • read issue/PR body, comments, labels, linked refs, current source, adjacent tests
   • suppress maintainer-owned queue noise unless it is the best fix path
   • identify opener/author and preserve credit
   • decide: repair-existing-pr, create-new-pr, close-fixed-on-main, close-duplicate, or reject
4. Prove before patching:
   • failing test, focused repro, log/source proof, or dependency contract proof
   • if already fixed on main, prove with current source/test/commit and close kindly
5. Patch:
   • prefer existing PR when good and writable
   • if unwritable or wrong shape, create own PR and preserve useful contributor credit
   • if no PR exists, create one
   • add regression test when it fits

…