Evaluate open source package health before adoption. Use when the user says "should I use this package", "is lodash well-maintained", "endor score express", "package health", "compare lodash vs underscore", "evaluate this dependency", or wants activity, popularity, security, and quality scores. Do NOT use for checking known CVEs in a package (/endor-check) or scanning the whole repo (/endor-scan).
76
93%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that hits all the marks. It provides specific capabilities, abundant natural trigger terms, explicit 'Use when' and 'Do NOT use' clauses, and clear boundaries against related skills. The inclusion of concrete example phrases and negative scope boundaries makes this particularly effective for skill selection.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple concrete actions: evaluate package health, provide activity/popularity/security/quality scores, compare packages. Also explicitly distinguishes what it does NOT do (checking CVEs, scanning repos). | 3 / 3 |
Completeness | Clearly answers both 'what' (evaluate open source package health, provide activity/popularity/security/quality scores) and 'when' (explicit 'Use when...' clause with multiple trigger phrases). Also includes negative boundaries with 'Do NOT use for' guidance. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural user phrases: 'should I use this package', 'is lodash well-maintained', 'package health', 'compare lodash vs underscore', 'evaluate this dependency'. These are realistic phrases users would actually say. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with clear niche (open source package health evaluation) and explicit negative boundaries distinguishing it from related skills (/endor-check for CVEs, /endor-scan for repo scanning). Very unlikely to conflict. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
87%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-crafted skill that provides concrete, actionable guidance for evaluating package health. It efficiently covers multiple scenarios (single package, version comparison, package comparison) with specific tool calls and CLI commands. The main weakness is the lack of explicit validation between dependent steps—particularly verifying the package UUID retrieval before using it in subsequent queries.
Suggestions
Add a validation checkpoint between Step 1/2 confirming the package UUID was retrieved before querying the scorecard metric, with a fallback action if it's missing.
Add a brief note about what to do when Step 1 (vulnerabilities) succeeds but Step 2 (metrics) fails or vice versa, so Claude knows how to present partial results.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It doesn't explain what package health means or how ecosystems work. Every section serves a purpose—input parsing, workflow steps, score categories, error handling—without padding or unnecessary context. | 3 / 3 |
Actionability | Provides concrete MCP tool names with exact parameters, executable CLI commands with proper flags, specific filter syntax, and clear recommendation thresholds. The guidance is copy-paste ready with real tool/API calls. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (1-5) with logical progression from data gathering to presentation. However, there are no explicit validation checkpoints—no verification that the package UUID was successfully retrieved before using it in Step 2's scorecard query, and no feedback loop for handling partial data (e.g., metrics available but vulnerabilities check failed). | 2 / 3 |
Progressive Disclosure | Content is well-structured with clear sections (Input Parsing, Workflow steps, Next Steps, Error Handling). References to related skills (/endor-check, /endor-upgrade-impact, /endor-scan) and a data sources file (references/data-sources.md) are clearly signaled and one level deep. The skill is appropriately sized for a single file. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
b958adc
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.