merge-innocent-pull-requests

name

merge-innocent-pull-requests

description

Use this skill to merge low-risk pull requests opened by automation bots across a list of GitHub repository owners: walk every repository, pick the open pull requests authored by `renovate`, `renovate[bot]`, or `github-actions[bot]`, keep only the ones where every required CI check has finished successfully, and merge them one by one. Stop after merging two hundred pull requests or after spending thirty minutes of wall-clock time on the run, whichever happens first. One run, one budget — then stop.

Treat the input as a list of GitHub account names — the OWNERS — supplied by the user or read from the current context; refuse to run if no owners are given, and do not invent owners from memory.

Use the gh CLI for every read and write against GitHub, so authentication, rate limits, and pagination are handled by the official tool rather than by ad hoc HTTP calls.

Record the wall-clock start time at the very beginning of the run and recheck it before every merge, because the run must stop as soon as thirty minutes have elapsed even if the merge counter is still below two hundred.

Maintain a merge counter that starts at zero and is incremented by one after every successful merge, and stop the run as soon as the counter reaches two hundred even if the time budget is not yet exhausted.

Iterate over the OWNERS in the order given, and for each owner list the public, non-archived, non-fork repositories (for example with gh repo list <owner> --no-archived --source --visibility public --limit 1000 --json name,defaultBranchRef), discarding mirrors, template repos, and repos whose description or topics mark them as deprecated, read-only, or moved.

For every surviving repository, list the open pull requests authored by an automation bot (for example with gh pr list --repo <owner>/<repo> --state open --json number,author,isDraft,mergeable,mergeStateStatus,headRefName,baseRefName,reviewDecision), and keep only the ones whose author login is exactly renovate, renovate[bot], github-actions, or github-actions[bot].

Discard every pull request that is a draft, that has merge conflicts (mergeable is CONFLICTING), that is blocked by required reviews (reviewDecision is REVIEW_REQUIRED or CHANGES_REQUESTED), or whose mergeStateStatus is BLOCKED, BEHIND, or DIRTY, because none of those states permit a clean merge.

For every remaining pull request, fetch the combined status of the head commit (for example with gh pr checks <number> --repo <owner>/<repo> --json name,status,conclusion), and keep the pull request only when every check has status equal to completed and conclusion equal to success, neutral, or skipped; treat any failure, cancelled, timed_out, action_required, stale, or still-running check as a hard reject.

Refuse to merge a pull request that has zero CI checks attached, because the contract of this skill is to merge only pull requests with all CI jobs green, and a pull request with no checks has no green signal at all.

Merge each surviving pull request with the merge method allowed by the repository, preferring squash when squash is enabled, otherwise rebase, otherwise a regular merge commit (for example with gh pr merge <number> --repo <owner>/<repo> --squash --delete-branch), and never override repository branch-protection rules to force a merge through.

If the merge call fails for any reason — branch protection, missing permissions, late-arriving check, network error — log the failure with the pull request URL and the exact error message, do not retry inside the same run, and continue with the next pull request.

Do not approve, comment on, label, assign, rebase, update, or close any pull request as part of this skill; the only write action permitted is the merge itself.

Do not open new pull requests, do not push commits to any branch, do not edit any file in any repository, and do not run any build; the skill exists purely to merge pull requests that automation bots already prepared.

Recheck the wall-clock budget and the merge counter after every merge attempt — successful or not — and break out of all loops the moment either limit is reached, so the run never overshoots its budget by more than one pull request.

Move on to the next repository in the current owner once every eligible pull request in the current repository is either merged or rejected, and move on to the next owner once every repository of the current owner has been processed.

Report at the end of the run a short factual summary: the number of pull requests merged, the number rejected with the dominant rejection reason, the wall-clock time spent, and the owner-and-repository pair where the run stopped, so the next run can resume from a known point.

Do not pick up a pull request that this skill rejected earlier in the same run, even if its CI turns green before the budget is exhausted, because re-evaluation inside a single run risks unbounded loops on flaky checks; let the next run of this skill reconsider it.