agentleFS
InfiniteRoomLabsInfiniteRoomLabs/agent-ops/skills/dep-audit/SKILL.md

dep-audit

Skill0 starsChanged 5 months agoMITView on GitHub

Use when auditing project dependencies for license, security, or staleness issues

9 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

13 rules. 0 are common, 10 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    FLAG ALL COPYLEFT LICENSES IN PERMISSIVE PROJECTS: If the project uses MIT/Apache/BSD, any dependency using GPL/AGPL/LGPL/MPL must be …

    line 16
  2. Distinctive:

    If multiple ecosystems are detected, audit each one separately.

    line 31
  3. Very specific:

    Read the LICENSE file or the license field in the package manifest to determine the project's own license.

    line 35
  4. Distinctive:

    Run the appropriate command for the detected package manager:

    line 39
  5. Distinctive:

    If the command is unavailable, fall back to reading the lock file and comparing versions via the registry API.

    line 50
  6. Distinctive:

    When the project license is permissive (MIT, Apache-2.0, BSD):

    line 66
  7. Distinctive:

    Run the appropriate audit command:

    line 78
  8. Distinctive:

    If the tool is unavailable, note it as SKIPPED in the report.

    line 88
  9. Distinctive:

    Do NOT install dependencies or modify lock files.

    line 141
  10. Very specific:

    Do NOT run npm install, composer install, etc.

    line 142
  11. Distinctive:

    Do NOT assume all commands are available.

    line 143
  12. Distinctive:

    Do NOT report patch-level outdated dependencies as urgent.

    line 144
  13. Distinctive:

    Do NOT conflate "outdated" with "vulnerable." Outdated is maintenance.

    line 145

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “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

Dependency Audit

Audit project dependencies for license compatibility, outdated versions, and known vulnerabilities.

Iron Law

FLAG ALL COPYLEFT LICENSES IN PERMISSIVE PROJECTS. If the project uses MIT/Apache/BSD, any dependency using GPL/AGPL/LGPL/MPL must be explicitly flagged as a compatibility risk.

Step 1: Detect Package Manager

Scan the repo root for manifest files to determine the ecosystem:

FileEcosystemLock file
package.jsonnpm/Node.jspackage-lock.json, yarn.lock, pnpm-lock.yaml
composer.jsonComposer/PHPcomposer.lock
Cargo.tomlCargo/RustCargo.lock
pyproject.toml / requirements.txtpip/Pythonrequirements.txt, poetry.lock
go.modGo modulesgo.sum
GemfileBundler/RubyGemfile.lock

If multiple ecosystems are detected, audit each one separately.

Step 2: Detect Project License

Read the LICENSE file or the license field in the package manifest to determine the project's own license. This is needed for compatibility analysis in Step 4.

Step 3: Check for Outdated Dependencies

Run the appropriate command for the detected package manager:

EcosystemCommand
npmnpm outdated --json
Composercomposer outdated --format=json
Cargocargo outdated --format json (if cargo-outdated is installed, otherwise parse Cargo.toml manually)
pippip list --outdated --format=json
Gogo list -m -u all
Bundlerbundle outdated --parseable

If the command is unavailable, fall back to reading the lock file and comparing versions via the registry API.

Step 4: Identify Dependency Licenses

Determine licenses for each dependency:

EcosystemMethod
npmnpm ls --json then check each package's package.json license field
Composercomposer licenses --format=json
Cargocargo license (if cargo-license is installed) or parse Cargo.toml of each dep
pippip-licenses --format=json (if installed) or check PyPI metadata
GoCheck LICENSE files in module cache or go-licenses tool

License Compatibility Matrix

When the project license is permissive (MIT, Apache-2.0, BSD):

Dependency LicenseStatus
MIT, ISC, BSD, Apache-2.0, Unlicense, CC0COMPATIBLE
LGPL-2.1, LGPL-3.0CAUTION -- compatible if dynamically linked
GPL-2.0, GPL-3.0, AGPL-3.0INCOMPATIBLE -- copyleft infection risk
MPL-2.0CAUTION -- file-level copyleft
Unknown / No licenseRISK -- treat as proprietary

Step 5: Check for Known Vulnerabilities

Run the appropriate audit command:

EcosystemCommand
npmnpm audit --json
Composercomposer audit --format=json
Cargocargo audit --json (if cargo-audit is installed)
pippip-audit --format=json (if installed)
Gogovulncheck ./... (if installed)

If the tool is unavailable, note it as SKIPPED in the report.

Output Format

Present the report as:

# Dependency Audit Report

**Project**: {name}
**Project License**: {license}
**Ecosystem**: {ecosystem}
**Total Dependencies**: {count}
**Audited**: {date}

## Summary

| Category | Count |
|----------|-------|
| Up to date | X |
| Outdated (minor) | X |
| Outdated (major) | X |
| Vulnerable | X |
| License incompatible | X |
| License caution | X |

## Vulnerabilities

| Package | Installed | Severity | Advisory | Fix |
|---------|-----------|----------|----------|-----|
| {name} | {version} | CRITICAL/HIGH/MEDIUM/LOW | {CVE or advisory ID} | Upgrade to {version} |

## License Issues

| Package | Version | License | Status | Risk |
|---------|---------|---------|--------|------|
| {name} | {version} | {license} | INCOMPATIBLE/CAUTION/RISK | {explanation} |

## Outdated Dependencies

| Package | Current | Latest | Type |
|---------|---------|--------|------|
| {name} | {current} | {latest} | major/minor/patch |

## Recommendations

1. **[CRITICAL]** {action} -- {why}
2. **[IMPORTANT]** {action} -- {why}
3. **[MAINTENANCE]** {action} -- {why}

Anti-Patterns

  • Do NOT install dependencies or modify lock files. Read-only analysis.
  • Do NOT run npm install, composer install, etc. Work with what is already installed or use registry APIs.
  • Do NOT assume all commands are available. Check first and gracefully skip unavailable tools.
  • Do NOT report patch-level outdated dependencies as urgent. Focus on major version gaps and security issues.
  • Do NOT conflate "outdated" with "vulnerable." Outdated is maintenance; vulnerable is security.

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.