BPRR: Bulk PR Reviewer
Review multiple open pull requests for README entry contributions.
Hard Rules
- Use GitHub MCP tools for PR operations. Do not use
gh for PR review, comments, labels, closing, or merging.
- Filter out PRs with the
reviewed label unless the user asks to re-review them.
- Do not comment, label, close, or merge until the user explicitly approves each action.
- Do not auto-merge all approved PRs unless the user explicitly selects that option.
- If GitHub MCP tools are unavailable, report the blocker and point to
docs/codex-setup.md.
Workflow
- List open PRs sorted oldest first.
- Filter to unreviewed PRs by default.
- Fetch the default-branch
README.md once for duplicate checks.
- For each PR, fetch details, current head SHA, labels, files, body, diff, and the latest
Validate PR workflow/check attempt for that SHA.
- Review only added
README.md entries unless the PR changes other files; flag other file changes as unusual.
- Apply the CI evidence rules below, then perform the remaining
$sprr checks. Use scripts/validate_readme.py --diff-from <base-ref> only when current-head CI does not establish mechanical validity and the PR branch is available locally; otherwise apply the validator's rules manually from the MCP diff.
CI Evidence Rules
Evaluate each PR independently. Use only the latest attempt for the current head SHA; a newer
queued or pending attempt supersedes an older success for that SHA. A result for one PR or
commit never applies to another.
| Current-head result |
Review behavior |
success |
Accept parser format, tag syntax, separators, the required final period, HTTPS, GitHub-link syntax, recognized section, and base-README duplicate checks as passed. Do not repeat those mechanical checks. |
failure |
Inspect the failing job or step. Use NEEDS CHANGES when validation failed; if another step failed or details are unavailable, reproduce mechanical validation before deciding. |
| queued, pending, awaiting approval |
Mark the review incomplete and do not return APPROVE. |
| skipped, cancelled, missing |
Treat mechanical validation as unverified and reproduce it before deciding. |
| success only on an older SHA |
Report STALE, ignore it, and reproduce mechanical validation for the current head SHA. |
For every PR, still inspect the diff and manually review tag meaning and concision, description
quality, relevance, semantic section suitability, commercial classification, repository
activity/archive/documentation/community evidence, duplicates in open PRs and PRs closed
within the last 365 days, and multi-project relatedness.
Validation Checklist
For each added entry, check:
- Parser regex match.
- Required backtick tags for new non-commercial entries. Treat them as a compact tag cloud:
accept concise languages, runtimes, protocols, interfaces, data types, and domain terms.
- Separate concepts must use adjacent tags, such as
`Python` `C++` `MCP`; do not require
every tag to be a programming language.
- Description period before optional
[GitHub](...).
https:// URLs.- Exact optional
[GitHub](https://github.com/owner/repo) format.
- Correct category section.
- Commercial placement under
Commercial & Proprietary Services.
- Duplicate project names or URLs.
- Treat any verifiable GitHub repository mentioned as the main URL or exact
[GitHub](...)
suffix as a strong positive relevance signal.
- For GitHub repos, check source availability, activity, archived status, documentation, and
community evidence. GitHub relevance does not waive duplicate, format, or quality checks.
- Clear rationale for multiple related projects in one PR.
Summary Output
Present a table:
| PR | Title | Author | Head | Validate PR | Entries | Format/URL | Section | Duplicate | Verdict |
|----|-------|--------|------|-------------|---------|------------|---------|-----------|---------|
Use the entry count in Entries. Use PASS, FAIL, PENDING, UNVERIFIED, or
STALE in Validate PR. Use CI PASS, CI FAIL, REPRODUCED PASS,
REPRODUCED FAIL, or INCOMPLETE in Format/URL. Section remains a manual
semantic judgment. In Duplicate, report both README PASS|FAIL and
PR SEARCH PASS|FAIL.
After the table, list any PRs that need detailed notes, including the failing workflow step or the reason CI evidence was not accepted.
Ask what to do next. Accept selections like:
merge 123, 124comment 125close 126all approvednone
Confirm each merge before executing it.
1---2name: bprr-23description: Bulk PR reviewer for awesome-quant. Use when the user asks to review all open PRs, review unreviewed PRs, bulk review, or mentions "bprr". Reviews open PRs lacking the reviewed label and presents a summary before any merge/comment/label action.4---56# BPRR: Bulk PR Reviewer78Review multiple open pull requests for README entry contributions.910## Hard Rules11121. Use GitHub MCP tools for PR operations. Do not use `gh` for PR review, comments, labels, closing, or merging.132. Filter out PRs with the `reviewed` label unless the user asks to re-review them.143. Do not comment, label, close, or merge until the user explicitly approves each action.154. Do not auto-merge all approved PRs unless the user explicitly selects that option.165. If GitHub MCP tools are unavailable, report the blocker and point to `docs/codex-setup.md`.1718## Workflow19201. List open PRs sorted oldest first.212. Filter to unreviewed PRs by default.223. Fetch the default-branch `README.md` once for duplicate checks.234. For each PR, fetch details, current head SHA, labels, files, body, diff, and the latest `Validate PR` workflow/check attempt for that SHA.245. Review only added `README.md` entries unless the PR changes other files; flag other file changes as unusual.256. Apply the CI evidence rules below, then perform the remaining `$sprr` checks. Use `scripts/validate_readme.py --diff-from <base-ref>` only when current-head CI does not establish mechanical validity and the PR branch is available locally; otherwise apply the validator's rules manually from the MCP diff.2627## CI Evidence Rules2829Evaluate each PR independently. Use only the latest attempt for the current head SHA; a newer30queued or pending attempt supersedes an older success for that SHA. A result for one PR or31commit never applies to another.3233| Current-head result | Review behavior |34|---|---|35| `success` | Accept parser format, tag syntax, separators, the required final period, HTTPS, GitHub-link syntax, recognized section, and base-README duplicate checks as passed. Do not repeat those mechanical checks. |36| `failure` | Inspect the failing job or step. Use `NEEDS CHANGES` when validation failed; if another step failed or details are unavailable, reproduce mechanical validation before deciding. |37| queued, pending, awaiting approval | Mark the review incomplete and do not return `APPROVE`. |38| skipped, cancelled, missing | Treat mechanical validation as unverified and reproduce it before deciding. |39| success only on an older SHA | Report `STALE`, ignore it, and reproduce mechanical validation for the current head SHA. |4041For every PR, still inspect the diff and manually review tag meaning and concision, description42quality, relevance, semantic section suitability, commercial classification, repository43activity/archive/documentation/community evidence, duplicates in open PRs and PRs closed44within the last 365 days, and multi-project relatedness.4546## Validation Checklist4748For each added entry, check:4950- Parser regex match.51- Required backtick tags for new non-commercial entries. Treat them as a compact tag cloud:52 accept concise languages, runtimes, protocols, interfaces, data types, and domain terms.53- Separate concepts must use adjacent tags, such as `` `Python` `C++` `MCP` ``; do not require54 every tag to be a programming language.55- Description period before optional `[GitHub](...)`.56- `https://` URLs.57- Exact optional `[GitHub](https://github.com/owner/repo)` format.58- Correct category section.59- Commercial placement under `Commercial & Proprietary Services`.60- Duplicate project names or URLs.61- Treat any verifiable GitHub repository mentioned as the main URL or exact `[GitHub](...)`62 suffix as a strong positive relevance signal.63- For GitHub repos, check source availability, activity, archived status, documentation, and64 community evidence. GitHub relevance does not waive duplicate, format, or quality checks.65- Clear rationale for multiple related projects in one PR.6667## Summary Output6869Present a table:7071```text72| PR | Title | Author | Head | Validate PR | Entries | Format/URL | Section | Duplicate | Verdict |73|----|-------|--------|------|-------------|---------|------------|---------|-----------|---------|74```7576Use the entry count in `Entries`. Use `PASS`, `FAIL`, `PENDING`, `UNVERIFIED`, or77`STALE` in `Validate PR`. Use `CI PASS`, `CI FAIL`, `REPRODUCED PASS`,78`REPRODUCED FAIL`, or `INCOMPLETE` in `Format/URL`. `Section` remains a manual79semantic judgment. In `Duplicate`, report both `README PASS|FAIL` and80`PR SEARCH PASS|FAIL`.8182After the table, list any PRs that need detailed notes, including the failing workflow step or the reason CI evidence was not accepted.8384Ask what to do next. Accept selections like:8586- `merge 123, 124`87- `comment 125`88- `close 126`89- `all approved`90- `none`9192Confirm each merge before executing it.
wilsonfreitas