スキル一覧に戻る

audit-dependency-versions

pjt222
更新日 2 days ago
7 閲覧
17
2
17
GitHubで表示
その他ai

について

このスキルは、プロジェクトの依存関係を監査し、古いバージョン、セキュリティ脆弱性、互換性の問題をチェックします。ロックファイルを分析し、アップグレードの経路を計画し、破壊的変更を評価します。リリース前、メンテナンス期間中、セキュリティ勧告後、あるいはプロジェクトを継承する際に使用し、依存関係の健全性を確保します。

クイックインストール

Claude Code

推奨
メイン
npx skills add pjt222/agent-almanac -a claude-code
プラグインコマンド代替
/plugin add https://github.com/pjt222/agent-almanac
Git クローン代替
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/audit-dependency-versions

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

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:

LevelDefinitionAction
CurrentAt latest version or within latest patchNo action needed
Patch behindSame major.minor, older patchLow priority upgrade, usually safe
Minor behindSame major, older minorMedium priority, review changelog for new features
Major behindOlder major versionHigh priority, likely breaking changes in upgrade
EOL / ArchivedPackage no longer maintainedCritical: 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 → Rscript may be cross-platform wrapper. Check which 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 upgrades
  • manage-renv-dependencies — R-specific dep mgmt w/ renv
  • security-audit-codebase — broader security audit inc. dep vulns
  • manage-changelog — doc dep upgrades in changelog
  • plan-release-cycle — schedule dep upgrades in release timeline

GitHub リポジトリ

pjt222/agent-almanac
パス: i18n/caveman-ultra/skills/audit-dependency-versions
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

関連スキル

llamaguard

その他

LlamaGuardは、暴力やヘイトスピーチなど6つの安全性カテゴリーにおいて、LLMの入力と出力をモデレートするMetaの70-80億パラメータモデルです。94〜95%の精度を提供し、vLLM、Hugging Face、Amazon SageMakerを使用してデプロイ可能です。このスキルを使用して、AIアプリケーションにコンテンツフィルタリングと安全策を簡単に統合できます。

スキルを見る

cost-optimization

その他

このClaudeスキルは、リソースの適正サイジング、タグ付け戦略、支出分析を通じて、開発者がクラウドコストを最適化することを支援します。AWS、Azure、GCPにわたるクラウド支出の削減とコストガバナンスの実施のためのフレームワークを提供します。インフラコストの分析、リソースの適正サイジング、または予算制約への対応が必要な際にご利用ください。

スキルを見る

quantizing-models-bitsandbytes

その他

このスキルは、bitsandbytesを使用してLLMを8ビットまたは4ビット精度に量子化し、精度の低下を最小限に抑えつつ50〜75%のメモリ削減を実現します。限られたGPUメモリでより大規模なモデルを実行したり、推論を高速化するのに理想的で、INT8、NF4、FP4などのフォーマットをサポートしています。HuggingFace Transformersと統合され、QLoRAトレーニングや8ビットオプティマイザーを可能にします。

スキルを見る

dispatching-parallel-agents

その他

このClaudeスキルは、複数のエージェントを配備し、3つ以上の独立した問題を並行して調査・修正します。共有状態や依存関係がなく解決可能な、無関係な障害が発生するシナリオ向けに設計されています。中核となる機能は並列問題解決であり、効率を最大化するために独立した問題領域ごとに1つのエージェントを割り当てます。

スキルを見る