tech-debt
Use when reworking a change to prevent tech debt, or auditing existing debt to categorize, score, and prioritize the refactor backlog.
- 0
- Installs
- —
- Rating
- —
- Success rate
- 3
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 b2a7362a60d98098… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
Tech Debt
Overview
Two complementary stances on technical debt, picked apart by the router in this file:
- Mode A — Prevent: while you're making a change, rework it toward the intended end state. Delete the dead compatibility path instead of preserving it.
- Mode B — Triage: while you're assessing existing code, categorize, score, and prioritize the debt into a remediation plan.
They run at different points in a debt's lifecycle: prevent when writing, triage when planning. Triage output feeds back into prevent, one item at a time.
When to use
Use Mode A when:
- You are implementing, finishing, or reviewing a feature / fix / refactor and the user wants the change clean.
- You're about to keep a fallback, alias, mode flag, or wrapper "just in case" — check it has a caller first.
- The user says "do this properly", "no bandaids", "zero tech debt", or "don't leave a mess".
Use Mode B when:
- The user asks for a tech-debt audit, code-health review, or "what should we refactor?"
- The user wants to prioritize a maintenance / refactor backlog or roadmap.
- Debt has accumulated and nobody is sure what to fix first.
When NOT to use:
- A single obvious local fix with no structural angle — just fix it; don't invoke a debt framework.
- Style/formatting nits — point them at the linter/formatter, not here.
- Greenfield where the intended end state is genuinely unknown (Mode A can't target what isn't defined yet).
How this skill works — router
This skill is a ROUTER. This file stays a thin orchestrator. It picks exactly one mode (or the chain A→B→A), then you load the matching references/*.md and follow it. The two reference docs hold the actual steps, rules, and examples.
Never inline a reference doc's body. If a branch is more than a 2–3 line summary, it belongs in references/. The decision of which branch to take stays here.
Why: keeping the router thin keeps it scannable, and loading the branch body only when the mode is confirmed saves context on the wrong branch.
Routing
Decision criterion — one boolean property of the task: Is the user actively making a change right now (writing/editing code, has a diff)? yes → Mode A; no → Mode B. The chain rule: once a triaged item is being implemented, switch to Mode A for that change.
digraph tech_debt_route {
rankdir=TB;
node [shape=box];
start [label="User task touches tech debt" shape=oval];
q [label="Actively making a change\n(writing/editing code, has a diff)?" shape=diamond];
a [label="MODE A — PREVENT\nRework THIS change to the\nintended end state"];
b [label="MODE B — TRIAGE\nCategorize + score the\nwhole codebase's debt"];
loadA [label="Load references/prevent-during-change.md"];
loadB [label="Load references/triage-backlog.md"];
chain [label="Implementing a triaged item?\nSwitch to Mode A for that change" shape=diamond];
start -> q;
q -> a [label="yes"];
q -> b [label="no — assessing existing code"];
a -> loadA;
b -> loadB;
loadB -> chain;
chain -> loadA [label="yes, per item"];
}
Routing table
| If the user is… | Mode | Load |
|---|---|---|
| implementing/finishing a feature, fix, or refactor and wants the change clean | A | references/prevent-during-change.md |
| about to preserve a fallback/alias/flag "just in case" | A | references/prevent-during-change.md |
| asking for a tech-debt audit / "what should we refactor" / code-health review | B | references/triage-backlog.md |
| asking to prioritize a maintenance or refactor backlog | B | references/triage-backlog.md |
| fixing an item that came out of a triage | A (per item) | references/prevent-during-change.md |
Mode A — Prevent (during a change)
Rework the change from the intended end state, not the path that led to the current patch. Optimize for the code that should exist; delete dead compatibility paths rather than improving them. Prefer one clear component/flow over mode flags.
Load references/prevent-during-change.md and follow it.
Mode B — Triage (audit a backlog)
Systematically identify, categorize, and prioritize existing debt across the codebase. Produce a prioritized list with effort estimates and a phased remediation plan that can run alongside feature work.
Load references/triage-backlog.md and follow it.
Bottom line
Prevent new debt while you're changing the code; triage old debt when you're planning what to fix.
Files
3- SKILL.md
1fab8014b44.8 KB - references/prevent-during-change.md
e286478c205.4 KB - references/triage-backlog.md
e3b963574a4.5 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from secondsky/claude-skills8
[TODO: Write comprehensive description in third-person. Start with "This skill provides..." or "This skill should be used when..."] [TODO: Add "Use when" scenarios - specific situations where Claude should use this skill] [TODO: Add keywords - technologies, use cases, error messages that should tr
100+ animated React components (Aceternity UI) for Next.js with Tailwind. Use for hero sections, parallax, 3D effects, or encountering animation, shadcn CLI integration errors.
Secure API authentication with JWT, OAuth 2.0, API keys. Use for authentication systems, third-party integrations, service-to-service communication, or encountering token management, security headers, auth flow errors.
Creates comprehensive API changelogs documenting breaking changes, deprecations, and migration strategies for API consumers. Use when managing API versions, communicating breaking changes, or creating upgrade guides.
Verifies API contracts between services using consumer-driven contracts, schema validation, and tools like Pact. Use when testing microservices communication, preventing breaking changes, or validating OpenAPI specifications.
Master REST and GraphQL API design principles to build intuitive, scalable, and maintainable APIs that delight developers. Use when designing new APIs, reviewing API specifications, or establishing API design standards.
Implements standardized API error responses with proper status codes, logging, and user-friendly messages. Use when building production APIs, implementing error recovery patterns, or integrating error monitoring services.
Builds flexible API filtering and sorting systems with query parameter parsing, validation, and security. Use when implementing search endpoints, building data grids, or creating dynamic query APIs.