Token导航 LogoToken导航

Agent Skill · 研究检索

technical-debt-management(技术债务管理)

technical-debt-management 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

technical-debt-management 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为调用外部服务;许可证为 MIT,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 12,306。

总安装 10,382周安装 422GitHub Stars 公开资料未说明下载 2,652核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:technical-debt-management(技术债务管理)
来源仓库:https://github.com/zpankz/mcp-skillset
仓库路径:skills/technical-debt-management
安装命令:
npx skills add zpankz/mcp-skillset --skill "technical-debt-management"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add zpankz/mcp-skillset --skill "technical-debt-management"

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

发现并安装AI代理的技能,用于管理技术债务相关流程。适用于Codex、Claude等宿主中优化代码质量与维护策略。通过npx skills add zpankz/mcp-skillset --skill "technical-debt-management"安装。需评估是否涉及外部依赖调用或配置文件修改。

应结合项目实际情况判断适用性,避免盲目引入新工具。

来源仓库内路径:skills/technical-debt-management

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add zpankz/mcp-skillset --skill "technical-debt-management";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要调用外部服务,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

technical-debt-management 怎么安装?

在终端执行 npx skills add zpankz/mcp-skillset --skill "technical-debt-management"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

technical-debt-management 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

technical-debt-management 需要什么权限?

权限级别是调用外部服务。该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

technical-debt-management 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

technical-debt-management 用的人多吗?

公开数据是累计安装 10,382 次,近一周安装 422 次,下载 2,652 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

technical-debt-management 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
technical-debt-management

技术债务管理 · 本页

10,382—调用外部服务MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
Technical Debt Management
description
Systematic technical debt quantification and management using SQALE methodology with value-effort prioritization, phased paydown roadmaps, and prevention strategies. Use when technical debt unmeasured or subjective, need objective prioritization, planning refactoring work, establishing debt prevention practices, or tracking debt trends over time. Provides 6 methodology components (measurement with SQALE index, categorization with code smell taxonomy, prioritization with value-effort matrix, phased paydown roadmap, trend tracking system, prevention guidelines), 3 patterns (SQALE-based quantification, code smell taxonomy mapping, value-effort prioritization), 3 principles (high-value low-effort first, SQALE provides objective baseline, complexity drives maintainability debt). Validated with 4.5x speedup vs manual approach, 85% transferability across languages (Go, Python, JavaScript, Java, Rust), SQALE industry-standard methodology.
allowed-tools
Read, Write, Edit, Bash, Grep, Glob

Technical Debt Management

Transform subjective debt assessment into objective, data-driven paydown strategy with 4.5x speedup.

Measure what matters. Prioritize by value. Pay down strategically. Prevent proactively.

When to Use This Skill

Use this skill when:

  • 📊 Unmeasured debt: Technical debt unknown or subjectively assessed
  • 🎯 Need prioritization: Many debt items, unclear which to tackle first
  • 📈 Planning refactoring: Need objective justification and ROI analysis
  • 🚨 Debt accumulation: Debt growing but no tracking system
  • 🔄 Prevention lacking: Reactive debt management, no proactive practices
  • 📋 Objective reporting: Stakeholders need quantified debt metrics

Don't use when:

  • ❌ Debt already well-quantified with SQALE or similar methodology
  • ❌ Codebase very small (<1K LOC, minimal debt accumulation)
  • ❌ No refactoring capacity (debt measurement without action is wasteful)
  • ❌ Tools unavailable (need complexity, coverage, duplication analysis tools)

Quick Start (30 minutes)

Step 1: Calculate SQALE Index (15 min)

SQALE Formula:

Development Cost = LOC / 30  (30 LOC/hour productivity)
Technical Debt = Remediation Cost (hours)
TD Ratio = Technical Debt / Development Cost × 100%

SQALE Ratings:

  • A (Excellent): ≤5% TD ratio
  • B (Good): 6-10%
  • C (Moderate): 11-20%
  • D (Poor): 21-50%
  • E (Critical): >50%

Example (meta-cc):

LOC: 12,759
Development Cost: 425.3 hours
Technical Debt: 66.0 hours
TD Ratio: 15.52% (Rating: C - Moderate)

Step 2: Categorize Debt (10 min)

SQALE Code Smell Taxonomy:

  1. Bloaters: Long methods, large classes (complexity debt)
  2. Change Preventers: Shotgun surgery, divergent change (flexibility debt)
  3. Reliability Issues: Test coverage gaps, error handling (quality debt)
  4. Couplers: Feature envy, inappropriate intimacy (coupling debt)
  5. Dispensables: Duplicate code, dead code (maintainability debt)

Example Breakdown:

  • Complexity: 54.5 hours (82.6%)
  • Coverage: 10.0 hours (15.2%)
  • Duplication: 1.0 hours (1.5%)

Step 3: Prioritize with Value-Effort Matrix (5 min)

Four Quadrants:

High Value, Low Effort  → Quick Wins (do first)
High Value, High Effort → Strategic (plan carefully)
Low Value, Low Effort   → Opportunistic (do when convenient)
Low Value, High Effort  → Avoid (skip unless critical)

Quick Wins Example:

  • Fix error capitalization (0.5 hours)
  • Increase test coverage for small module (2.0 hours)

Six Methodology Components

1. Measurement Framework (SQALE)

Objective: Quantify technical debt objectively using industry-standard SQALE methodology

Three Calculations:

A. Development Cost:

Development Cost = LOC / Productivity
Productivity = 30 LOC/hour (SQALE standard)

B. Remediation Cost (Complexity Example):

Graduated Thresholds:
- Low complexity (≤10): 0 hours
- Medium complexity (11-15): 0.5 hours per function
- High complexity (16-25): 1.0 hours per function
- Very high (26-50): 2.0 hours per function
- Extreme (>50): 4.0 hours per function

C. Technical Debt Ratio:

TD Ratio = (Total Remediation Cost / Development Cost) × 100%
SQALE Rating = Map TD Ratio to A-E scale

Tools:

  • Go: gocyclo, gocov, golangci-lint
  • Python: radon, pylint, pytest-cov
  • JavaScript: eslint, jscpd, nyc
  • Java: PMD, JaCoCo, CheckStyle
  • Rust: cargo-geiger, clippy

Output: SQALE Index Report (total debt, TD ratio, rating, breakdown by category)

Transferability: 100% (SQALE formulas language-agnostic)


2. Categorization Framework (Code Smells)

Objective: Map metrics to SQALE code smell taxonomy for prioritization

Five SQALE Categories:

1. Bloaters (Complexity Debt):

  • Long methods (cyclomatic complexity >10)
  • Large classes (>500 LOC)
  • Long parameter lists (>5 parameters)
  • Remediation: Extract method, split class, introduce parameter object

2. Change Preventers (Flexibility Debt):

  • Shotgun surgery (change requires touching multiple files)
  • Divergent change (class changes for multiple reasons)
  • Remediation: Consolidate logic, introduce abstraction layer

3. Reliability Issues (Quality Debt):

  • Test coverage gaps (<80% target)
  • Missing error handling
  • Remediation: Add tests, implement error handling

4. Couplers (Coupling Debt):

  • Feature envy (method uses data from another class more than own)
  • Inappropriate intimacy (high coupling between modules)
  • Remediation: Move method, reduce coupling

5. Dispensables (Maintainability Debt):

  • Duplicate code (>3% duplication ratio)
  • Dead code (unreachable functions)
  • Remediation: Extract common code, remove dead code

Output: Code Smell Report (smell type, instances, files, remediation cost)

Transferability: 80-90% (OO smells apply to OO languages only, others universal)


3. Prioritization Framework (Value-Effort Matrix)

Objective: Rank debt items by ROI (business value / remediation effort)

Business Value Assessment (3 factors):

  1. User Impact: Does debt affect user experience? (0-10)
  2. Change Frequency: How often is this code changed? (0-10)
  3. Error Risk: Does debt cause bugs? (0-10)
  4. Total Value: Sum of 3 factors (0-30)

Effort Estimation:

  • Use SQALE remediation cost model
  • Factor in testing, code review, deployment time

Value-Effort Quadrants:

         High Value
         |
 Quick   |   Strategic
  Wins   |
---------|------------- Effort
Opportun-|   Avoid
  istic  |
         |
       Low Value

Priority Ranking:

  1. Quick Wins (high value, low effort)
  2. Strategic (high value, high effort) - plan carefully
  3. Opportunistic (low value, low effort) - when convenient
  4. Avoid (low value, high effort) - skip unless critical

Output: Prioritization Matrix (debt items ranked by quadrant)

Transferability: 95% (value-effort concept universal, specific values vary)


4. Paydown Framework (Phased Roadmap)

Objective: Create actionable, phased plan for debt reduction

Four Phases:

Phase 1: Quick Wins (0-2 hours)

  • Highest ROI items
  • Build momentum, demonstrate value
  • Example: Fix lint issues, error capitalization

Phase 2: Coverage Gaps (2-12 hours)

  • Test coverage improvements
  • Prevent regressions, enable refactoring confidence
  • Example: Add integration tests, increase coverage to ≥80%

Phase 3: Strategic Complexity (12-30 hours)

  • High-value, high-effort refactoring
  • Address architectural debt
  • Example: Consolidate duplicated logic, refactor high-complexity functions

Phase 4: Opportunistic (as time allows)

  • Low-priority items tackled when working nearby
  • Example: Refactor during feature development in same area

Expected Improvements (calculate per phase):

Phase TD Reduction = Sum of remediation costs in phase
New TD Ratio = (Total Debt - Phase TD Reduction) / Development Cost × 100%
New SQALE Rating = Map new TD ratio to A-E scale

Output: Paydown Roadmap (4 phases, time estimates, expected TD ratio improvements)

Transferability: 100% (phased approach universal)


5. Tracking Framework (Trend Analysis)

Objective: Continuous debt monitoring with early warning alerts

Five Tracking Components:

1. Automated Data Collection:

  • Weekly metrics collection (complexity, coverage, duplication)
  • CI/CD integration (collect on every build)

2. Baseline Storage:

  • Quarterly SQALE snapshots
  • Historical comparison (track delta)

3. Trend Tracking:

  • Time series: TD ratio, complexity, coverage, hotspots
  • Identify trends (increasing, decreasing, stable)

4. Visualization Dashboard:

  • TD ratio over time
  • Debt by category (stacked area chart)
  • Coverage trends
  • Complexity heatmap
  • Hotspot analysis (files with most debt)

5. Alerting Rules:

  • TD ratio increase >5% in 1 month
  • Coverage drop >5%
  • New high-complexity functions (>25 complexity)
  • Duplication spike >3%

Expected Impact:

  • Visibility: Point-in-time → continuous trends
  • Decision making: Reactive → data-driven proactive
  • Early warning: Alert before debt spikes

Output: Tracking System Design (automation plan, dashboard mockups, alert rules)

Transferability: 95% (tracking concept universal, tools vary)


6. Prevention Framework (Proactive Practices)

Objective: Prevent new debt accumulation through gates and practices

Six Prevention Strategies:

1. Pre-Commit Complexity Gates:

# Reject commits with functions >15 complexity
gocyclo -over 15 .

2. Test Coverage Requirements:

  • Overall: ≥80%
  • New code: ≥90%
  • CI/CD gate: Fail build if coverage drops

3. Static Analysis Enforcement:

  • Zero tolerance for critical issues
  • Warning threshold (fail if >10 warnings)

4. Code Review Checklist (6 debt prevention items):

  • [ ] No functions >15 complexity
  • [ ] Test coverage ≥90% for new code
  • [ ] No duplicate code (DRY principle)
  • [ ] Error handling complete
  • [ ] No dead code
  • [ ] Architecture consistency maintained

5. Refactoring Time Budget:

  • Allocate 20% sprint capacity for refactoring
  • Opportunistic paydown during feature work

6. Architecture Review:

  • Quarterly health checks
  • Identify architectural debt early
  • Plan strategic refactoring

Expected Impact:

  • TD accumulation: 2%/quarter → <0.5%/quarter
  • ROI: 4 days saved per quarter (prevention time << paydown time)

Output: Prevention Guidelines (pre-commit hooks, CI/CD gates, code review checklist)

Transferability: 85% (specific thresholds vary, practices universal)


Three Extracted Patterns

Pattern 1: SQALE-Based Debt Quantification

Problem: Subjective debt assessment leads to inconsistent prioritization

Solution: Use SQALE methodology for objective, reproducible measurement

Structure:

  1. Calculate development cost (LOC / 30)
  2. Calculate remediation cost (graduated thresholds)
  3. Calculate TD ratio (remediation / development × 100%)
  4. Assign SQALE rating (A-E)

Benefits:

  • Objective (same methodology, same results)
  • Reproducible (industry standard)
  • Comparable (across projects, over time)

Transferability: 90% (formulas universal, threshold calibration language-specific)


Pattern 2: Code Smell Taxonomy Mapping

Problem: Metrics (complexity, duplication) don't directly translate to actionable insights

Solution: Map metrics to SQALE code smell taxonomy for clear remediation strategies

Structure:

Metric → Code Smell → Remediation Strategy
Complexity >10 → Long Method (Bloater) → Extract Method
Duplication >3% → Duplicate Code (Dispensable) → Extract Common Code
Coverage <80% → Test Gap (Reliability Issue) → Add Tests

Benefits:

  • Actionable (smell → remediation)
  • Prioritizable (smell severity)
  • Educational (developers learn smell patterns)

Transferability: 80% (OO smells require adaptation for non-OO languages)


Pattern 3: Value-Effort Prioritization Matrix

Problem: Too many debt items, unclear which to tackle first

Solution: Rank by ROI using value-effort matrix

Structure:

  1. Assess business value (user impact + change frequency + error risk)
  2. Estimate remediation effort (SQALE model)
  3. Plot on matrix (4 quadrants)
  4. Prioritize: Quick Wins → Strategic → Opportunistic → Avoid

Benefits:

  • ROI-driven (maximize value per hour)
  • Transparent (stakeholders understand prioritization)
  • Flexible (adjust value weights per project)

Transferability: 95% (concept universal, specific values vary)


Three Principles

Principle 1: Pay High-Value Low-Effort Debt First

Statement: "Maximize ROI by prioritizing high-value low-effort debt (quick wins) before tackling strategic debt"

Rationale:

  • Build momentum (early wins)
  • Demonstrate value (stakeholder buy-in)
  • Free up capacity (small wins compound)

Evidence: Quick wins phase (0.5-2 hours) enables larger strategic work

Application: Always start paydown roadmap with quick wins


Principle 2: SQALE Provides Objective Baseline

Statement: "Use SQALE methodology for objective, reproducible debt measurement to enable data-driven decisions"

Rationale:

  • Subjective assessment varies by developer
  • Objective measurement enables comparison (projects, time periods)
  • Industry standard (validated across thousands of projects)

Evidence: 4.5x speedup vs manual approach, objective vs subjective

Application: Calculate SQALE index before any debt work


Principle 3: Complexity Drives Maintainability Debt

Statement: "Complexity debt dominates technical debt (often 70-90%), focus refactoring on high-complexity functions"

Rationale:

  • High complexity → hard to understand → slow changes → bugs
  • Complexity compounds (high complexity attracts more complexity)
  • Refactoring complexity has highest impact

Evidence: 82.6% of meta-cc debt from complexity (54.5/66 hours)

Application: Prioritize complexity reduction in paydown roadmaps


Proven Results

Validated in bootstrap-012 (meta-cc project):

  • ✅ SQALE Index: 66 hours debt, 15.52% TD ratio, rating C (Moderate)
  • ✅ Methodology: 6/6 components complete (measurement, categorization, prioritization, paydown, tracking, prevention)
  • ✅ Convergence: V_instance = 0.805, V_meta = 0.855 (both >0.80)
  • ✅ Duration: 4 iterations, ~7 hours
  • ✅ Paydown roadmap: 31.5 hours → rating B (8.23%, -47.7% debt reduction)

Effectiveness Validation:

  • Manual approach: 9 hours (ad-hoc review, subjective prioritization)
  • Methodology approach: 2 hours (tool-based, SQALE calculation)
  • Speedup: 4.5x ✅
  • Accuracy: Subjective → Objective (SQALE standard)
  • Reproducibility: Low → High

Transferability Validation (5 languages analyzed):

  • Go: 90% transferable (native)
  • Python: 85% (tools: radon, pylint, pytest-cov)
  • JavaScript: 85% (tools: eslint, jscpd, nyc)
  • Java: 90% (tools: PMD, JaCoCo, CheckStyle)
  • Rust: 80% (tools: cargo-geiger, clippy, skip OO smells)
  • Overall: 85% transferable ✅

Universal Components (13/16, 81%):

  • SQALE formulas (100%)
  • Prioritization matrix (100%)
  • Paydown roadmap (100%)
  • Code smell taxonomy (90%, OO smells excluded)
  • Tracking approach (95%)
  • Prevention practices (85%)

Common Anti-Patterns

❌ Measurement without action: Calculating debt but not creating paydown plan ❌ Strategic-only focus: Skipping quick wins, tackling only big refactoring (low momentum) ❌ No prevention: Paying down debt without gates (debt re-accumulates) ❌ Subjective prioritization: "This code is bad" without quantified impact ❌ Tool-free assessment: Manual review instead of automated metrics (4.5x slower) ❌ No tracking: Point-in-time snapshot instead of continuous monitoring (reactive)


Templates and Examples

Templates

Examples


Related Skills

Parent framework:

Complementary domains:


References

Core methodology:

Quick guides:


Status: ✅ Production-ready | Validated in meta-cc | 4.5x speedup | 85% transferable

平台分布

OpenCode

28.83%
按下载量换算765

Claude Code

25.09%
按下载量换算665

windsurf

19.59%
按下载量换算520

Codex

12.52%
按下载量换算332

kiro-cli

8.86%
按下载量换算235

mcpjam

3.81%
按下载量换算101

安全审计

暂无安全审计结果可展示。

权限和风险

调用外部服务

该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills