How we review

1. Clone the real repo. We read the actual SKILL.md, not the marketing README alone.
2. Sizes are git sizes. File sizes we quote are the bytes git stores at the commit we read (no Windows line-ending conversion), so git cat-file -s or the GitHub API gives the same number.
3. Inventory what runs. Every script, shell file and allowed-tools entry in the skill folder gets listed. Instructions-only skills score safer by default.
4. Check license, author, recency. License file in repo (and in-folder where present), author from frontmatter, repo last-commit date — labelled as a repo date, never dressed up as a skill release date.
5. Verify install commands against the repo README or SKILL.md. If we cannot verify, we say so.
6. Copy claims need measurement. We only say 'Copy' when we diffed the files ourselves and can quote similarity. Same name alone is not evidence — we exonerated a same-named marketing pack that way (5% similarity).
7. Install counts are distribution, not quality. Where we quote skills.sh figures, we date them and treat them as popularity, not proof.

Verdicts

Install Install with caution Skip Redistributed copy — install the original

What we do not do: execute installers, run third-party scripts against real accounts, or claim hands-on output quality we did not test. Any unknown is labelled unknown.

Rating scale in search results

Each verdict page carries schema.org Review data so search engines can read it. The scale is 1 to 3 and maps one-to-one to our verdicts: Install = 3, Install with caution = 2, Skip and Redistributed copy — install the original = 1. It is not a score of output quality.

Independence

Skill authors can ask for a fast-track review. Paying moves the date, never the verdict: paid reviews follow this same method, can end in Skip, are labelled on the page, and never buy a place in a best-of list.