docs: investigate commercial services behind thin repositories

.agents/skills/sprr/SKILL.md

@@ -94,13 +94,50 @@ For every added entry:
   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
+- A verifiable GitHub repository containing substantive implementation, mentioned as the main URL
-  is a strong positive relevance signal.
+  or exact `[GitHub](...)` suffix, is a strong positive relevance signal. Repository existence
+  alone does not establish commercial eligibility or functional-section placement.
 - 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.
 
+## Repository Substance and Linked Services
+
+For every added entry with a repository, investigate what the public source actually provides:
+
+1. Inspect representative implementation files behind the advertised functionality. A README,
+   license, tests, file count, or stars alone do not establish substance.
+2. Trace whether core functionality is implemented publicly or depends on a proprietary service.
+   Identify code that only calls a vendor API, integrates a service, downloads generated output,
+   or provides examples or marketing. External dependencies alone do not make a project thin;
+   assess where the advertised functionality is implemented.
+3. Follow linked service websites, public documentation, and pricing/free-tier pages. Establish
+   the repository's relationship to the service and verify eligibility under `CONTRIBUTING.md`,
+   including useful permanent free access without payment information.
+4. Report concrete evidence: representative source-file links, API dependencies, and relevant
+   service/pricing/documentation links. State unavailable or inconclusive evidence explicitly.
+   Small size, few stars, or recent creation alone do not imply poor quality or commercial status.
+
+When a repository mainly supports a qualifying commercial service, place the entry in
+`Commercial & Proprietary Services`. Use the service name and stable service website as the main
+link, and retain the repository only as the exact `[GitHub](...)` suffix:
+
+```markdown
+- [Service Name](https://service.example) - Factual service description with relevant free-tier limits. [GitHub](https://github.com/owner/client)
+```
+
+Describe the service, not merely its SDK. An open-source client license does not make the hosted
+service open source. Substantive public implementation can qualify for a functional section even
+when its maintainers also sell a hosted service.
+
+- Qualifying service with incorrect placement or a thin repository as its main link:
+  `NEEDS CHANGES`, with a proposed corrected README entry.
+- Confirmed paid-only, trial-only, demo-only, waitlist-only, or otherwise non-qualifying free
+  access: `REJECT`; moving the entry does not fix eligibility.
+- Insufficient evidence of repository substance or service eligibility: `NEEDS CHANGES`, naming
+  the missing evidence without claiming that the service qualifies.
+
 ## Verdicts
 
 Use these verdicts:

.claude/skills/sprr/SKILL.md

@@ -51,6 +51,10 @@ relevance, semantic section suitability, commercial classification, repository q
 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:
@@ -67,8 +71,8 @@ For every added entry:
 - 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.
-- Any verifiable GitHub repository mentioned as the main URL or exact `[GitHub](...)` suffix
+- A verifiable GitHub repository containing substantive implementation, mentioned as the main URL
-  is a strong positive relevance signal.
+  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.

CONTRIBUTING.md

@@ -58,7 +58,8 @@ Link to the PyPI package page. If the project has a GitHub repo, append it after
 ### General rules
 
 - Use `https://` URLs only.
-- GitHub repository URLs are strongly preferred and are a major positive relevance signal.
+- GitHub repositories containing substantive implementation are strongly preferred and are a
+  major positive relevance signal.
   Projects with a verifiable GitHub repository are easier to evaluate for source availability,
   documentation, activity, maintenance, and community adoption, and they receive automated
   tracking of stars, activity, and archive status on
@@ -66,8 +67,9 @@ Link to the PyPI package page. If the project has a GitHub repo, append it after
 - A public GitHub repository containing the substantive implementation is preferred. Use it
   as the main URL, or append the exact `[GitHub](https://github.com/owner/repo)` suffix when
   the project has a separate website. Repository-less commercial services are considered only
-  under the eligibility rules below. A valid GitHub repository mentioned in either place
+  under the eligibility rules below. A substantive GitHub repository mentioned in either place
-  receives the same relevance consideration.
+  receives the same relevance consideration; repository existence alone does not establish
+  commercial eligibility or functional-section placement.
 - Use short, meaningful tags. Each concept must have its own backtick pair; for example,
   use `` `Python` `C++` `` rather than `` `Python, C++` ``.
 - The description must end with a period (before the `[GitHub]` link, if present).
@@ -100,13 +102,22 @@ integration, examples, generated-data, or marketing repository—are repository-
 eligibility check. They must publish pricing and free-tier limits, as well as public documentation,
 methodology, or usage examples. Their entries must use a stable HTTPS URL without affiliate or
 tracking parameters, have a concise, factual, non-promotional description, and be placed in the
-**Commercial & Proprietary Services** section. Backtick tags are optional in that section. For
+**Commercial & Proprietary Services** section. Use the service name and website as the main
-example:
+link; when a supporting repository exists, append it as the exact `[GitHub](...)` suffix.
+Describe the service and relevant free-tier limits, not merely its SDK. Backtick tags are
+optional in that section. For example:
 
 ```markdown
 - [Project Name](https://project.example) - Concise factual description ending with a period.
+- [Service Name](https://service.example) - Factual service description with relevant free-tier limits. [GitHub](https://github.com/owner/client)
 ```
 
+Reviewers inspect representative source files to establish whether advertised functionality is
+implemented publicly or merely accessed through a proprietary service, and follow linked service
+documentation and pricing pages. Small size, few stars, or recent creation alone do not make a
+repository thin. An open-source SDK license does not make the service open source; substantive
+public implementation may qualify for a functional section even with a paid hosted version.
+
 Only a repository containing substantive implementation supports placement in a functional
 section. Commercial submissions without a qualifying permanent free tier—including paid-only,
 trial-only, demo-only, and waitlist-only offerings—are `REJECT`. Reserve `NEEDS CHANGES` for