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

docs: align PR reviews with commercial policy

Browse Source
This commit is contained in:
Wilson Freitas
2026-08-16 09:41:28 -03:00
parent 73a4bc4127
commit 6f79dbc83d
3 changed files with 52 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/bprr/SKILL.md
+21 -3
View File
@@ -41,7 +41,8 @@ commit never applies to another.
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.
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
@@ -56,7 +57,16 @@ For each added entry, check:
- `https://` URLs.
- Exact optional `[GitHub](https://github.com/owner/repo)` format.
- Correct category section.
- Commercial placement under `Commercial & Proprietary Services`.
- 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
hosted service with only a thin repository as repository-less for this 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.
@@ -64,6 +74,12 @@ For each added entry, check:
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:
- `REJECT` paid-only proprietary submissions without substantive public source.
- Use `NEEDS CHANGES` for correctable disclosure, wording, placement, URL, or documentation
problems.
## Summary Output
Present a table:
@@ -79,7 +95,9 @@ Use the entry count in `Entries`. Use `PASS`, `FAIL`, `PENDING`, `UNVERIFIED`, o
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.
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:
.agents/skills/sprr/SKILL.md
+17 -5
View File
@@ -48,8 +48,9 @@ queued or pending attempt supersedes an older successful attempt for the same SH
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.
commercial free-tier eligibility or transparency, URL tracking, cross-PR uniqueness, or multi-
project relatedness. CI cannot establish any of these manual criteria. Search open PRs and PRs
closed within the last 365 days for duplicate names and URLs.
## Validation Checklist
@@ -65,7 +66,16 @@ For every added entry:
- 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`.
- Distinguish repositories containing substantive implementation from thin SDK, integration,
examples, generated-data, or marketing repositories.
- Hosted proprietary products without substantive public source are 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
hosted service with only a thin repository as repository-less for this 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.
- Project name and URLs are not duplicates of existing README entries.
- Any verifiable GitHub repository mentioned as the main URL or exact `[GitHub](...)` suffix
is a strong positive relevance signal.
@@ -79,8 +89,10 @@ For every added entry:
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.
- `NEEDS CHANGES`: fixable format, disclosure, wording, placement, URL, or documentation issue.
- `REJECT`: paid-only proprietary submission without substantive public source, duplicate,
unrelated multi-project PR, empty PR description, archived/abandoned project, or other hard
rejection.
## Output Shape
AGENTS.md
+14 -6
View File
@@ -64,10 +64,14 @@ Rules:
- Each tag must use its own backtick pair, for example `` `Python` `C++` `MCP` ``.
- Descriptions must end with a period before the optional `[GitHub](...)` link.
- URLs in new entries must use `https://`.
- A valid GitHub repository used as the main URL or exact `[GitHub](...)` suffix is a strong
positive relevance signal. Review its activity and documentation rather than treating
non-language tags as format errors.
- Commercial/proprietary projects belong in `## Commercial & Proprietary Services`.
- A valid GitHub repository used as the main URL or exact `[GitHub](...)` suffix is preferred
and is a strong positive relevance signal, but it is not universally required. Functional-
section placement requires a repository containing substantive implementation; a thin SDK,
integration, examples, generated-data, or marketing repository does not qualify.
- Hosted commercial/proprietary products without substantive public source belong in
`## Commercial & Proprietary Services`, even when a thin repository exists. Repository-less
services qualify only under the permanent free tier and transparency rules in
`CONTRIBUTING.md`.
- Backtick tags are optional only for commercial services and other metadata-free
sections such as `Related Lists`.
- Use `CONTRIBUTING.md` as the user-facing source for contribution rules.
@@ -89,8 +93,12 @@ Review requirements:
4. Always ask the user before commenting, labeling, closing, or merging.
5. Check section placement, duplicates in `README.md`, entry format, URL format,
and project activity/documentation. Give substantial positive weight to a verifiable
GitHub repository mentioned as either the main URL or exact suffix.
6. Use the `reviewed` label only after the user approves a review comment.
GitHub repository mentioned as either the main URL or exact suffix, while confirming that
functional-section repositories contain substantive implementation.
6. Manually assess commercial entries for free-tier usefulness, payment information,
public pricing and limits, public documentation/methodology/examples, stable non-tracking
URLs, concise factual description tone, and repository substance.
7. Use the `reviewed` label only after the user approves a review comment.
## GitHub MCP Tools