diff --git a/.agents/skills/sprr/SKILL.md b/.agents/skills/sprr/SKILL.md index 805d49c..5fa6cce 100644 --- a/.agents/skills/sprr/SKILL.md +++ b/.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 - is a strong positive relevance signal. +- A verifiable GitHub repository containing substantive implementation, mentioned as the main URL + 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: diff --git a/.claude/skills/sprr/SKILL.md b/.claude/skills/sprr/SKILL.md index df97ede..85b362b 100644 --- a/.claude/skills/sprr/SKILL.md +++ b/.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 - is a strong positive relevance signal. +- A verifiable GitHub repository containing substantive implementation, mentioned as the main URL + 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. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index be2d8d4..d3364cb 100644 --- a/CONTRIBUTING.md +++ b/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 - receives the same relevance consideration. + under the eligibility rules below. A substantive GitHub repository mentioned in either place + 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 -example: +**Commercial & Proprietary Services** section. Use the service name and website as the main +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