agentsclimarketplace

Manage technical debt tradeoffs

Skill alexe-ev/product-plugins/technical-product/skills/manage-technical-debt-tradeoffs

Skill library for AI agents — 15 product domains, 121 skills. Tells the agent what to ask, how to reason, and what to output.

Install
npx -y skills add alexe-ev/product-plugins --skill manage-technical-debt-tradeoffs

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 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

Structure the trade-off decision between addressing technical debt and delivering new product value. Use this skill when a team needs to make explicit, principled decisions about when and how to invest in technical debt reduction.

SKILL.md

2.8 KB, as published. Nobody here has run it

Manage Technical Debt Trade-offs

Purpose

Help product and engineering teams make principled, transparent decisions about when to prioritize technical debt over new features — and how to communicate and sequence those decisions.

Skill type

Conceptual skill

Use this skill when

  • Engineering is pushing for a technical debt investment and product needs to evaluate the trade-off
  • A product area is slowing down due to accumulated debt and the impact needs to be quantified
  • A planning cycle needs to include technical debt work alongside feature work
  • Debt-related risk needs to be communicated to stakeholders

Do not use this skill when

  • The goal is pure technical architecture decisions (engineering-owned)
  • The goal is reliability and SLA design (use assess-reliability-scalability)

Required inputs

  • Technical debt area or initiative
  • Estimated cost: time required to address
  • Estimated impact of debt on: velocity, reliability, user experience, or risk

Optional inputs

  • Engineering assessment of debt severity
  • User or business impact data (incidents, slow features, bugs)
  • Opportunity cost: what feature work is blocked or slowed?

Upstream context

Works best when:

  • Engineering has characterized the debt
  • Product velocity or quality data is available

Downstream handoff

Output can feed:

  • build-roadmap-prioritization (debt investment goes on roadmap)
  • build-business-case (debt investment needs justification to stakeholders)

Instructions

  1. Characterize the debt: what type, how old, what caused it?
  2. Quantify the current cost of the debt: delivery slowdown, bug rate, reliability impact, user impact.
  3. Quantify the investment: estimated effort and timeline to address.
  4. Calculate the payback: how long until the investment pays off in recovered velocity or reduced cost?
  5. Identify the risk of not addressing: will the debt compound? Is there a cliff?
  6. Make a recommendation: address now / schedule / accept.

Output

Provide:

  • Debt characterization (type, cause, age)
  • Current cost of debt (velocity, reliability, user impact)
  • Investment estimate
  • Payback analysis
  • Risk of deferral
  • Recommendation: address now / schedule next cycle / accept as-is
  • Stakeholder communication framing

Risks / caveats

  • "Tech debt" without business impact quantification will never beat feature work in prioritization
  • All debt is not equal — distinguish structural risk (blocking growth) from cosmetic debt (annoyance)
  • Accepting debt deliberately is valid — accepting it accidentally is not

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

Said here and by no other author read

  • quantify the current cost of debt
  • quantify the investment to address
  • calculate the payback period
  • identify the risk of not addressing
  • make a recommendation
  • provide stakeholder communication framing

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.