Skip to content

sweep-open-prs: skill for triaging the whole open PR queue - #1294

Open
potiuk wants to merge 3 commits into
mainfrom
sweep-open-prs-skill
Open

potiuk wants to merge 3 commits into
mainfrom
sweep-open-prs-skill

Conversation

@potiuk

@potiuk potiuk commented Sep 16, 2026

Copy link
Copy Markdown
Member

Adds a sweep-open-prs skill for the pass over the whole open PR queue: gather state for every open PR, bucket each one, act only on what is confirmed.

  • Two gh pr list calls cover the queue - one for state, one for a check rollup collapsed to only non-green results. Avoids the per-PR loop that trips gh's spurious 401.
  • Records the judgement rules that decide most of the queue: BLOCKED + REVIEW_REQUIRED means "needs one approval" rather than "broken"; a self-authored PR can never be self-approved; carried-over warnings are not regressions; a held bump is often superseded rather than fixed.
  • Routes anything red, or any bump being approved on substance rather than a green tick, to analyze-action-pr instead of duplicating its failure taxonomy.
  • Documents both skills in README.md under a new Agent Skills section, with a TOC entry. analyze-action-pr had never been documented; it is included rather than left invisible now that the section exists.

Test plan: prek run --files README.md .claude/skills/sweep-open-prs/SKILL.md passes. Frontmatter is 363 chars against the 1024 limit, with the two required fields. Both README links resolve to files in the tree and the #batch-reviewing-dependabot-prs anchor matches a real heading. Every gh invocation in the skill was run against this repo's live queue while drafting it.

🤖 Generated with Claude Code

Codifies the pass a maintainer makes repeatedly: gather state for every open
PR, bucket each one into merge-now / approve+merge / needs-triage / blocked,
and act only on what is confirmed.

Two `gh pr list` calls cover the queue -- one for state, one for a check
rollup collapsed to only non-green results -- which avoids the per-PR loop
that trips gh's spurious 401. Records the judgement rules that decide most of
the queue: BLOCKED + REVIEW_REQUIRED means "needs one approval" rather than
"broken", self-authored PRs can never be self-approved, carried-over warnings
are not regressions, and a held bump is often superseded rather than fixed.

Routes anything red, or any bump being approved on substance, to
analyze-action-pr rather than duplicating its failure taxonomy.

Generated-by: Claude Opus 5
Adds an Agent Skills section covering analyze-action-pr and sweep-open-prs,
with a TOC entry. Points readers at Batch-Reviewing Dependabot PRs as the
non-agent equivalent of the queue sweep.

analyze-action-pr had never been documented; it is included here rather than
left invisible now that the section exists.

Generated-by: Claude Opus 5
@potiuk
potiuk requested a review from dave2wave September 16, 2026 10:08
@potiuk

potiuk commented Sep 16, 2026

Copy link
Copy Markdown
Member Author

This one adds a SKILL - reflecting what I have been doing recently - swiping through all PRs with my agent and acting appropriately.

With this skill ANYONYE can do what I did regularly by just asking the agent "

"sweep throuh open PRs".

That's it - everything will happen automatically then, you will be asked to confirm the actions when they are safe, or asked to additionally review the PRs when there are doubts.

This should allow anyone to spend few minutes (!) a day - to keep the repo in a good shape.

@dfoulks1 @dave2wave @ppkarwasz -> I would love if you would like to try it and see how much time it saves.

@potiuk
potiuk requested a review from raboof September 16, 2026 11:50
@potiuk

potiuk commented Sep 16, 2026

Copy link
Copy Markdown
Member Author

Also @raboof -> With that SKIL I was able to sweep through 14 open PRs in lest than 10 minutes of elapsed time, with analysis of what they do, checking if they are sound, if they have no suspicious changes (this all on top of the deterministic analysis that we run in the PRs).

I highly recommend merging that one and starting using it by everyone from time to time. That will help us to avoid SPOFs and delay.

I even have an idea that when we have access to llmao we could add a workflow that will be using it automatically and all we get is an "review and approve" buttong to marge result of such a swipe.

This would be fantastic workflow - we would just get a single place where regularly. we will see:

  • there are 10 new PRs
  • 5 of them are ready to merge, save, checked for malicious code
  • 2 of them need attemtion
  • 5 of them are regular dependabot dependency upgrades with cooldown that looks safe

And any of us would be able to "Approve" all of them.

A CheckRun carries conclusion: null until status reaches COMPLETED, and its
state is always null -- state belongs to the StatusContext shape. Reaching
straight for (.conclusion // .state) printed a bare "name=" for every check
still running, which reads as a finding rather than "ask again in a minute".
It misreported a PR whose ten checks were simply mid-flight.

Read status first and report QUEUED / IN_PROGRESS, and record alongside the
UNKNOWN mergeability case that neither is a verdict.

Generated-by: Claude Opus 5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant