audit-dependency-versions
Über
Diese Skill überprüft die Abhängigkeiten eines Projekts auf veraltete Versionen, Sicherheitslücken und Kompatibilitätsprobleme. Sie analysiert Lock-Dateien, plant Upgrade-Pfade und bewertet Breaking Changes. Nutzen Sie sie vor Releases, während der Wartung, nach Sicherheitshinweisen oder bei der Übernahme eines Projekts, um die Integrität der Abhängigkeiten sicherzustellen.
Schnellinstallation
Claude Code
Empfohlennpx 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-versionsKopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren
Dokumentation
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
GitHub Repository
Verwandte Skills
llamaguard
AndereLlamaGuard ist Metas 7-8B-Parameter-Modell zur Moderation von LLM-Eingaben und -Ausgaben in sechs Sicherheitskategorien wie Gewalt und Hassrede. Es bietet eine Genauigkeit von 94-95 % und kann mit vLLM, Hugging Face oder Amazon SageMaker eingesetzt werden. Nutzen Sie diese Skill, um Inhaltsfilterung und Sicherheitsguardrails einfach in Ihre KI-Anwendungen zu integrieren.
cost-optimization
AndereDiese Claude Skill unterstützt Entwickler bei der Optimierung von Cloud-Kosten durch Ressourcen-Dimensionierung, Tagging-Strategien und Ausgabenanalysen. Sie bietet einen Rahmen zur Senkung von Cloud-Ausgaben und zur Implementierung von Kosten-Governance für AWS, Azure und GCP. Nutzen Sie sie, wenn Sie Infrastrukturkosten analysieren, Ressourcen richtig dimensionieren oder Budgetvorgaben einhalten müssen.
quantizing-models-bitsandbytes
AndereDiese Fähigkeit quantisiert LLMs auf 8-Bit- oder 4-Bit-Präzision mittels bitsandbytes und erreicht dabei eine Speicherreduzierung von 50–75 % bei minimalem Genauigkeitsverlust. Sie ist ideal für den Betrieb größerer Modelle mit begrenztem GPU-Speicher oder zur Beschleunigung von Inferenzvorgängen und unterstützt Formate wie INT8, NF4 und FP4. Die Fähigkeit integriert sich in HuggingFace Transformers und ermöglicht QLoRA-Training sowie 8-Bit-Optimierer.
dispatching-parallel-agents
AndereDiese Claude-Fähigkeit verteilt mehrere Agenten, um drei oder mehr unabhängige Probleme gleichzeitig zu untersuchen und zu beheben. Sie ist für Szenarien konzipiert, die unabhängige Fehler umfassen, die ohne gemeinsamen Zustand oder Abhängigkeiten gelöst werden können. Die Kernfähigkeit ist die parallele Problemlösung, bei der pro unabhängigem Problembereich ein Agent zugewiesen wird, um die Effizienz zu maximieren.
