agentleFS
optaveoptave/ops-codegraph-tool/.claude/skills/deps-audit/SKILL.md

deps-audit

Skill94 starsChanged 3 months agoApache-2.0View on GitHub

Audit dependencies for vulnerabilities, staleness, unused packages, and license risks — produce a health report with actionable fixes

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

25 rules. About 0 are common, 6 are distinctive, and 19 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 19

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run node --version — must be >= 20

    line 19
  2. Very specific:

    Run npm --version to capture toolchain info

    line 20
  3. Very specific:

    Use [ -n "$STASH_REF" ] (stash created) / [ -z "$STASH_REF" ] (nothing stashed) for all branching.

    line 28
  4. Very specific:

    Run npm audit --json and parse the output:

    line 32
  5. Very specific:

    Check if a fix is available (npm audit fix --dry-run --json)

    line 37
  6. Very specific:

    If AUTO_FIX is set: Run npm audit fix (non-breaking fixes only).

    line 40
  7. Very specific:

    Run npm outdated --json and categorize:

    line 44
  8. Distinctive:

    If major: check the package's CHANGELOG/release notes for breaking changes relevant to our usage

    line 52
  9. Very specific:

    If AUTO_FIX is set: Run npm update to apply semver-compatible updates.

    line 66
  10. Very specific:

    Read dependencies and devDependencies from package.json

    line 72
  11. Distinctive:

    Check licenses for all direct dependencies:

    line 91
  12. Distinctive:

    Only flag non-permissive licenses — don't list every MIT dep

    line 99
  13. Distinctive:

    Check for duplicate versions of the same package in the dependency tree:

    line 103
  14. Very specific:

    Run npm ls --all --json and look for packages that appear multiple times with different versions

    line 105
  15. Distinctive:

    Only flag duplicates that add significant bundle weight (> 100KB) or are security-sensitive (crypto, auth, etc.)

    line 106
  16. Very specific:

    Write a report to generated/deps-audit/DEPS_AUDIT_<date>.md with this structure:

    line 111
  17. Very specific:

    If AUTO_FIX was set:

    line 159
  18. Very specific:

    Run npm test to verify nothing broke

    line 163
  19. Very specific:

    If the pop applies cleanly: a.

    line 165
  20. Very specific:

    If the pop causes conflicts in package.json/package-lock.json: warn the user, leave conflict markers for manual resolution, and instruct: …

    line 174
  21. Very specific:

    If tests pass and STASH_REF is empty: no action needed — the npm changes are good and no stash entry exists to clean up

    line 176
  22. Very specific:

    If tests fail and STASH_REF is non-empty:

    line 177
  23. Very specific:

    If tests fail and STASH_REF is empty:

    line 182
  24. Distinctive:

    Always run tests: after any auto-fix changes

    line 191
  25. Very specific:

    Treat optionalDependencies separately — they're expected to fail on some platforms

    line 193

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/deps-audit — Dependency Health Audit

Audit the project's dependency tree for security vulnerabilities, outdated packages, unused dependencies, and license compliance. Produce a structured report and optionally auto-fix safe updates.

Arguments

  • $ARGUMENTS may contain --fix to auto-apply safe updates (patch/minor only)

Phase 0 — Pre-flight

  1. Confirm we're in the codegraph repo root (check for package.json and package-lock.json)
  2. Run node --version — must be >= 20
  3. Run npm --version to capture toolchain info
  4. Parse $ARGUMENTS — set AUTO_FIX=true if --fix is present
  5. If AUTO_FIX is set: Save the original manifests now, before any npm commands run, so pre-existing unstaged changes are preserved:
    git stash push -m "deps-audit-backup" -- package.json package-lock.json
    STASH_REF=$(git stash list --format='%gd %s' | grep 'deps-audit-backup' | head -1 | awk '{print $1}')
    STASH_REF is non-empty if and only if a stash entry was actually created. Do not use $? — modern git (2.16+) returns 0 even when nothing was stashed. Use [ -n "$STASH_REF" ] (stash created) / [ -z "$STASH_REF" ] (nothing stashed) for all branching. Use $STASH_REF (not stash@{0}) in all later stash drop/pop commands to avoid targeting the wrong entry.

Phase 1 — Security Vulnerabilities

Run npm audit --json and parse the output:

  1. Count vulnerabilities by severity: critical, high, moderate, low, info
  2. For each critical or high vulnerability:
    • Record: package name, severity, CVE/GHSA ID, vulnerable version range, patched version, dependency path (direct vs transitive)
    • Check if a fix is available (npm audit fix --dry-run --json)
  3. Summarize: total vulns, fixable count, breaking-fix count

If AUTO_FIX is set: Run npm audit fix (non-breaking fixes only). Record what changed. Do NOT run npm audit fix --force — breaking changes require manual review.

Phase 2 — Outdated Dependencies

Run npm outdated --json and categorize:

2a. Direct dependencies (dependencies + devDependencies)

For each outdated package, record:

  • Package name
  • Current version → Wanted (semver-compatible) → Latest
  • Whether the update is patch, minor, or major
  • If major: check the package's CHANGELOG/release notes for breaking changes relevant to our usage

2b. Staleness score

Classify each outdated dep:

CategoryDefinition
FreshOn latest or within 1 patch
Aging1+ minor versions behind
Stale1+ major versions behind
AbandonedNo release in 12+ months (check npm registry publish date)

For any package classified as Abandoned, check if there's a maintained fork or alternative.

If AUTO_FIX is set: Run npm update to apply semver-compatible updates. Record what changed.

Phase 3 — Unused Dependencies

Detect dependencies declared in package.json but never imported:

  1. Read dependencies and devDependencies from package.json
  2. For each dependency, search for imports/requires across src/, tests/, scripts/, mcp/, graph/, ast-analysis/, cli.js, index.js:
    • require('<pkg>') or require('<pkg>/...')
    • import ... from '<pkg>' or import '<pkg>'
    • import('<pkg>') (dynamic imports)
  3. Skip known implicit dependencies that don't have direct imports:
    • @anthropic-ai/tokenizer — peer dependency of @anthropic-ai/sdk; the SDK may require it at runtime without an explicit import in our code (verify against package.json before removing)
    • tree-sitter-* and web-tree-sitter — loaded dynamically via WASM
    • @biomejs/biome — used as CLI tool only
    • commit-and-tag-version — used as npm script
    • @optave/codegraph-* — platform-specific optional binaries
    • vitest — test runner, invoked via CLI
    • Anything in optionalDependencies
  4. For each truly unused dep: recommend removal with npm uninstall <pkg>

Important: Some deps are used transitively or via CLI — don't blindly remove. Flag as "likely unused" and let the user decide.

Phase 4 — License Compliance

Check licenses for all direct dependencies:

  1. For each package in dependencies, read its node_modules/<pkg>/package.json → license field
  2. Classify:
    • Permissive (MIT, ISC, BSD-2-Clause, BSD-3-Clause, Apache-2.0, 0BSD, Unlicense): OK
    • Weak copyleft (LGPL-2.1, LGPL-3.0, MPL-2.0): Flag for review
    • Strong copyleft (GPL-2.0, GPL-3.0, AGPL-3.0): Flag as risk — may conflict with MIT license of codegraph
    • Unknown/UNLICENSED/missing: Flag for investigation
  3. Only flag non-permissive licenses — don't list every MIT dep

Phase 5 — Duplicate Packages

Check for duplicate versions of the same package in the dependency tree:

  1. Run npm ls --all --json and look for packages that appear multiple times with different versions
  2. Only flag duplicates that add significant bundle weight (> 100KB) or are security-sensitive (crypto, auth, etc.)
  3. Suggest deduplication: npm dedupe

Phase 6 — Report

Write a report to generated/deps-audit/DEPS_AUDIT_<date>.md with this structure:

# Dependency Audit Report — <date>

## Summary

| Metric | Value |
|--------|-------|
| Total dependencies (direct) | N |
| Total dependencies (transitive) | N |
| Security vulnerabilities | N critical, N high, N moderate, N low |
| Outdated packages | N stale, N aging, N fresh |
| Unused dependencies | N |
| License risks | N |
| Duplicates | N |
| **Health score** | **X/100** |

## Health Score Calculation

- Start at 100
- -20 per critical vuln, -10 per high vuln, -3 per moderate vuln
- -5 per stale (major behind) dep, -2 per aging dep
- -5 per unused dep
- -10 per copyleft license risk
- Floor at 0

## Security Vulnerabilities
<!-- Detail each critical/high vuln with remediation -->

## Outdated Packages
<!-- Table: package, current, latest, category, notes -->

## Unused Dependencies
<!-- List with evidence (no imports found) -->

## License Flags
<!-- Only non-permissive licenses -->

## Duplicates
<!-- Only significant ones -->

## Recommended Actions
<!-- Prioritized list: fix vulns > remove unused > update stale > dedupe -->

Phase 7 — Auto-fix Summary (if --fix)

If AUTO_FIX was set:

Summarize all changes made:

  1. List each package updated/fixed
  2. Run npm test to verify nothing broke
  3. If tests pass and STASH_REF is non-empty: pop and merge the saved state (git stash pop $STASH_REF) — this restores any pre-existing uncommitted changes alongside the npm fix results. Note: the step 2 test run validated the npm changes alone; step 3b below is the authoritative test of the final merged state.
    • If the pop applies cleanly: a. Run npm install to re-sync node_modules/ with the merged manifest. b. Re-run npm test to confirm the merged state is consistent (this is the authoritative check — step 2 only validated the npm changes in isolation). c. If tests still pass: confirm the project is consistent. d. If tests now fail: warn the user — the pre-existing manifest changes conflict with the audit fixes. Recovery options:
      • To undo all manifest changes (both audit fixes and pre-existing): git checkout -- package.json package-lock.json && npm ci
      • To keep only the audit fixes and discard pre-existing changes: manually edit package.json/package-lock.json to remove the pre-existing delta, then npm ci
      • To keep only the pre-existing changes and discard the audit fixes: git checkout HEAD -- package.json package-lock.json && npm ci to revert manifests to their clean state, then manually re-apply only your pre-existing changes
    • If the pop causes conflicts in package.json/package-lock.json: warn the user, leave conflict markers for manual resolution, and instruct: "After you resolve the conflicts, run npm install to re-sync node_modules/ with the resolved lock file before committing."
    • For conflicts in other files, resolve them by keeping both the npm fixes and the pre-existing changes. If tests pass and STASH_REF is empty: no action needed — the npm changes are good and no stash entry exists to clean up
  4. If tests fail and STASH_REF is non-empty:
    • Reset manifests to HEAD first (undoes npm changes): git checkout HEAD -- package.json package-lock.json
    • Then re-apply the pre-existing changes cleanly: git stash pop $STASH_REF
    • Restore node_modules/ to match the reverted lock file: npm ci
    • Report what failed
  5. If tests fail and STASH_REF is empty:
    • Discard manifest changes: git checkout -- package.json package-lock.json
    • Restore node_modules/ to match the reverted lock file: npm ci
    • Report what failed

Rules

  • Never run npm audit fix --force — breaking changes need human review
  • Never remove a dependency without asking the user, even if it appears unused — flag it in the report instead
  • Always run tests after any auto-fix changes
  • If --fix causes test failures, first reset manifests to HEAD (git checkout HEAD -- package.json package-lock.json), then re-apply pre-existing changes (git stash pop $STASH_REF if STASH_REF is non-empty, or no-op if nothing was stashed), then run npm ci to resync node_modules/, and report the failure
  • Treat optionalDependencies separately — they're expected to fail on some platforms
  • The report goes in generated/deps-audit/ — create the directory if it doesn't exist

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.