agentleFS
mikezamayiasmikezamayias/agent-skills/skills/techdebt/SKILL.md

techdebt

Skill1 starsChanged 26 days agoBSD-3-ClauseView on GitHub

Scans the current project for duplicate code, dead code, TODOs, unused imports and inconsistent patterns. It writes a prioritized report to `tasks/techdebt.md`. Use at session end or when the user says techdebt, tech debt, cleanup, dead code or duplicated code.

13 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use docs-ci, docs-interfaces and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • jh941213Skill

    docs-ci

    문서 CI(링크·OpenAPI lint·breaking 게이트·mermaid 검증)나 문서 드리프트 감지(docs.yaml 신선도 검사)를 설치하거나 돌릴 때 사용. 문서 내용 작성은 docs-architecture·docs-interfaces·docs-manuals.

    Also in 3 projects that use this

  • jh941213Skill

    docs-interfaces

    API·이벤트 인터페이스 문서(OpenAPI·swagger·AsyncAPI 명세, 엔드포인트 레퍼런스, API 구성도·시퀀스, API CHANGELOG)를 만들거나 코드와 맞출 때 사용. 시스템 구성도는 docs-architecture, API 설계 원칙은 api-design-principles.

    Also in 3 projects that use this

  • RachaelQuiselSkill

    client-docs

    Client documentation. Use when a build needs documentation updates or missing project documents need to be identified.

    Also in 3 projects that use this

  • planailabsSkill

    docs-architecture

    Layout, build pipeline, and structural gotchas for this dual-Astro repo. Read before changing structure, routing, or adding content. Operational/dev-server questions → dev-build skill.

    Also in 3 projects that use this

  • yu-iskwSkill

    test-and-fix

    Run unit tests and automatically fix code failures, regression bugs, or test mismatches. Use when tests are failing, after implementing new features, or to repair "broken" tests.

    Also in 3 projects that use this

  • llama-farmSkill

    commit-push-pr

    Commit changes, push to GitHub, and open a PR. Includes quality checks (security, patterns, simplification). Use --quick to skip checks.

    Also in 5 projects that use this

  • +4 more from jh941213

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 8 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If inside a git repo: audit that project root

    line 17
  2. Very specific:

    If not in a project: audit recently modified files.

    line 18
  3. Distinctive:

    Use subagents to scan in parallel:

    line 23
  4. Very specific:

    When several findings share one cause, group them under one proposed fix, written above the findings it solves, each finding with its …

    line 78
  5. Distinctive:

    Keep this grouped list as a decision log in the report, so a long session can resume after compaction without rereading the code.

    line 79
  6. Distinctive:

    After writing the report, ask:

    line 83
  7. Distinctive:

    If yes: fix critical items first, then offer high-priority items.

    line 87
  8. Distinctive:

    Do NOT refactor working code unless it's clearly duplicated or dead

    line 91
  9. Distinctive:

    Do NOT add TODOs — the report itself is the record

    line 92
  10. Distinctive:

    Run this at the end of every development session

    line 93

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Tech Debt Audit

The idea comes from tip 4 in Boris Cherny's Claude Code team tips: a /techdebt command run at the end of every session.

You have been invoked to perform a tech debt audit of the current project.

Process

1. Identify Scope

  • If inside a git repo: audit that project root
  • If not in a project: audit recently modified files; write to ~/.claude/tasks/techdebt-global.md
  • Output file: tasks/techdebt.md (relative to project root)

2. Scan for Issues

Use subagents to scan in parallel:

Agent A — Duplication

  • Find functions/methods with near-identical logic
  • Find copy-pasted blocks (10+ lines repeated 2+ times)
  • Find duplicate type definitions or constants

Agent B — Dead Code

  • Exported symbols never imported elsewhere
  • Functions defined but never called
  • Variables assigned but never read
  • Commented-out code blocks older than obvious debugging

Agent C — Hygiene

  • TODO/FIXME/HACK/XXX comments — list each with file:line
  • Unused imports/dependencies
  • Inconsistent naming patterns (camelCase vs snake_case in same file)
  • Magic numbers/strings that should be constants

3. Prioritize Findings

PriorityCriteriaAction
CriticalDead code, duplicate logic causing bugsRemove immediately
HighDuplicate functions, unused exportsRefactor this session
LowTODOs, style inconsistencies, magic valuesNote for later

4. Write Report

Create tasks/techdebt.md with:

# Tech Debt Report — [DATE]

## Critical (remove now)

- [file:line] description

## High (refactor soon)

- [file:line] description

## Low (note for later)

- [file:line] description

## Stats

- Files scanned: N
- Issues found: N critical, N high, N low
  • When several findings share one cause, group them under one proposed fix, written above the findings it solves, each finding with its file:line.
  • Keep this grouped list as a decision log in the report, so a long session can resume after compaction without rereading the code.

5. Offer to Fix

After writing the report, ask:

"I found N critical and N high-priority issues. Should I fix the critical ones now?"

If yes: fix critical items first, then offer high-priority items.

Notes

  • Do NOT refactor working code unless it's clearly duplicated or dead
  • Do NOT add TODOs — the report itself is the record
  • Run this at the end of every development session

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.