← All craftbooks

Dependency Audit

Review and QAevalv1.1.3released 2026-09-01workflow: build-loop

Steps

Entry step: scan. Each step names the specialist role it wants; the full working prompt is expandable.

1. Scan the dependency treedeveloperentry

   inventory deps with versions, CVEs, licenses

   Show working prompt

   Step 1: Read the manifest and lockfile (package.json/lock, requirements/poetry, go.mod, Cargo.toml, etc.) to inventory direct and notable transitive dependencies. Step 2: For each, gather: installed version vs latest, the semver gap (patch/minor/major behind), known vulnerabilities (run the ecosystem audit tool if available — `npm audit`, `pip-audit`, `cargo audit` — and capture CVE id + severity), license, and maintenance signals (last release date, archived/deprecated, single-maintainer). If the task already provides audit output or dependency notes, treat those files as authoritative evidence and do not replace them with fresh network assumptions. Step 3: Flag duplicates/multiple versions of the same package and obviously unused or trivially-replaceable dependencies. Step 4: Write the acceptance-criteria checklist for the audit, e.g. 'every direct dependency is inventoried', 'all CVEs at high+ are captured with an id', 'each license is recorded and flagged if copyleft/incompatible', 'staleness is measured by both semver gap and release recency'. Step 5: Save the inventory table to `write_task_note` AND `{{workPath}}/scan.md`. No prioritization yet — this phase is the raw inventory.
   
   The deliverable `{{workPath}}/scan.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.

2. 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.
   
   The deliverable `{{workPath}}/assess.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.

3. Write the audit reportreviewer

   prioritized upgrade/replace/remove plan

   Show working prompt

   Step 1: Open `{{workPath}}/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.
   
   The deliverable `{{workPath}}/dependency-audit.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.

4. Evaluatereviewer

   Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

   Show working prompt

   Open `{{workPath}}/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.
   
   The deliverable lives in the project's artifacts drawer — open `{{workPath}}/dependency-audit.md` with `read_artifact`, not `read_file`.
   
   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.

5. 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

Source

View this craftbook on GitHub · MIT license