From dependency-evaluator
Evaluate npm or Python packages for build-vs-buy decisions. Use when adding a new dependency, reviewing package.json or requirements.txt changes, pip install, or deciding whether to use a library or implement functionality yourself.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dependency-evaluator:evaluating-dependenciesThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Evaluate whether to **USE**, **EXTRACT**, or **BUILD** before adding any dependency.
Evaluate whether to USE, EXTRACT, or BUILD before adding any dependency.
No new dependency without an evaluation. If you are about to install a new package or add one to package.json / requirements.txt / pyproject.toml, run this evaluation first.
Determine the ecosystem from context:
npm installpip installnpm info <pkg>) and/or PyPI (curl -s https://pypi.org/pypi/<pkg>/json). If both, ask the user which ecosystem they mean.Then follow the ecosystem-specific gathering steps below.
User runs /evaluating-dependencies <package> [function]. The package name is available as $ARGUMENTS[0] and the optional function as $ARGUMENTS[1]. Produce the full report format.
You are about to add a dependency. Run the evaluation silently and produce the condensed 1-line format. If the verdict is BUILD or EXTRACT, pause and present the finding before proceeding.
Run these commands. Parallelize where possible.
npm info <pkg> --json
npm pack <pkg> --dry-run 2>&1
npm info <pkg> dependencies --json
npm view <pkg> dist.unpackedSize
# If package is in node_modules:
npm audit --json
# Otherwise, check advisories from npm info output
Fetch the package entry point to identify its public API:
# Get the main/exports field from npm info output
# Then fetch source to count exports and assess complexity
If the user specified a specific function, find that function's source code:
Count total public exports. Calculate usage ratio: functions needed / total exports.
Extract from the npm info JSON output:
time.modified — last publish datemaintainers — countdist-tags — release activityIf a GitHub repository is linked:
gh api repos/<owner>/<repo> --jq '{stars: .stargazers_count, open_issues: .open_issues_count, pushed_at: .pushed_at}'
npm search <keywords-describing-the-functionality> --json | head -20
curl -s https://pypi.org/pypi/<pkg>/json
Extract from the JSON response: info.version, info.license, info.summary, info.author, info.requires_dist (dependencies), info.project_urls (GitHub link), urls (release files and sizes).
From the PyPI JSON info.requires_dist field — list direct dependencies. For transitive depth:
pip install --dry-run <pkg> 2>&1
Count packages that would be installed.
pip-audit --desc <pkg> 2>&1
# Or check PyPI advisories from the JSON response
# Or: curl -s https://pypi.org/pypi/<pkg>/json | look for yanked releases
Also check for postinstall equivalent: .pth files, setup.py with arbitrary code execution, or suspicious __init__.py imports (relevant to supply chain attacks like litellm).
From PyPI JSON info.project_urls, find the GitHub repo. Then:
__init__.py or main source file to count public exports (__all__ or top-level functions/classes)Count total public API surface. Calculate usage ratio.
From the PyPI JSON response:
urls[0].upload_timereleases object (count recent versions)info.maintainer and info.authorIf GitHub repo is linked:
gh api repos/<owner>/<repo> --jq '{stars: .stargazers_count, open_issues: .open_issues_count, pushed_at: .pushed_at}'
# PyPI has no search API — use GitHub or web search
Search GitHub or the web for <functionality> python library to find focused alternatives.
Focus on packages that are smaller or more focused than the one being evaluated.
Evaluate each signal as leaning toward USE, EXTRACT, or BUILD:
| Signal | → USE | → Neutral | → BUILD |
|---|---|---|---|
| Source complexity | >200 LOC or handles edge cases (timezones, unicode, crypto, browser quirks) | 50-200 LOC, moderate complexity | <50 LOC, straightforward logic |
| Usage ratio | Need >20% of exports | 5-20% | <5% — paying for a lot you won't use |
| Bundle size | <10KB tree-shaken | 10-50KB | >50KB for what you need |
| Transitive deps | 0 dependencies | 1-5 | >5 — hidden risk |
| Security | Clean audit, no CVEs | Minor or resolved advisories | Active CVEs or unpatched vulnerabilities |
| Maintenance | Published <6 months ago, 2+ maintainers | Published 6-12 months ago | >12 months stale, solo maintainer |
| License | MIT, Apache-2.0, ISC | BSD variants | GPL/AGPL in a proprietary project (blocker) |
| Alternatives | No smaller package exists | Comparable alternatives available | A focused package does exactly what you need |
Weight priority (highest first): Source complexity > Usage ratio > Bundle size > Transitive deps > Security > Maintenance > License > Alternatives.
Count the signal leans. Apply weights. Determine one of three verdicts:
License is a hard gate: GPL/AGPL in a proprietary project = BUILD or EXTRACT regardless of other signals.
Active CVEs are a hard gate: Unpatched vulnerabilities = BUILD or find an alternative regardless of other signals.
Use a markdown table with no box-drawing characters. Keep each signal value to ONE line — no wrapping.
## dep-eval: <package>
**You need:** `<function>` — <brief purpose>
| Signal | Value | Lean |
|--------|-------|------|
| Source complexity | <n> LOC, <brief note> | BUILD / USE |
| Usage ratio | <n>/<total> exports (<n>%) | BUILD / USE |
| Bundle size | <size>, <tree-shake status> | BUILD / USE |
| Transitive deps | <count> | BUILD / USE |
| Security | <status> | BUILD / USE |
| Maintenance | <last publish>, <n> maintainers | BUILD / USE |
| License | <license> | BUILD / USE |
| Alternatives | <name or "none"> | BUILD / USE |
### VERDICT: <USE / EXTRACT / BUILD>
<2-3 sentence justification>
### If extracting
<file list, LOC, internal deps>
### If building
<code snippet or description of what to implement>
Rules for the table:
One line, no markdown:
dep-eval: <package> → <VERDICT> (<key reasons, comma-separated>)
Examples:
dep-eval: date-fns → USE (47 LOC, 0 deps, tree-shakes to 5.2KB, MIT, active)
dep-eval: left-pad → BUILD (1 LOC, trivial implementation)
dep-eval: moment → EXTRACT (need formatRelative only, 284KB non-tree-shakeable, consider date-fns instead)
If you notice any of these, flag them prominently in the report:
Both ecosystems:
npm-specific:
install or postinstall scripts that execute arbitrary codePython-specific:
.pth files in the package (code execution on import — litellm attack vector)setup.py with network calls or base64-encoded payloadsreleases object for yanked: true)__init__.py| Excuse | Reality |
|---|---|
| "Everyone uses this package" | Popularity does not mean it's right for YOUR use case |
| "It's only one extra dependency" | Check the transitive tree — it might be 50 |
| "I don't have time to evaluate" | You don't have time to debug a bad dependency later |
| "Tree-shaking will handle it" | Only if the package uses ESM exports. Check. |
| "The package is well-maintained" | Maintained does not mean small or appropriate |
| "Building it would be reinventing the wheel" | 10 lines of code is not a wheel |
npx claudepluginhub apart-tech/plugins --plugin dependency-evaluatorEvaluates dependencies before npm/pip install: assesses bundle size, tree-shaking, maintenance, vulnerabilities, docs, alternatives, and recommends add, reject, or implement internally.
Audits project dependencies for bloat, unused packages, security risks, supply-chain issues, and upgrades by building import graphs and verifying call sites in npm, pip, Cargo, Go, Ruby projects.
Evaluates packages, manages dependencies, and addresses supply chain security for npm/pip/cargo/bundler/Go. Use for auditing packages, reviewing lockfiles, checking vulnerabilities, comparing alternatives, assessing trustworthiness.