Duplication, tangles, and dead patterns — mapped as interest paid vs principal owed, with a refactor sequence that pays for itself.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: map the technical debt as an economist would — what interest is being paid today, what the principal costs to retire — and produce a refactor sequence where every step pays for itself.
Read-only pass. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
the same logic living in 3 places, drifting apart
everything-magnets that every change touches
import cycles, layers reaching around each other
three ways to fetch, two ways to handle errors; every choice a new dev must relearn
code kept "just in case", vestigial abstractions
patterns the ecosystem has moved past, blocking upgrades
code that can't be tested without mocking the world
files that keep appearing in bug-fix commits
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.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Cross churn with complexity.
Duplication clusters — the same logic living in 3 places, drifting apart.
Every item states its interest.
Create DEBT.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:tech-debt-map.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-tech-debt-map:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=13 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/13.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Tech Debt Map You are working inside this repo. Mission: map the technical debt as an economist would — what interest is being paid today, what the principal costs to retire — and produce a refactor sequence where every step pays for itself. Read-only pass. Your only write is the report file. ## Phase 1 — Find where debt concentrates - Cross churn with complexity: which files are both large and frequently edited? (use git log) - Census the TODO/FIXME/HACK comments: count, age, clusters. - Where do new features take longest to add? Trace one recent feature's diff to see what it had to touch. ## Phase 2 — Audit through 8 lenses 1. **Duplication clusters** — the same logic living in 3 places, drifting apart 2. **God files & modules** — everything-magnets that every change touches 3. **Tangles** — import cycles, layers reaching around each other 4. **Pattern inconsistency** — three ways to fetch, two ways to handle errors; every choice a new dev must relearn 5. **Dead weight** — code kept "just in case", vestigial abstractions 6. **Outdated idioms** — patterns the ecosystem has moved past, blocking upgrades 7. **Test-hostile design** — code that can't be tested without mocking the world 8. **Historic hotspots** — files that keep appearing in bug-fix commits ## Phase 3 — Curate - Every item states its **interest**: how it hurts today (slower features, recurring bugs, onboarding cost) - And its **principal**: realistic cost to fix - Explicitly list debt to ACCEPT — real debt not worth paying down; write down why ## Phase 4 — Report Create `DEBT.md` at repo root: 1. **Debt inventory** — each: item · interest paid · principal · evidence (paths, churn numbers) 2. **Refactor sequence** — ordered steps, each safe, independently shippable, and justified by what it unlocks next 3. **Accepted debt register** — with reasons; revisit dates optional 4. **The first refactor** — scoped fully, with a safety plan (tests to add first) Start the report with today's date. If `DEBT.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - No refactor without a payoff story: what gets faster, safer, or simpler after - Sequence so each step de-risks the next - 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 refactor to start
reports/ directory exists at the repo root, write the report there instead of the root.Walk clone → install → run → change → PR like a brand-new developer and log every stumble on the way to a first contribution.
Census the drifted colors, spacing, and duplicate components; propose the token set and migration order to unify them.
Can a coding agent work here? Entry files, one-command checks, discoverable conventions, and a mechanical definition of done — audited by attempting the work.
Read git history for the human risks — files only one person understands, critical paths with a truck factor of one, and the knowledge that leaves when they do.
Runs inside these playbooks — curated sequences you can launch with one paste: