---
name: bprr
description: 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.
---

# BPRR: Bulk PR Reviewer

Review multiple open pull requests for README entry contributions.

## Hard Rules

1. Use GitHub MCP tools for PR operations. Do not use `gh` for PR review, comments, labels, closing, or merging.
2. Filter out PRs with the `reviewed` label unless the user asks to re-review them.
3. Do not comment, label, close, or merge until the user explicitly approves each action.
4. Do not auto-merge all approved PRs unless the user explicitly selects that option.
5. If GitHub MCP tools are unavailable, report the blocker and point to `docs/codex-setup.md`.

## Workflow

1. List open PRs sorted oldest first.
2. Filter to unreviewed PRs by default.
3. Fetch the default-branch `README.md` once for duplicate checks.
4. For each PR, fetch details, current head SHA, labels, files, body, diff, and the latest `Validate PR` workflow/check attempt for that SHA.
5. Review only added `README.md` entries unless the PR changes other files; flag other file changes as unusual.
6. 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. CI cannot establish commercial free-tier
eligibility or transparency, URL tracking, repository substance, or any other manual criterion.

## 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.
- Distinguish repositories containing substantive implementation from thin SDK, integration,
  examples, generated-data, or marketing repositories.
- Hosted proprietary products without substantive public source belong under
  `Commercial & Proprietary Services`, even when a thin repository exists.
- For repository-less commercial entries, verify a useful permanent free tier for quantitative
  finance that requires no payment information and is not a trial, demo, or waitlist.
- Treat a commercial service with only a thin SDK, integration, examples, generated-data, or
  marketing repository as repository-less for every eligibility check.
- Verify that these commercial entries publish pricing and free-tier limits plus public
  documentation, methodology, or usage examples; use a stable HTTPS URL without affiliate or
  tracking parameters; and have a concise, factual, non-promotional description.
- 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.

Apply verdict rules independently to every PR:

- Commercial submissions without a qualifying permanent free tier—including paid-only,
  trial-only, demo-only, and waitlist-only offerings—are `REJECT`.
- Reserve `NEEDS CHANGES` for correctable evidence or disclosure, wording, URL, documentation, or
  placement defects when the underlying offering can qualify.

## Summary Output

Present a table:

```text
| 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. When repository-less commercial eligibility affects a
verdict, explain the free-tier and transparency evidence in those detailed notes.

Ask what to do next. Accept selections like:

- `merge 123, 124`
- `comment 125`
- `close 126`
- `all approved`
- `none`

Confirm each merge before executing it.