awesome-quant/.agents/skills/bprr/SKILL.md

name, description

name	description
bprr	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, labels, files, body, and diff.
5. Review only added README.md entries unless the PR changes other files; flag other file changes as unusual.
6. Validate each PR with the same checks as $sprr. Use scripts/validate_readme.py --diff-from <base-ref> when the PR branch is available locally; otherwise apply the validator's rules manually from the MCP diff.

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 | Entries | Format | URL | Section | Duplicate | Verdict |
|----|-------|--------|---------|--------|-----|---------|-----------|---------|

After the table, list any PRs that need 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.