SPRR: Single PR Reviewer
Review one pull request that adds entries to README.md.
Hard Rules
- Review only the PR number the user requested. If no PR number is given, ask for one.
- Use GitHub MCP tools for PR operations. Do not use
gh for PR review, comments, labels, closing, or merging.
- Do not modify the PR until the user explicitly approves that action.
- Always present findings before asking whether to comment, label, close, or merge.
- Always ask before merging.
- Enforce
CONTRIBUTING.md and AGENTS.md strictly for new entries.
If GitHub MCP tools are unavailable, report that PR operations are blocked and point the user to docs/codex-setup.md.
Workflow
- Fetch PR details, current head SHA, files changed, labels, comments, and diff with GitHub MCP.
- Confirm whether the
reviewed label or prior maintainer comments exist, then proceed with full validation anyway.
- Fetch the latest
Validate PR workflow/check attempt for the current head SHA and apply the CI evidence rules below.
- Focus on added lines in
README.md. Flag any other changed files as unusual for a normal contribution.
- When mechanical validation is not established by current-head CI, save or reconstruct the PR diff locally only if needed, then validate added README entries with:
uv run python scripts/validate_readme.py --diff-from <base-ref>
If a base ref is not locally available, apply the same checks manually from the fetched diff.
CI Evidence Rules
Use only the latest attempt whose commit SHA exactly matches the PR's current head SHA. A newer
queued or pending attempt supersedes an older successful attempt for the same SHA.
| 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 rerun those mechanical checks. |
failure |
Inspect the failing job or step. Return NEEDS CHANGES when validation failed; if another step failed or details are unavailable, reproduce mechanical validation before deciding. |
| queued, pending, awaiting approval |
Report the review as incomplete and do not return APPROVE. |
| skipped, cancelled, missing |
Treat mechanical validation as unverified and reproduce it before deciding. |
| success on an older SHA |
Ignore it and evaluate the current SHA using these rules. |
CI never replaces inspection of the diff or the manual checks below. A successful check confirms
only mechanical rules; it does not establish tag meaning or concision, description quality,
relevance, semantic section suitability, commercial classification, repository quality,
cross-PR uniqueness, or multi-project relatedness. Search open PRs and PRs closed within the
last 365 days for duplicate names and URLs.
For repository substance and linked commercial services, apply the Repository Substance and
Linked Services investigation in .agents/skills/sprr/SKILL.md, including its evidence,
service-first link, and eligibility verdict rules.
Validation Checklist
For every added entry:
- It matches
^\s*- \[(.*)\]\((.*)\) - (.*)$.
- New non-commercial entries include one or more backtick tags followed by
-. Treat these
as a compact tag cloud: accept concise languages, runtimes, protocols, interfaces, data
types, and domain terms.
- Separate concepts use adjacent tags, such as
`Python` `C++` `MCP`; do not reject a tag
merely because it is not a programming language.
- Description ends with a period before optional
[GitHub](...).
- URLs use
https://.
- Optional GitHub link uses
[GitHub](https://github.com/owner/repo).
- Section placement matches the project's purpose.
- Commercial/proprietary projects are under
Commercial & Proprietary Services.
- Project name and URLs are not duplicates of existing README entries.
- A verifiable GitHub repository containing substantive implementation, mentioned as the main URL
or exact
[GitHub](...) suffix, is a strong positive relevance signal.
- GitHub projects are checked for source availability, activity, archived status,
documentation, and community evidence. GitHub relevance does not waive duplicate, format,
or quality checks.
- Multiple projects in one PR are closely related and explained in the PR body.
Verdicts
Use these verdicts:
APPROVE: entry is ready to merge.NEEDS CHANGES: fixable format, section, URL, description, or documentation issue.REJECT: duplicate, unrelated multi-project PR, empty PR description, archived/abandoned project, or other hard rejection.
Output Shape
Report:
PR #<number>: <title>
Author: <author>
Prior review: YES/NO
Files changed: <files>
Entries reviewed: <count>
Automated validation:
- Validate PR: PASS | FAIL | PENDING | UNVERIFIED
- Commit: <checked-sha> (CURRENT | STALE)
- Mechanical checks: accepted from CI | reproduced manually | incomplete
Findings:
- <entry>: <status and reason>
Verdict: APPROVE | NEEDS CHANGES | REJECT
Recommended action: <merge/comment/close/no action>
Then ask for explicit approval before doing the recommended action.
Approved Actions After User Consent
- If approved and user says to merge: merge with squash unless user requests otherwise.
- If needs changes and user says to comment: leave one concise comment with all requested fixes, then add
reviewed if available.
- If rejected and user says to close: leave a polite rejection comment and close the PR.
1---2name: sprr-23description: Single PR reviewer for awesome-quant. Use when the user asks to review, validate, comment on, label, close, or merge one specific pull request that adds README.md entries. Triggers include "sprr", "review PR", "check PR", and "validate contribution".4---56# SPRR: Single PR Reviewer78Review one pull request that adds entries to `README.md`.910## Hard Rules11121. Review only the PR number the user requested. If no PR number is given, ask for one.132. Use GitHub MCP tools for PR operations. Do not use `gh` for PR review, comments, labels, closing, or merging.143. Do not modify the PR until the user explicitly approves that action.154. Always present findings before asking whether to comment, label, close, or merge.165. Always ask before merging.176. Enforce `CONTRIBUTING.md` and `AGENTS.md` strictly for new entries.1819If GitHub MCP tools are unavailable, report that PR operations are blocked and point the user to `docs/codex-setup.md`.2021## Workflow22231. Fetch PR details, current head SHA, files changed, labels, comments, and diff with GitHub MCP.242. Confirm whether the `reviewed` label or prior maintainer comments exist, then proceed with full validation anyway.253. Fetch the latest `Validate PR` workflow/check attempt for the current head SHA and apply the CI evidence rules below.264. Focus on added lines in `README.md`. Flag any other changed files as unusual for a normal contribution.275. When mechanical validation is not established by current-head CI, save or reconstruct the PR diff locally only if needed, then validate added README entries with:2829```bash30uv run python scripts/validate_readme.py --diff-from <base-ref>31```3233If a base ref is not locally available, apply the same checks manually from the fetched diff.3435## CI Evidence Rules3637Use only the latest attempt whose commit SHA exactly matches the PR's current head SHA. A newer38queued or pending attempt supersedes an older successful attempt for the same SHA.3940| Current-head result | Review behavior |41|---|---|42| `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 rerun those mechanical checks. |43| `failure` | Inspect the failing job or step. Return `NEEDS CHANGES` when validation failed; if another step failed or details are unavailable, reproduce mechanical validation before deciding. |44| queued, pending, awaiting approval | Report the review as incomplete and do not return `APPROVE`. |45| skipped, cancelled, missing | Treat mechanical validation as unverified and reproduce it before deciding. |46| success on an older SHA | Ignore it and evaluate the current SHA using these rules. |4748CI never replaces inspection of the diff or the manual checks below. A successful check confirms49only mechanical rules; it does not establish tag meaning or concision, description quality,50relevance, semantic section suitability, commercial classification, repository quality,51cross-PR uniqueness, or multi-project relatedness. Search open PRs and PRs closed within the52last 365 days for duplicate names and URLs.5354For repository substance and linked commercial services, apply the **Repository Substance and55Linked Services** investigation in `.agents/skills/sprr/SKILL.md`, including its evidence,56service-first link, and eligibility verdict rules.5758## Validation Checklist5960For every added entry:6162- It matches `^\s*- \[(.*)\]\((.*)\) - (.*)$`.63- New non-commercial entries include one or more backtick tags followed by ` - `. Treat these64 as a compact tag cloud: accept concise languages, runtimes, protocols, interfaces, data65 types, and domain terms.66- Separate concepts use adjacent tags, such as `` `Python` `C++` `MCP` ``; do not reject a tag67 merely because it is not a programming language.68- Description ends with a period before optional `[GitHub](...)`.69- URLs use `https://`.70- Optional GitHub link uses `[GitHub](https://github.com/owner/repo)`.71- Section placement matches the project's purpose.72- Commercial/proprietary projects are under `Commercial & Proprietary Services`.73- Project name and URLs are not duplicates of existing README entries.74- A verifiable GitHub repository containing substantive implementation, mentioned as the main URL75 or exact `[GitHub](...)` suffix, is a strong positive relevance signal.76- GitHub projects are checked for source availability, activity, archived status,77 documentation, and community evidence. GitHub relevance does not waive duplicate, format,78 or quality checks.79- Multiple projects in one PR are closely related and explained in the PR body.8081## Verdicts8283Use these verdicts:8485- `APPROVE`: entry is ready to merge.86- `NEEDS CHANGES`: fixable format, section, URL, description, or documentation issue.87- `REJECT`: duplicate, unrelated multi-project PR, empty PR description, archived/abandoned project, or other hard rejection.8889## Output Shape9091Report:9293```text94PR #<number>: <title>95Author: <author>96Prior review: YES/NO97Files changed: <files>98Entries reviewed: <count>99100Automated validation:101- Validate PR: PASS | FAIL | PENDING | UNVERIFIED102- Commit: <checked-sha> (CURRENT | STALE)103- Mechanical checks: accepted from CI | reproduced manually | incomplete104105Findings:106- <entry>: <status and reason>107108Verdict: APPROVE | NEEDS CHANGES | REJECT109Recommended action: <merge/comment/close/no action>110```111112Then ask for explicit approval before doing the recommended action.113114## Approved Actions After User Consent115116- If approved and user says to merge: merge with squash unless user requests otherwise.117- If needs changes and user says to comment: leave one concise comment with all requested fixes, then add `reviewed` if available.118- If rejected and user says to close: leave a polite rejection comment and close the PR.
wilsonfreitas