The Dependency Audit Report

# SITUATION
A project's dependency tree has grown without oversight. Some packages haven't been updated in years. The team needs to understand what's risky, what's stale, and what to do about it — before a security incident forces the conversation.

Project context:
- Language/runtime: {{LANGUAGE}}
- Package manager: {{PACKAGE_MANAGER}}
- Dependency list or lockfile excerpt: {{DEPS}}
- Production status: {{PROD_STATUS}}

# PURPOSE
Produce a dependency audit report that a tech lead can act on this week. Not a full security scan (tools do that) — a prioritized analysis of what matters and why.

# EXPECTED OUTPUT

## 1. Risk Summary
One paragraph: overall health of the dependency tree. How many direct deps, how many transitive, any immediate red flags.

## 2. Critical Risks (fix this week)
Dependencies with known CVEs, abandoned packages with no security patches, or packages with breaking license changes. For each:
- Package name and version
- The specific risk (CVE ID if applicable, or description)
- Recommended action (upgrade, replace, pin)
- Effort to fix

## 3. Maintenance Debt (fix this quarter)
Dependencies that are behind by major versions, packages with no recent commits, or packages that have been superseded. For each:
- Package name
- How far behind (current vs. latest)
- What's blocking the upgrade (breaking changes, API redesign, etc.)
- Risk of staying on current version

## 4. License Review
Any dependencies with non-permissive licenses (GPL, AGPL, SSPL, or custom restrictive licenses) that could create compliance issues. Note: only flag if relevant to the project's distribution model.

## 5. Recommendation: Replace Candidates
Dependencies that are abandoned, duplicated in the tree, or have better-maintained alternatives. Name the replacement and the migration effort.

# CONTEXT
- This is a human-actionable report, not tool output. Add judgment, not just data.
- If a "risky" dependency is actually low-risk in context (e.g., dev-only dependency), say so.
- Prioritize by actual exploitability, not CVE count.

# STYLE
Technical and direct. No preamble about "the importance of dependency management." Tables where useful, prose where it adds judgment. Tech leads should be able to convert this into tickets directly.