diff --git a/.agents/skills/bprr/SKILL.md b/.agents/skills/bprr/SKILL.md index 1df2738..8c50a46 100644 --- a/.agents/skills/bprr/SKILL.md +++ b/.agents/skills/bprr/SKILL.md @@ -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: diff --git a/.agents/skills/sprr/SKILL.md b/.agents/skills/sprr/SKILL.md index df97ede..a112c7d 100644 --- a/.agents/skills/sprr/SKILL.md +++ b/.agents/skills/sprr/SKILL.md @@ -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 diff --git a/AGENTS.md b/AGENTS.md index f64fce6..4f5e1cb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -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