docs: align PR reviews with commercial policy

.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:
 

.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