dependency-risk-triage
Tells you which of your dependencies are a liability and the smallest set of changes that fixes it.
Reads package.json, lockfiles and requirements, flags unpinned, abandoned, typosquat-looking or known-risky packages and install scripts, then proposes a minimal upgrade plan.
- version
- 1.0.0
- author
- surpriz
- goal
- code-audit
- license
- MIT
- checks
- checks 100/100
- published
- 2026-11-03
package
1 skills · 3 MCP servers · 5 settings
- mcp filesystem · npm:@modelcontextprotocol/server-filesystem@2.1.0 · filesystem read · network none
- mcp git · pypi:mcp-server-git==2026.10.28 · filesystem read · network none
- mcp github · npm:@modelcontextprotocol/server-github@2025.4.8 · filesystem none · network api.github.com
- setting severity_floor (enum, default medium): Lowest severity to include in the findings list
- setting max_findings (integer, default 20): Cap on the number of findings reported
- setting include_dev_dependencies (boolean, default true): Also review devDependencies (build tooling runs on your machine and in CI)
- setting check_upstream_activity (boolean, default false): Use the GitHub MCP server to check whether a package repo is archived or stale
- setting stale_months (integer, default 24): A package with no release or commit for this many months counts as abandoned
package.json · agent.yaml
readme
Dependency Risk Triage reads your package.json, lockfile, requirements.txt or
pyproject.toml and tells you which dependencies are a liability: version ranges
that let a compromised release walk in, packages nobody maintains, names that
look like a typo of a popular package, packages with install scripts that run
arbitrary code on npm install, git and URL dependencies, and packages the
community knows to avoid.
It does not run npm audit for you and does not replace it. It finds what audit
does not: structural risk. It ends with a minimal upgrade plan, ordered so you
can do the first three items in an afternoon without breaking the build.
It reads files only. Optional: the GitHub MCP server lets it check whether a
package's repository is archived or has gone quiet. Without it, abandonment is
inferred from the lockfile versions and release dates it already knows.
use cases
- Before the first production deploy of a vibe-coded app
- When an AI assistant added packages you have never heard of
- After a supply-chain incident in the news, to know whether you are affected
- To shrink a bloated package.json before handing the project to someone else
← all agents