Trust — is it safe?
Brief 07

Dependency Health Check

Vulnerable, abandoned, oversized, or duplicated packages — the full health check on every dependency this project stands on, with removal candidates named.

DEPS.md4 phases7 lenses~2.6k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: assess every dependency this project stands on — vulnerable, abandoned, oversized, duplicated — and produce a safe upgrade and removal plan.

This is the full health check — vulnerabilities, abandonware, weight, duplication. For pure version-lag and the cost of catching up, run 85.

Read-only pass: inspect manifests and lockfiles, run audit/outdated tooling. Your only write is the report file.

What it looks for

7 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Known vulnerabilities

from audit output; note which are reachable in this codebase vs theoretical

2

Abandonware

no release in 2+ years, archived repos, sole-maintainer risk on critical paths

3

Version lag

majors behind; size the breaking distance for each big jump

4

Heavyweights

large packages used for one function; note the native or small replacement

5

Duplicates & overlaps

two libraries doing the same job (dates, HTTP, state)

6

License risk

anything incompatible with how this project ships

7

Hygiene

missing lockfile, loose version ranges, install scripts from untrusted packages

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

DEPS.md
1
Health snapshot
counts: total, vulnerable, outdated, abandoned
2
Upgrade sequence
ordered list: package · from → to · risk · what might break · effort
3
Removal candidates
package · used for · replacement · size saved
4
One-command wins
safe fixes runnable today
5
Watch list
fine now, risky later
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Inventory

Count direct vs transitive dependencies per manifest.

2
Phase 2

Audit through 7 lenses

Known vulnerabilities — from audit output.

3
Phase 3

Curate

Order upgrades safest-first.

4
Phase 4

Report

Create DEPS.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:dependency-health.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-dependency-health:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=07 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/07.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,620 characters)
# Goal: Dependency Health Check

You are working inside this repo. Mission: assess every dependency this project stands on — vulnerable, abandoned, oversized, duplicated — and produce a safe upgrade and removal plan.

This is the full health check — vulnerabilities, abandonware, weight, duplication. For pure version-lag and the cost of catching up, run 85.

Read-only pass: inspect manifests and lockfiles, run audit/outdated tooling. Your only write is the report file.

## Phase 1 — Inventory
- Count direct vs transitive dependencies per manifest.
- Run the ecosystem's audit and outdated commands; capture the raw counts.
- Note anything pinned oddly, forked, or vendored.

## Phase 2 — Audit through 7 lenses
1. **Known vulnerabilities** — from audit output; note which are reachable in this codebase vs theoretical
2. **Abandonware** — no release in 2+ years, archived repos, sole-maintainer risk on critical paths
3. **Version lag** — majors behind; size the breaking distance for each big jump
4. **Heavyweights** — large packages used for one function; note the native or small replacement
5. **Duplicates & overlaps** — two libraries doing the same job (dates, HTTP, state)
6. **License risk** — anything incompatible with how this project ships
7. **Hygiene** — missing lockfile, loose version ranges, install scripts from untrusted packages

## Phase 3 — Curate
- Order upgrades safest-first: patch bumps → minors → risky majors
- Every removal candidate names its replacement (native API, stdlib, or nothing)
- Estimate blast radius per change: files touched, APIs changed

## Phase 4 — Report
Create `DEPS.md` at repo root:
1. **Health snapshot** — counts: total, vulnerable, outdated, abandoned
2. **Upgrade sequence** — ordered list: package · from → to · risk · what might break · effort
3. **Removal candidates** — package · used for · replacement · size saved
4. **One-command wins** — safe fixes runnable today
5. **Watch list** — fine now, risky later

Start the report with today's date. If `DEPS.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Reachability matters: a vuln in an unused code path is lower priority — say so
- Never recommend a major upgrade without naming its breaking changes
- No third-party dependencies in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which changes to apply

House rules for this Goal Prompt

  • Reachability matters: a vuln in an unused code path is lower priority — say so
  • Never recommend a major upgrade without naming its breaking changes
  • No third-party dependencies in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which changes to apply
Keep exploring

Pairs well with

Curated neighbors — briefs that answer the adjacent question, worth running in the same session.

More Trust briefs

Runs inside these playbooks — curated sequences you can launch with one paste: