How we score a skill
Methodology v1. Two layers: red lines that veto, then points that rank. No evidence, no points — and popularity is never evidence.
Layer 1 — security red lines (veto)
A skill is flagged and never recommended, whatever its score, if it does any of these:
- Steals credentials or sends them to a third party
- Downloads remote code and executes it without verification
- Exfiltrates data to unrelated third parties
- Hides instructions (including invisible Unicode or second-stage files)
- Ships obfuscated payloads
- Demands privileges it does not need
A missing or invalid SKILL.md, a name that doesn't match its folder, or no licence also bars a skill from recommendation. Our scan is a screening, not a security certification.
Layer 2 — 100 points, six dimensions
Standard-task completion, margin over the no-skill baseline, self-verification in the output, failure behaviour.
Clear steps, defined inputs/outputs, built-in checks, stop conditions, failure recovery.
Does the description say what it does, when to use it — and when NOT to? Tested with five fixed prompts.
Leanness (guideline: SKILL.md body under 500 lines), progressive disclosure, organisation, no padding.
Examples and templates, script quality where scripts exist, stated dependencies, concrete instructions.
Least privilege, declared tool scope, confirmation before sensitive actions. Real risk is handled by the red lines below, so this stays small.
Install counts and GitHub stars appear on review pages as background only. They never add a single point.
Grades
| 90–100 | S | First choice |
| 80–89 | A | Recommended |
| 65–79 | B | Usable, with known gaps |
| 50–64 | C | Caution |
| <50 | D | Not recommended |
The test protocol
- Collect metadata (background only — never scored).
- Static read of SKILL.md and every bundled file.
- Security screen against the red-line list.
- Trigger tests: five fixed prompts — three that should fire it, two lookalikes that should not.
- Standard-task A/B run: same brief, with and without the skill. Prompts and outputs are kept as evidence.
- Compatibility spot-check across Claude Code, Cursor and Codex.
- Score and publish, with the test environment and date on the page.
Re-tests are triggered by a major version change, 90 days elapsed, or a user report.