| name | version-check |
| description | Check that dependencies are current stable versions and not deprecated.
Use before adding new dependencies or at project setup.
Triggers on "check versions", "verify dependencies", "audit packages".
|
| allowed-tools | Bash, Read, WebFetch |
Version Check Skill
Full documentation: CLAUDE.md
Quick Process
1. Check Package Status
npm view <package> version
npm view <package> deprecated
npm view <package> time.modified
npm view <package> engines
2. Evaluate Criteria
| Criterion | Pass | Fail |
|---|
| Deprecation | Not deprecated | Deprecated |
| Last update | Within 12 months | Over 12 months |
| Node version | Compatible with 22.x | Incompatible |
| Security | No advisories | Has advisories |
3. Run Security Audit
pnpm audit
Actions
If deprecated or outdated:
- Find replacement
- Create GitHub issue to track migration
- Document migration path
See CLAUDE.md for complete version verification protocol.
Anti-rationalization — Dependency choice
| Excuse | Counter |
|---|
| "It's the most-starred package" | Stars correlate with marketing, not maintenance. Check last-commit, open-issues-vs-resolved-rate, recent CVE response time. |
| "Latest version is fine, just install it" | Latest may be a 0.x with breaking changes, or a v2 alpha. Check stability marker — latest tag isn't always stable. |
| "I'll fix any issues that come up" | Cost of npm uninstall + replacement is a multiple of npm view upfront. Ten seconds of due diligence saves an afternoon. |
Red flags
- Dependency added via
npm install <name> without a version-check cite in the PR
- Last commit > 12 months on a non-trivial dep
- Maintenance signal poor (open issues piling, no recent releases) but added anyway
- License incompatible with our MIT (e.g., AGPL, GPLv3 in CLI/library code)
Verification checklist
