Tech debt
macOS bootstrap dotfiles: Brewfile, declarative symlinks, app prefs, macOS defaults, agent skills, vault secrets, make doctor. Fork-friendly.
npx -y skills add t4sh/dotfiles --skill tech-debtAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Identify, categorize, and prioritize technical debt. Trigger with "tech debt", "technical debt audit", "what should we refactor", "code health", or when the user asks about code quality, refactoring priorities, or maintenance backlog.
SKILL.md
1.4 KB, as published. Nobody here has run it
Tech Debt Management
Systematically identify, categorize, and prioritize technical debt.
Categories
| Type | Examples | Risk |
|---|---|---|
| Code debt | Duplicated logic, poor abstractions, magic numbers | Bugs, slow development |
| Architecture debt | Monolith that should be split, wrong data store | Scaling limits |
| Test debt | Low coverage, flaky tests, missing integration tests | Regressions ship |
| Dependency debt | Outdated libraries, unmaintained dependencies | Security vulns |
| Documentation debt | Missing runbooks, outdated READMEs, tribal knowledge | Onboarding pain |
| Infrastructure debt | Manual deploys, no monitoring, no IaC | Incidents, slow recovery |
Prioritization Framework
Score each item on:
- Impact: How much does it slow the team down? (1-5)
- Risk: What happens if we don't fix it? (1-5)
- Effort: How hard is the fix? (1-5, inverted — lower effort = higher priority)
Priority = (Impact + Risk) x (6 - Effort)
Output
Produce a prioritized list with estimated effort, business justification for each item, and a phased remediation plan that can be done alongside feature work.
Gives 0 of the 12 instructions most refactoring skills give
Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06
- run tests after each changein 59 of 521, across 56 files
- write tests before refactoringin 27 of 521, across 24 files
- preserve external behaviorin 26 of 521, across 22 files
- remove dead codein 25 of 521, across 24 files
- make small incremental changesin 20 of 521, across 17 files
- break the implementation into tiny commitsin 18 of 521, across 5 files
- ask the user about alternative optionsin 17 of 521, across 4 files
- create a GitHub issue with the planin 17 of 521, across 4 files
- explore the repository to verify assertionsin 17 of 521, across 4 files
- interview the user about the refactorin 16 of 521, across 3 files
- check the codebase for test coveragein 16 of 521, across 3 files
- refactor one thing at a timein 16 of 521, across 12 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.