sweep-prs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sweep PRs

PR扫描审计

Audit recently merged and closed PRs for anomalies that slipped through the normal PR lifecycle. Two strictly separated phases: a read-only sweep that gathers evidence, then confirmed remediation. Never mutate anything (issues, replies, resolutions) before the findings are confirmed.

对最近合并和关闭的PR进行审计，排查在常规PR生命周期中遗漏的异常情况。流程分为两个严格分离的阶段：只读扫描（收集证据），随后是经确认后的整改。在审计结果得到确认前，不得修改任何内容（包括问题、回复、线程状态标记）。

Invocation

调用方式

```
/sweep-prs
```
— current repo, last 14 days. Each sweep is stateless: no memory of previous runs, by design — pass an explicit window to change scope.
```
/sweep-prs 4d
```
/
```
/sweep-prs 30d
```
/
```
/sweep-prs since 2026-07-01
```
— explicit window; natural phrasing ("last 4 days") is fine too.
```
/sweep-prs lgtm-hq/podex lgtm-hq/py-lintro
```
— explicit repos (default: current checkout's repo, via
```
gh repo view
```
).
No checkout needed: all gathering uses
```
gh api
```
with explicit
```
owner/repo
```
, so explicit-repo invocations work from any directory; without a local checkout, verify claims via API file reads instead of
```
git show origin/main:
```
. Invoked outside any repo with no repo argument → ask which repo, don't guess.

```
/sweep-prs
```
— 针对当前仓库，扫描最近14天的PR。每次扫描都是无状态的：设计上不保留之前运行的记录——可通过指定时间范围来调整扫描范围。
```
/sweep-prs 4d
```
/
```
/sweep-prs 30d
```
/
```
/sweep-prs since 2026-07-01
```
— 指定时间范围；使用自然表述（如"last 4 days"）也可。
```
/sweep-prs lgtm-hq/podex lgtm-hq/py-lintro
```
— 指定仓库（默认：通过
```
gh repo view
```
获取当前本地检出的仓库）。
无需本地检出仓库：所有信息收集均通过
```
gh api
```
并指定
```
owner/repo
```
，因此即使在任意目录下也可调用指定仓库的扫描；若未本地检出仓库，则通过API读取文件来验证相关信息，而非使用
```
git show origin/main:
```
命令。若在非仓库目录下调用且未指定仓库参数，请询问目标仓库，切勿猜测。

Phase 1 — Gather (read-only)

第一阶段——收集信息（只读）

Enumerate merged and closed PRs in the window (

gh pr list --state merged

--state closed

, GraphQL for thread state).

Gather in bulk, not per-PR. Paginated GraphQL search (~25 PRs/page, fetching checks rollup + review threads + reviews in one query) covers hundreds of PRs in a handful of API calls; analyze the dump locally (

jq

). Reserve background sub-agents for Phase 2's per-finding assessment deep-reads, in batches of ~5 PRs each — read-only: no writes, no replies, no issue creation. Use server-side filters where they exist (e.g.

actions/runs?status=failure

for Check B) — client-side filtering of

gh run list

output silently truncates at the fetch limit.

枚举指定时间范围内已合并和已关闭的PR（使用

gh pr list --state merged

--state closed

命令，通过GraphQL获取线程状态）。

批量收集信息，而非逐个PR处理。 分页的GraphQL搜索（每页约25个PR，一次查询即可获取检查汇总、评审线程及评审记录）可通过少量API调用覆盖数百个PR；在本地使用

jq

分析导出的数据。预留后台子代理用于第二阶段中针对每个发现的深度评估，每次批量处理约5个PR——全程只读：不得写入、回复或创建问题。尽可能使用服务端过滤器（例如检查项B中使用

actions/runs?status=failure

）——对

gh run list

输出进行客户端过滤会在达到获取限制时自动截断内容，且无提示。

Check A — Merged without green builds

检查项A——未通过绿色构建即合并

For each merged PR, compare check-run conclusions on the merge commit (head SHA) against the merge timestamp:

Any required check
```
FAILURE
```
/
```
TIMED_OUT
```
/ still running at merge time.
Checks that never ran on the final head (stale approvals, admin bypass).
```
CANCELLED
```
runs are usually superseded duplicates, not failures — verify before flagging.

For each hit: was the failure addressed post-merge (follow-up commit on

main

, existing issue)? Record addressed/unaddressed.

针对每个已合并的PR，对比合并提交（head SHA）的检查运行结论与合并时间戳：

任何必填检查在合并时处于
```
FAILURE
```
/
```
TIMED_OUT
```
状态，或仍在运行中。
最终提交头从未执行过检查（过时的审批、管理员绕过检查）。
```
CANCELLED
```
状态的运行通常是被替代的重复任务，而非失败——标记前需先验证。

对于每个命中的异常：合并后是否已解决该失败问题（如在

main

分支提交后续修复代码、已有对应问题记录）？记录已解决/未解决状态。

Check B — Merged while main was red

检查项B——主线状态异常（red main）时合并

Reconstruct

main

's workflow-run health over the window (

gh run list --branch main

). For each merge that landed inside a red window: did the merge fix the redness, ignore it, or worsen it? Was the red-main cause tracked in an issue? Record.

重构指定时间范围内

main

分支的工作流运行健康状态（使用

gh run list --branch main

命令）。对于每个发生在主线状态异常时段内的合并：该合并是修复了主线异常、忽略了异常，还是加剧了异常？主线异常的原因是否已在问题中追踪？记录相关情况。

Check C — Review threads (all reviewers)

检查项C——评审线程（所有评审者）

For every merged/closed PR, via GraphQL:

Unresolved threads from any reviewer — CodeRabbit, Greptile, Bugbot, github-advanced-security/CodeQL, humans.
Post-merge reviews: reviewer activity timestamped after the merge — the in-flight-review race (see
```
babysit-pr
```
's merge-gate rule: zero threads is not evidence of review). These are invisible to normal PR hygiene and must be surfaced explicitly.
Hollow resolutions: threads resolved with no reply and no linked fix — per review-thread hygiene canon, resolve only via a fix or a disagreement reply.
Closed-not-merged PRs with dangling unresolved threads (superseded PRs whose findings were never carried to the successor).

针对每个已合并/已关闭的PR，通过GraphQL获取以下信息：

未解决的线程：来自任意评审者，包括CodeRabbit、Greptile、Bugbot、github-advanced-security/CodeQL及人工评审者。
合并后的评审：评审活动时间戳晚于合并时间——即评审与合并的竞态问题（参考
```
babysit-pr
```
的合并门限规则：零线程并不代表已完成评审）。这些情况在常规PR合规检查中不可见，必须明确披露。
无实质内容的线程标记已解决：线程被标记为已解决，但未给出回复且未关联修复内容——根据评审线程合规准则，仅当问题已修复或给出异议回复时，才可标记线程为已解决。
已关闭但未合并的PR中存在悬而未决的线程：被替代的PR，其评审发现未被延续至后续替代PR中。

Check D — Case-by-case checklist (extensible)

检查项D——逐项检查清单（可扩展）

A living list — add checks here as new anomaly patterns are observed rather than keeping them in chat memory:

Admin/bypass merges (
```
--admin
```
, branch-protection overrides) without a recorded justification.
PRs closed without any comment explaining why.
Repo-convention adherence where applicable (e.g. 1 PR = 1 release: change PRs merged without their release PR).
Version/lockfile drift introduced by a merge and not followed up.

这是一个动态更新的清单——当发现新的异常模式时，在此处添加检查项，而非存储在对话记忆中：

无记录理由的管理员/绕过规则的合并（使用
```
--admin
```
参数、覆盖分支保护规则）。
未添加任何解释评论即关闭的PR。
是否遵循仓库约定（例如：1个PR对应1次发布：合并了变更PR但未合并对应的发布PR）。
合并引入的版本/锁文件偏移未得到后续处理。

Phase 2 — Assess, summarize, then confirm (checkpoint, deliberate)

第二阶段——评估、汇总，然后确认（检查点，审慎决策）

Before presenting anything, assess every finding on its merits — read the thread/failure against current

main

and take a position:

Agree (real, still stands) → propose a follow-up issue (per the
```
issue
```
skill, with AI Implementation Prompt when code-shaped).
Disagree / moot / already addressed → propose a disposition reply + resolve (link the fixing commit/PR; no hollow resolutions).
No action, with one line of rationale (recorded in the report).

Then present a summary first, details on demand — aggregate counts with the assessment split, not per-item detail. The shape:

Found N unresolved threads and M hollow-resolved ones. Of the unresolved, I agree with X (propose follow-up issues) and disagree with Y (propose reply + resolve). Of the resolved, Z look wrongly resolved and deserve reopening or a follow-up issue.

Do not lead with what each individual finding was. The owner then chooses per bucket: approve the batch, drill into any subset item by item before deciding, or skip. Per-item detail (PR, severity, evidence, timestamps, links) is produced only when asked, and kept ready from Phase 1 so drill-down is instant.

Confirmation rules: the checkpoint is deliberate — never trade it away for fewer clicks. Questions must be self-contained and answerable without scrolling back: no invented codenames ("F1", "finding 3") pointing at earlier tables; each option states what-was-found and what-will-happen in its own words. No-action findings are report rows, never options. Batch approval is fine when the owner says so.

在提交任何结果前，根据实际情况评估每个发现——结合当前

main

分支的内容查看线程/失败情况，并给出判断：

认可（问题真实存在且仍未解决）→ 提议创建后续跟踪问题（遵循
```
issue
```
技能规范，若涉及代码修改则附上AI实现提示）。
不认可 / 已无关紧要 / 已解决→ 提议回复处理意见并标记线程为已解决（关联修复提交/PR；不得无实质内容标记已解决）。
无需操作，并给出一行理由（记录在报告中）。

随后采用先汇总、按需提供细节的方式呈现——按评估结果分类汇总数量，而非逐个展示细节。示例格式：

发现N个未解决线程和M个无实质内容标记已解决的线程。在未解决线程中，我认可X个（提议创建后续跟踪问题），不认可Y个（提议回复处理意见并标记已解决）。在已标记解决的线程中，有Z个属于错误标记，需重新打开或创建后续跟踪问题。

切勿先逐个展示每个发现的具体内容。仓库所有者可针对每个分类做出选择：批量批准处理、深入查看任意子集的逐个项目后再决策，或跳过。仅当被要求时才提供单个项目的细节（PR信息、严重程度、证据、时间戳、链接），且这些细节需从第一阶段准备就绪，以便即时展开深入查看。

确认规则：检查点是审慎决策环节——切勿为了减少操作步骤而省略该环节。问题必须独立完整，无需回溯即可回答：不得使用虚构代号（如"F1"、"发现3"）指向之前的表格；每个选项需用自身表述说明发现的问题及将要执行的操作。无需操作的发现仅作为报告条目，不得作为选项。若仓库所有者允许，可进行批量批准。

Phase 3 — Remediate (only what was confirmed)

第三阶段——整改（仅处理已确认的内容）

Execute exactly the confirmed dispositions: file issues, post replies, resolve threads. Follow the

issue

skill's backlog-stewardship rules (announce changes, comment before closing, no silent churn).

严格执行已确认的处理方案：创建问题、发布回复、标记线程为已解决。遵循

issue

技能的待办事项管理规则（公告变更、关闭前添加评论、不得静默修改）。

Final report

最终报告

Per repo: PRs swept (count, window), findings by check with disposition (issue filed / replied+resolved / no-action+rationale), issues created (URLs), and anything deferred with reason. The report is the sweep's only output — sweeps keep no state between runs; overlap between windows is harmless because remediated findings assess as already-dispositioned.

针对每个仓库：扫描的PR数量及时间范围、各检查项的发现及处理结果（已创建问题 / 已回复并标记解决 / 无需操作及理由）、已创建问题的URL，以及任何延迟处理的事项及理由。报告是扫描的唯一输出——扫描在每次运行之间不保留状态；时间范围重叠无影响，因为已整改的发现会被评估为已处理。

Notes

说明

This is the periodic, fleet-wide complement to
```
babysit-pr
```
's per-PR post-merge sweep backstop — that one catches the race on PRs it just merged; this one catches everything else, including sessions that didn't use the skills at all.
Origin: recurring manual ritual of eyeballing every merged PR's diff and threads across repos (2026-07-19; found podex#255/#262 post-merge CodeRabbit findings, incl. an unread Critical).

这是对
```
babysit-pr
```
工具针对单个PR的合并后扫描保障机制的补充，用于定期在全仓库范围内进行扫描——
```
babysit-pr
```
仅能捕获其刚合并的PR中的竞态问题；而本工具可捕获所有其他异常，包括未使用该技能的会话中的问题。
起源：源自反复手动检查各仓库中每个已合并PR的差异和线程的流程（2026-07-19；发现podex#255/#262合并后CodeRabbit的发现，包括一条未读的严重问题）。