Best AI Agent Skills for Technical Debt (2026)

Coding agents are the fastest technical-debt generators ever built. They produce working code at a rate no review process was designed for, and the debt they create has a particular signature: three near-identical helper functions, a test suite that passes because it asserts what the code does rather than what it should do, and a utils.py that grew 400 lines in a week nobody remembers.

The same agents can pay that debt down. But not with the default setup, because an agent asked to "clean up this codebase" will reliably rewrite the parts that were fine and leave the parts that were load-bearing and ugly.

The skills below change that, and they work by constraining the agent rather than making it smarter.

The short list

Start with the plan, not the refactor

claude skill add obra/superpowers/writing-plans

sp-writing-plans is the least exciting skill here and the one that changes outcomes most.

Technical debt work fails in a specific way: the agent starts fixing one thing, notices an adjacent problem, fixes that too, and forty minutes later you have a 900-line diff touching nine files with no way to tell which change was the one you asked for. Reviewing that diff costs more than the debt did.

Forcing a written plan first converts an open-ended cleanup into a bounded task list you can approve or reject before any code moves. It also surfaces the disagreement early. When the plan says "extract shared validation into a base class" and you know that base class will be wrong in six months, you find out before the work happens rather than during review.

The Superpowers collection this comes from sits at 270,000+ stars, MIT licensed, updated August 2026. It's the most-adopted skill collection in our directory by a wide margin.

Make the agent prove the bug exists

claude skill add obra/superpowers/systematic-debugging

The default agent debugging loop is: read the error, change something plausible, run it, see a different error, change something else. It converges eventually, and the code it leaves behind carries three speculative changes that had nothing to do with the bug.

sp-systematic-debugging enforces hypothesis-driven analysis: state what you think is wrong, state what you'd observe if that were true, check, then fix. The output isn't only a working fix. It's a fix you can read and understand, which is what stops today's repair from becoming next quarter's mystery.

This is the skill I'd install first on any codebase where an agent has already been working unsupervised.

Tests that assert intent, not behavior

claude skill add obra/superpowers/test-driven-development
claude skill add anthropics/skills/webapp-testing

Agent-written tests have a characteristic failure. Asked to add coverage for existing code, an agent reads the implementation and writes assertions that match it. The suite goes green, coverage numbers rise, and the tests now permanently encode whatever bugs were already there.

sp-tdd enforces red-green-refactor, which breaks that loop by requiring the test to fail first. A test that never failed proved nothing.

webapp-testing is Anthropic's official Playwright skill and the only audited entry here. It drives a real browser, so it verifies the thing a user touches rather than the function you hoped that thing calls. For debt work specifically, it's how you build a safety net before a refactor instead of after.

Order matters: Playwright coverage of the critical paths first, then refactor underneath it. Refactoring into an untested area and adding tests afterward means the tests describe the new code, and you've lost your ability to tell whether behavior changed.

Encoding your standards so they survive the next session

An agent has no memory of the argument your team had about error handling in March. It will re-litigate it every session unless the conclusion is written somewhere it reads.

compound-engineering from Every Inc is a practices-enforcement plugin. 24,172 stars, MIT, updated August 2026. It encodes engineering standards as something the agent applies rather than something it's told once in a prompt and forgets after compaction.

agent-rules-books takes a more opinionated route, translating Clean Code and similar canon into agent-readable rules across Codex, Cursor, and Claude Code. 2,465 stars, MIT. Whether you want this depends on whether you agree with the source material. Clean Code's advice on function length and comment density is contested for good reasons, and installing it means an agent will enforce those positions on your codebase. If your team already argues about this, don't outsource the argument to a skill.

The version I'd recommend is writing your own rules file with your team's real decisions in it, then using agnix to keep it honest:

claude mcp add agnix -- npx -y agent-sh/agnix

agnix lints CLAUDE.md, AGENTS.md, SKILL.md, and hooks: a linter for the instructions rather than the code. At 378 stars and unreviewed trust it's the least-proven skill on this list, but the problem it solves is real. Instruction files rot exactly like code, and nothing else checks them.

Closing the review loop

claude skill add obra/superpowers/receiving-code-review

sp-receiving-review handles the step everyone skips. An agent given review comments tends to address the first one thoroughly, the second partially, and silently drop the third. On a debt-reduction PR with fourteen comments, that's how half the work disappears.

Systematic processing of feedback is unglamorous and it's where the actual completion rate lives.

The measurement problem

One thing worth setting expectations on: none of these skills will give you a debt number.

Coverage percentages, complexity scores, and lint-warning counts all measure things that are easy to count rather than things that cost money. A codebase can sit at 90% coverage and still break every deploy, because the 10% left uncovered is the payment path. Agents optimize whatever metric you hand them, so handing them a bad metric produces confident work in the wrong place.

The signal I'd use instead is friction you can name. Which file does someone complain about in standup. Which change took three days last quarter and should have taken three hours. Which module every new hire gets stuck in during their first month. Those are unmeasurable by tooling and obvious to anyone on the team, which is why the scoping step stays human.

Write the friction down, turn it into a plan with sp-writing-plans, and let the agent execute against something real.

What this stack won't fix

It won't tell you which debt is worth paying. That's a product decision — the ugly module nobody touches costs you nothing, and the clean-looking one at the center of every feature costs you constantly. Agents have no view into which is which, and they gravitate toward whatever is most visibly messy, which is usually the wrong target.

It also won't fix architectural debt. Renaming things, extracting functions, and adding tests are all local operations. A wrong service boundary stays wrong at any level of code quality, and an agent will happily spend a week making the wrong abstraction beautiful.

Decide what to fix yourself. Use the skills to make sure the fix is bounded, tested, and reviewable.

Install order

Four skills, in this sequence:

1. sp-writing-plans, so work is scoped before it starts 2. webapp-testing, so you have a net before you change anything 3. sp-tdd, so new tests mean something 4. sp-systematic-debugging, so fixes stay explicable

Add compound-engineering once you know which of your team's standards keep getting violated. Skip agent-rules-books unless you've read the underlying rules and agree with them. Try agnix when your instruction files are large enough to have drifted.

Related reading: our lists for code review, refactoring, dependency upgrades, and QA testing, plus our full list for developers.

FAQ

Can an agent pay down technical debt without supervision?

No, and the failure mode is expensive. Unsupervised agents optimize for visible mess, which correlates poorly with cost. Scope the work yourself, let the agent execute inside that scope, review the diff.

Why do so many of these come from one collection?

Superpowers is the highest-adoption skill collection in our directory at 270,000+ stars, and its skills are process constraints rather than capabilities, which is what debt work needs. You can install individual skills from it without taking the whole set.

Should I let an agent write tests for existing untested code?

Only with review. An agent reading an implementation and writing matching assertions produces a suite that locks in current bugs. Write assertions from the spec or from what the code should do, then check whether it does.

Is agnix worth installing at 378 stars?

If your instruction files are more than a page or two, probably. It's unreviewed, so read the source first. The category of linting your agent config is new enough that adoption numbers aren't a useful quality signal yet.

How do I stop agents creating new debt in the first place?

sp-writing-plans and sp-tdd together, applied to feature work rather than only cleanup. Most agent-generated debt comes from unbounded tasks with no failing test to define what "done" means.