Audit and manage dependencies across multi-language projects. Identifies vulnerabilities, license conflicts, transitive dependency risks, and safe-upgrade paths. Use when auditing third-party packages before release, investigating a CVE, planning a major version bump, or running a license-compliance review. Examples: 'audit our npm dependencies', 'do we have GPL contamination', 'plan the upgrade t
cd ~/.claude/skills
git clone https://github.com/alirezarezvani/claude-skills.git claude-skills mkdir -p ~/.claude/skills/dependency-auditor
curl -fsSL https://raw.githubusercontent.com/alirezarezvani/claude-skills/HEAD/.gemini/skills/dependency-auditor/SKILL.md \
-o ~/.claude/skills/dependency-auditor/SKILL.md Skill Type: POWERFUL · Category: Engineering · Domain: Dependency Management & Security
Offline, deterministic dependency auditing across 8+ package ecosystems. The three scripts are pattern-matchers over manifests/lockfiles — they do not call live advisory APIs; pair their findings with npm audit / pip-audit / cargo audit for current CVE coverage.
# 1. Scan for vulnerabilities (built-in offline CVE pattern set; exit non-zero on high severity)
python3 scripts/dep_scanner.py /path/to/project --format json --fail-on-high -o scan.json
# 2. Check license compliance and conflicts
python3 scripts/license_checker.py /path/to/project --policy strict --format json -o licenses.json
# 3. Plan upgrades from the scanner's inventory
python3 scripts/upgrade_planner.py scan.json --risk-threshold medium --timeline 90 --format json -o plan.json
Consume the outputs: scan.json findings drive which packages to pin/patch now; licenses.json conflicts go to the user as a legal-risk list; plan.json orders upgrades by risk with rollback notes. --quick-scan skips transitive deps; --security-only limits the plan to security fixes.
Verification loop: after applying upgrades, re-run step 1 and assert 0 high-severity findings before closing the audit.
| Language | Manifests parsed |
|---|---|
| JavaScript/Node | package.json, package-lock.json, yarn.lock |
| Python | requirements.txt, pyproject.toml, Pipfile.lock, poetry.lock |
| Go | go.mod, go.sum |
| Rust | Cargo.toml, Cargo.lock |
| Ruby | Gemfile, Gemfile.lock |
| Java | pom.xml, gradle.lockfile |
| PHP | composer.json, composer.lock |
| C#/.NET | packages.config, project.assets.json |
The checker analyzes license inheritance through dependency chains and emits conflict pairs with remediation suggestions.
| Risk | Update type | Handling |
|---|---|---|
| Low | Patch, security fixes | Apply immediately |
| Medium | Minor with new features | Batch into scheduled update |
| High | Major version, API changes | Dedicated migration task + tests |
| Critical | Known breaking changes | Planned migration with rollback procedure |
Prioritization: security patches > bug fixes > feature updates > major rewrites; deprecated features get immediate attention.
scripts/dep_scanner.py — multi-format parser; built-in offline vulnerability pattern set (~16 CVE patterns — a smoke layer, not a replacement for live advisories); transitive resolution from lockfiles; JSON + text output.scripts/license_checker.py — license detection from package metadata; compatibility matrix across 20+ license types; --policy permissive|strict; conflict detection with remediation.scripts/upgrade_planner.py — semver-based breaking-change prediction; risk-ordered migration plan with testing checklist and timeline estimation.Sample fixtures: test-project/ and test-inventory.json in this folder; expected shapes in expected_outputs/.
# Security gate in CI
python3 scripts/dep_scanner.py . --format json --fail-on-high
python3 scripts/license_checker.py . --policy strict --format json
See README.md for detailed usage and references/ for the vulnerability/license knowledge bases.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions