agentleFS
Sign inStart free
SkillkeelSkillkeel/skillkeel-starter/skills/dependency-audit/SKILL.md

dependency-audit

Skill3 starsChanged 57 days agoMITView on GitHub

Use when the user asks to check dependencies for vulnerabilities, outdated packages, or before a release. Runs the ecosystem's real audit tool, separates fixable from unfixable, and proposes minimal safe upgrades with lockfile changes reviewed, never bulk-upgrading blindly.

  • Installs packages

42 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use api-audit, container-audit and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • gmanch94Skill

    api-audit

    Guides a structured API portfolio audit — from discovery through primary-source-verified inventory, shortcomings analysis, prioritized recommendations, executive summary, and options analysis. Enforces primary-source discipline, cross-file consistency, and advisor review gates. Use when auditing an API portfolio, evaluating a vendor's developer ecosystem, or producing defensible technical analysis of an API set.

    Also in 3 projects that use this

  • grichaSkill

    container-audit

    Audit local Docker images and running containers for hardening issues before deploy — privileged flags, root users, stale base images, missing resource limits. Use for pre-deploy container review.

    Also in 3 projects that use this

  • conorluddySkill

    performance-profiling

    Instruments integration and performance analysis workflows for iOS apps. Use when profiling CPU usage, memory allocation, network activity, or energy consumption. Covers Time Profiler, Allocations, Leaks, Network instruments, and performance optimization strategies.

    Also in 3 projects that use this

  • OpenAISkill

    threat-model

    Use when Codex is already in the threat-modeling phase of a security scan, the user explicitly invokes $threat-model, or the user explicitly asks to create, update, or persist a repository threat model. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.

    Also in 4 projects that use this

  • renfei-designSkill

    a11y-audit

    Audit Figma designs for WCAG accessibility issues — color contrast, minimum font size, touch target sizing, and missing text alternatives. Use when asked to check accessibility, audit contrast ratios, find a11y issues, verify WCAG compliance, or review designs for accessibility problems. Scans nodes, analyzes offline, and annotates issues in Figma.

    Also in 3 projects that use this

  • OpenAISkill

    security-scan

    Use for a standard, single-pass security audit of an entire repository or a scoped path, package, folder, or submodule with no diff to review. This is the default repository scan. Do not use for PR, commit, branch, or working-tree diffs, or for deep, multi-pass scans.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 39 edited versions we read keep these.

  • 3

    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
  1. Very specific:

    Run the audit tool that exists (check availability first with command -v):

    line 10
  2. Very specific:

    Tier 3 (document): no fix available → note in SECURITY.md or an issue with the advisory link.

    line 18
  3. Very specific:

    Never run npm audit fix --force or equivalent.

    line 22
  4. Distinctive:

    Never bump beyond what the advisory requires unless asked.

    line 23
  5. Distinctive:

    Run the project's tests after every applied bump.

    line 24
  6. Distinctive:

    If no audit tool is available and installing is not allowed, say so and stop at the outdated-list.

    line 25

“Common” is measured: kept by at least 6 in 10 of the 39 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

Procedure

  1. Detect ecosystems by manifest: package.json (+ lockfile → npm/pnpm/yarn), pyproject.toml/requirements*.txt, Cargo.toml, go.mod, Gemfile, composer.json. Handle each present one.
  2. Run the audit tool that exists (check availability first with command -v):
    • npm: npm audit --json / pnpm: pnpm audit --json / yarn: yarn npm audit --json
    • Python: pip-audit -f json (or pip install pip-audit in a venv if allowed) ; fallback pip list --outdated
    • Rust: cargo audit --json ; Go: govulncheck ./... ; Ruby: bundle audit ; PHP: composer audit
  3. Summarise: table of package | installed | severity | fixed in | direct/transitive | breaking?. Sort by severity.
  4. Fix in tiers:
    • Tier 1 (do now): patch/minor bumps of direct deps with a fix available. Apply it in the user's repo with the package manager (npm install pkg@^x.y.z) without asking, unless the user said not to change anything; a bump tried only in a scratch copy is not applied. Run the test suite, show the lockfile diff summary.
    • Tier 2 (ask first): major bumps or transitive overrides (overrides/resolutions).
    • Tier 3 (document): no fix available → note in SECURITY.md or an issue with the advisory link.
  5. Re-run the audit and paste the before/after counts.

Rules

  • Never run npm audit fix --force or equivalent.
  • Never bump beyond what the advisory requires unless asked.
  • Run the project's tests after every applied bump; revert the bump if tests fail and report.
  • If no audit tool is available and installing is not allowed, say so and stop at the outdated-list.

Verify

Maintainers: bash evals/run.sh /tmp/skillkeel-evals dependency-audit from the plugin root runs this case and grades it; records and transcripts sit in evals/dependency-audit/. evals/dependency-audit/: fixture package.json with a pinned old lodash and a package-lock; expected: audit run, lodash listed with severity, patch bump proposed as Tier 1, no --force.

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.

Check your setup, free