gavindiaz/awesome-quant
1
0
Fork 0
mirror of https://github.com/wilsonfreitas/awesome-quant.git synced 2026-08-18 06:18:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

refactor: update BPRR and SPRR skills for improved PR validation and workflow clarity

Browse Source
This commit is contained in:
Wilson Freitas
2026-08-12 21:22:06 -03:00
parent c839fd5ab3
commit 28f3d92b22
4 changed files with 208 additions and 345 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/bprr/SKILL.md
+30 -5
View File
@@ -20,9 +20,28 @@ Review multiple open pull requests for README entry contributions.
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.
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. 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.
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.
## Validation Checklist
@@ -50,11 +69,17 @@ For each added entry, check:
Present a table:
```text
| PR | Title | Author | Entries | Format | URL | Section | Duplicate | Verdict |
|----|-------|--------|---------|--------|-----|---------|-----------|---------|
| PR | Title | Author | Head | Validate PR | Entries | Format/URL | Section | Duplicate | Verdict |
|----|-------|--------|------|-------------|---------|------------|---------|-----------|---------|
```
After the table, list any PRs that need detailed notes.
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:
.agents/skills/sprr/SKILL.md
+28 -3
View File
@@ -20,10 +20,11 @@ If GitHub MCP tools are unavailable, report that PR operations are blocked and p
## Workflow
1. Fetch PR details, files changed, labels, comments, and diff with GitHub MCP.
1. Fetch PR details, current head SHA, files changed, labels, comments, and diff with GitHub MCP.
2. Confirm whether the `reviewed` label or prior maintainer comments exist, then proceed with full validation anyway.
3. Focus on added lines in `README.md`. Flag any other changed files as unusual for a normal contribution.
4. Save or reconstruct the PR diff locally only if needed, then validate added README entries with:
3. Fetch the latest `Validate PR` workflow/check attempt for the current head SHA and apply the CI evidence rules below.
4. Focus on added lines in `README.md`. Flag any other changed files as unusual for a normal contribution.
5. 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:
```bash
uv run python scripts/validate_readme.py --diff-from <base-ref>
@@ -31,6 +32,25 @@ 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.
## Validation Checklist
For every added entry:
@@ -73,6 +93,11 @@ 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>