Dependency Audit
Audit a project's dependencies for security, staleness, license, and maintenance risk, then produce a prioritized remediation report. First scans the manifest and lockfile to inventory every dependency with its installed vs latest version, known CVEs, license, and maintenance signals, then assesses each into a risk tier weighing severity, exploitability, breaking-change cost, and removability, then writes a report with a concrete upgrade/replace/remove action and order for each risky dependency. Use this for a dependency audit, supply-chain review, checking for vulnerable or outdated packages, license compliance, npm/pip audit triage, or reducing dependency risk — it turns a raw audit dump into a prioritized, justified action plan rather than a wall of warnings.
Steps
Entry step: scan. Each step names the specialist role it wants; the full working prompt is expandable.
- Scan the dependency treedeveloperentry
inventory deps with versions, CVEs, licenses
Show working prompt
Step 1: Call `security_scan` once and `list_dependencies` to reuse the indexed inventory and any semgrep/osv/npm evidence, then read the manifest and lockfile (package.json/lock, requirements/poetry, go.mod, Cargo.toml, etc.) to reconcile every direct and notable transitive dependency. Step 2: For each, gather installed version vs latest only from supplied or scanner evidence, the semver gap, known vulnerabilities with id + severity, license, and maintenance signals. If the task supplies audit output or dependency notes, treat those files as authoritative and do not replace them with network assumptions. Step 3: Flag duplicates/multiple versions and likely unused dependencies, but use `search_code`/`find_references` before calling a dependency unused or a vulnerable path reachable. Step 4: Write the acceptance-criteria checklist: every direct dependency reconciled; every high+ advisory captured; licenses and missing license evidence explicit; reachability claims verified; index/scanner coverage and unavailable tools stated. Step 5: Save the inventory and coverage statement to `write_task_note` AND `notes/scan.md`. No prioritization yet.
- Assess riskreviewer
tier each dep by risk and remediation cost
Show working prompt
Step 1: For each dependency in the inventory, assign a risk tier (Critical / High / Medium / Low) weighing: CVE severity AND whether the vulnerable code path is actually used, how far behind it is, whether the upgrade is a breaking major (and the migration cost), license incompatibility, and abandonment/maintenance risk. Step 2: Decide the remediation per dep: patch-upgrade (safe), minor/major upgrade (note breaking changes to handle), replace (name the alternative), remove (if unused), or defer (if no seeded issue is present). If the evidence says no patched version exists, do not recommend an update-to-patch; recommend replacement, containment, or a human decision instead. Step 3: Determine a sensible ORDER — critical/no-patch security items first, then other high CVEs, then cleanup and low-effort maintenance; do not put unused cleanup or low-risk maintenance ahead of a critical no-patch replacement just because it is easy. Step 4: Distinguish real exposure from theoretical (a CVE in an unreachable code path is lower risk — say so), and distinguish maintenance-only upgrades from security fixes. Step 5: Note anything needing human judgment (license/legal, a major framework bump). Good looks like: a tier justified by both severity and actual exposure, not just the audit tool's color. Stage the tiered list to `write_task_note`. Do not write the report yet.
- Write the audit reportreviewer
prioritized upgrade/replace/remove plan
Show working prompt
Step 1: Open `dependency-audit.md` and write a '## Summary' line: total deps, count by risk tier, and the headline risk. Step 2: Add an '## Action plan' ordered by priority; each entry: `package@installed → action (target version / replacement / remove / defer)` with the reason (CVE id + severity, semver gap, license, abandonment, or no seeded issue), the breaking-change note if any, and the migration effort. Keep exact target versions and named replacement alternatives from the evidence; do not downgrade a named maintenance upgrade to vague monitoring or replace a named alternative with generic wording. Step 3: Add a '## License flags' section for any copyleft/incompatible licenses; if the source names GPL/copyleft, the section must name that package and exact license identifier, not say no flags were found. Do not infer missing licenses; say license not provided when the evidence does not name one. Step 4: Add a '## Needs human decision' section for legal/major-bump/no-patch calls. Step 5: Add a one-paragraph '## Recommended order' (what to do this week vs later), keeping critical no-patch CVEs ahead of unused cleanup and low-effort maintenance upgrades. Every action must name a concrete target and a justification — no 'update your packages'. On a loop-back, fix only the named gaps. `write_task_note` the report path and the counts by tier.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open `dependency-audit.md` and grade it against the scan checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) every direct dependency is inventoried with installed vs latest; (2) all high+ CVEs are captured with an id and severity; (3) each risky dep has a concrete action (upgrade target / replacement / remove / defer) and a justification; (4) breaking-change/migration cost is noted for major upgrades; (5) licenses are recorded and incompatibilities flagged, especially any GPL/copyleft source note; (6) the plan is prioritized with a recommended order that puts critical/no-patch security items before unused cleanup and maintenance-only upgrades; (7) risk tiers reflect actual exposure, not just the tool's raw severity; (8) no dependency with no seeded issue is inflated into a security/replacement recommendation; (9) no dependency with no patched version is described as patch-upgradeable. If any criterion fails, name the exact gap and loop back. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "report" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- dependency audit
- are my dependencies safe
- check for outdated packages
- supply chain review
- npm audit triage
- license compliance check
Toolsets
- [object Object]
- [object Object]
Source
View this craftbook on GitHub · MIT license