Acerca de
Esta habilidad audita las dependencias de un proyecto en busca de versiones obsoletas, vulnerabilidades de seguridad y problemas de compatibilidad. Analiza archivos de bloqueo, planifica rutas de actualización y evalúa cambios disruptivos. Úsela antes de los lanzamientos, durante el mantenimiento, después de avisos de seguridad o al heredar un proyecto para garantizar la salud de las dependencias.
Instalación rápida
Claude Code
Recomendadonpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/audit-dependency-versionsCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Audit Dependency Versions
Audit deps → ver staleness, known security vulns, compat issues. Inventory all deps from lock files → check latest → classify staleness → flag security → prioritized upgrade report.
Use When
- Pre-release → deps current + secure
- Periodic maint (monthly/quarterly)
- Security advisory hits project dep
- Lang ver upgrade (R 4.4 → 4.5)
- Pre-submit CRAN/npm/crates.io
- Inheriting project → dep health
In
- Required: Project root w/ dep/lock files
- Optional: Ecosystem (R, Node.js, Python, Rust)
- Optional: Security-only mode (skip staleness → CVEs)
- Optional: Allowlist deps to skip
- Optional: Compat target date (e.g., "R 4.4.x")
Do
Step 1: Inventory All Dependencies
Parse dep files → complete inventory.
R packages:
# Direct dependencies from DESCRIPTION
grep -A 100 "^Imports:" DESCRIPTION | grep -B 100 "^[A-Z]" | head -50
grep -A 100 "^Suggests:" DESCRIPTION | grep -B 100 "^[A-Z]" | head -50
# Pinned versions from renv.lock
cat renv.lock | grep -A 3 '"Package"'
Node.js:
# Direct dependencies
cat package.json | grep -A 100 '"dependencies"' | grep -B 100 "}"
cat package.json | grep -A 100 '"devDependencies"' | grep -B 100 "}"
# Pinned versions from lock file
cat package-lock.json | grep '"version"' | head -20
Python:
# From requirements or pyproject
cat requirements.txt
cat pyproject.toml | grep -A 50 "dependencies"
# Pinned versions
cat requirements.lock 2>/dev/null || pip freeze
Rust:
# From Cargo.toml
grep -A 50 "\[dependencies\]" Cargo.toml
# Pinned versions
cat Cargo.lock | grep -A 2 "name ="
Inventory table:
| Package | Pinned Version | Type | Ecosystem |
|---|---|---|---|
| dplyr | 1.1.4 | Import | R |
| testthat | 3.2.1 | Suggests | R |
| express | 4.18.2 | dependency | Node.js |
| pytest | 8.0.0 | dev | Python |
→ Complete inventory direct + (optional) transitive deps w/ pinned vers.
If err: Lock files missing → repro issues. Note as finding → inventory from manifest w/ declared constraints.
Step 2: Check Latest Available Versions
Latest ver per dep.
R:
# Check available versions
available.packages()[c("dplyr", "testthat"), "Version"]
# Or via CLI
Rscript -e 'cat(available.packages()["dplyr", "Version"])'
Node.js:
# Check outdated packages
npm outdated --json
# Or individual package
npm view express version
Python:
# Check outdated
pip list --outdated --format=json
# Or individual
pip index versions requests 2>/dev/null
Rust:
# Check outdated
cargo outdated
# Or individual
cargo search serde --limit 1
Update inventory:
| Package | Pinned | Latest | Gap |
|---|---|---|---|
| dplyr | 1.1.4 | 1.1.6 | patch |
| ggplot2 | 3.4.0 | 3.5.1 | minor |
| Rcpp | 1.0.10 | 1.0.14 | patch |
| shiny | 1.7.4 | 1.9.1 | minor |
→ Latest ver per dep w/ gap magnitude (patch/minor/major).
If err: Registry unreachable → mark "unable to check", continue. Don't block full audit on one registry.
Step 3: Classify Staleness
Staleness level per dep:
| Level | Definition | Action |
|---|---|---|
| Current | At latest version or within latest patch | No action needed |
| Patch behind | Same major.minor, older patch | Low priority upgrade, usually safe |
| Minor behind | Same major, older minor | Medium priority, review changelog for new features |
| Major behind | Older major version | High priority, likely breaking changes in upgrade |
| EOL / Archived | Package no longer maintained | Critical: find replacement or fork |
Summary:
### Staleness Summary
- **Current**: 12 packages (48%)
- **Patch behind**: 8 packages (32%)
- **Minor behind**: 3 packages (12%)
- **Major behind**: 1 package (4%)
- **EOL/Archived**: 1 package (4%)
**Overall health**: AMBER (major-behind and EOL packages present)
Color coding:
- GREEN: All current/patch-behind
- AMBER: Any minor-behind or one major-behind
- RED: Multiple major-behind or any EOL
→ Every dep classified + overall health rating.
If err: Ver comparison ambiguous (non-SemVer, date-based) → classify conservatively "minor behind" + note non-standard scheme.
Step 4: Check for Security Vulnerabilities
Run ecosystem-specific audit tools:
R:
# No built-in audit tool; check manually
# Cross-reference with https://www.r-project.org/security.html
# Check GitHub advisories for each package
Node.js:
# Built-in audit
npm audit --json
# Severity levels: info, low, moderate, high, critical
npm audit --audit-level=moderate
Python:
# Using pip-audit
pip-audit --format=json
# Or safety
safety check --json
Rust:
# Using cargo-audit
cargo audit --json
Document findings:
### Security Findings
| Package | Version | CVE | Severity | Fixed In | Description |
|---|---|---|---|---|---|
| express | 4.18.2 | CVE-2024-XXXX | High | 4.19.0 | Path traversal in static file serving |
| lodash | 4.17.20 | CVE-2021-23337 | Critical | 4.17.21 | Command injection via template |
**Security status**: RED (1 critical, 1 high)
→ Vulns w/ CVE, severity, affected ver, fix ver.
If err: No audit tool → GitHub Security Advisories manual search per dep. Best-effort without tooling.
Step 5: Plan Upgrade Path
Prioritize by risk + impact:
### Upgrade Plan
#### Priority 1: Security Fixes (do immediately)
| Package | Current | Target | Risk | Notes |
|---|---|---|---|---|
| lodash | 4.17.20 | 4.17.21 | Low (patch) | Fixes CVE-2021-23337 |
| express | 4.18.2 | 4.19.0 | Low (minor) | Fixes CVE-2024-XXXX |
#### Priority 2: EOL Replacements (plan within 1 month)
| Package | Current | Replacement | Migration Effort |
|---|---|---|---|
| request | 2.88.2 | node-fetch 3.x | Medium (API change) |
#### Priority 3: Major Version Upgrades (plan for next release cycle)
| Package | Current | Target | Breaking Changes |
|---|---|---|---|
| webpack | 4.46.0 | 5.90.0 | Config format, plugin API |
#### Priority 4: Minor/Patch Updates (batch in maintenance window)
| Package | Current | Target | Notes |
|---|---|---|---|
| dplyr | 1.1.4 | 1.1.6 | Patch fixes only |
| ggplot2 | 3.4.0 | 3.5.1 | New geom functions added |
Major upgrades → note breaking changes from dep changelog.
→ Prioritized plan: security → EOL → major → minor/patch batches.
If err: Dep abandoned, no fork → document risk. Recommend: (1) vendor current, (2) alt pkg, (3) accept + monitor.
Step 6: Document Compatibility Risks
Per planned upgrade:
### Compatibility Assessment
#### express 4.18.2 -> 4.19.0
- **API changes**: None (patch-level fix)
- **Node.js requirement**: Same (>=14)
- **Test impact**: Run full test suite; expect zero failures
- **Confidence**: HIGH
#### webpack 4.46.0 -> 5.90.0
- **API changes**: Config file format changed, several plugins removed
- **Node.js requirement**: >=10.13 (unchanged)
- **Test impact**: Build configuration must be rewritten; all tests need re-run
- **Confidence**: LOW (requires dedicated migration effort)
- **Migration guide**: https://webpack.js.org/migrate/5/
Write report → DEPENDENCY-AUDIT.md or DEPENDENCY-AUDIT-2026-02-17.md.
→ Compat risks documented per significant upgrade. Report complete.
If err: Can't assess without testing → branch-based upgrade: branch, apply, test, evaluate, merge.
Check
- All direct deps inventoried from lock/manifest
- Latest ver checked per dep
- Staleness level assigned (current/patch/minor/major/EOL)
- Overall health rating (GREEN/AMBER/RED)
- Security audit w/ ecosystem tooling
- All CVEs documented (severity, affected, fix)
- Upgrade plan prioritized: security > EOL > major > minor/patch
- Compat risks per major upgrade
- Report → DEPENDENCY-AUDIT.md
- No "unable to check" w/o reason
Traps
- Ignore transitive deps: 10 direct → 200 transitive. Vulns hide transitive. Use
npm ls/renv::dependencies(). - Upgrade all at once: Batch upgrade → can't identify regression source. Upgrade logical groups (security first, majors individually, minors/patches batched).
- "Outdated" ≠ "insecure": Major behind + no CVE < current + critical vuln. Security > freshness.
- Skip changelogs: Blind major upgrade → breaking changes in dep → breaking changes in your project.
- Audit fatigue: Audits w/o action → worthless. Policy: security → 1 sprint, EOL → 1 quarter.
- Missing lock files: No lock → non-repro builds. Finding itself critical.
- Wrong R binary on hybrid: WSL/Docker →
Rscriptmay be cross-platform wrapper. Checkwhich Rscript && Rscript --version. Prefer native (e.g.,/usr/local/bin/Rscript). See Setting Up Your Environment.
→
apply-semantic-versioning— ver bumps may trigger from dep upgradesmanage-renv-dependencies— R-specific dep mgmt w/ renvsecurity-audit-codebase— broader security audit inc. dep vulnsmanage-changelog— doc dep upgrades in changelogplan-release-cycle— schedule dep upgrades in release timeline
Repositorio GitHub
Frequently asked questions
What is the audit-dependency-versions skill?
audit-dependency-versions is a Claude Skill by pjt222. Skills package instructions and resources that Claude loads on demand, so Claude can perform audit-dependency-versions-related tasks without extra prompting.
How do I install audit-dependency-versions?
Use the install commands on this page: add audit-dependency-versions to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does audit-dependency-versions belong to?
audit-dependency-versions is in the Other category, tagged ai.
Is audit-dependency-versions free to use?
Yes. audit-dependency-versions is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
Habilidades relacionadas
LlamaGuard es el modelo de Meta de 7-8B parámetros para moderar las entradas y salidas de LLM en seis categorías de seguridad como violencia y discurso de odio. Ofrece una precisión del 94-95% y puede implementarse usando vLLM, Hugging Face o Amazon SageMaker. Utiliza esta skill para integrar fácilmente filtrado de contenido y barreras de seguridad en tus aplicaciones de IA.
Esta Skill de Claude ayuda a los desarrolladores a optimizar los costes en la nube mediante el ajuste de tamaño de recursos, estrategias de etiquetado y análisis de gastos. Proporciona un marco para reducir los gastos en la nube e implementar una gobernanza de costes en AWS, Azure y GCP. Úsala cuando necesites analizar los costes de infraestructura, ajustar el tamaño de los recursos o cumplir con restricciones presupuestarias.
Esta habilidad de Claude analiza los mercados de apuestas deportivas, incluyendo spreads, over/unders y apuestas de propuestas, mediante el examen de tendencias históricas y estadísticas situacionales para identificar apuestas de valor. Proporciona una salida en markdown estructurado con recomendaciones accionables con fines educativos. Los desarrolladores deben utilizar esto para herramientas de análisis de apuestas deportivas, teniendo en cuenta que está diseñado únicamente para entretenimiento/educación.
Esta habilidad cuantiza LLMs a precisión de 8 o 4 bits utilizando bitsandbytes, logrando una reducción de memoria del 50-75% con pérdida mínima de precisión. Es ideal para ejecutar modelos más grandes en memoria GPU limitada o para acelerar la inferencia, admitiendo formatos como INT8, NF4 y FP4. La habilidad se integra con HuggingFace Transformers y permite entrenamiento QLoRA y optimizadores de 8 bits.
