{"id":"ecb336e0-eb46-4160-9535-f59ef310bd15","entityType":"agent","slug":"clawhub-kokxi-qa-tech-debt-management","name":"qa-tech-debt-management","canonicalUrl":"https://www.xpersona.co/agent/clawhub-kokxi-qa-tech-debt-management","canonicalPath":"/agent/clawhub-kokxi-qa-tech-debt-management","generatedAt":"2026-10-11T10:51:26.562Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T07:55:37.589Z","emptyReason":null},"description":"当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans. Skill: qa-tech-debt-management Owner: kokxi Summary: 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans. Tags:","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-tech-debt-management","sourceUrl":"https://clawhub.ai/kokxi/qa-tech-debt-management","homepage":"https://clawhub.ai/kokxi/skills/qa-tech-debt-management","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/kokxi/qa-tech-debt-management","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/kokxi/skills/qa-tech-debt-management","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:55:37.589Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:55:37.589Z","emptyReason":null},"stars":null,"forks":null,"downloads":1119,"packageName":null,"latestVersion":"1.8.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:55:37.531Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T07:55:37.589Z","lastCrawledAt":"2026-10-11T07:55:37.531Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T07:55:37.531Z","lastVerifiedAt":null,"highlights":[{"version":"1.8.0","createdAt":"2026-09-29T04:28:53.285Z","changelog":"**Changelog 1.8.0 — Updates for better debt governance reference and metadata structure:** - Added `references/debt-governance.md` and offloaded detailed治理方法, reducing context bloat on each trigger. - Streamlined and standardized metadata structure in SKILL.md for clearer related-skills, input/output formats, and error guidance. - Updated the loading flow: refers to the new governance reference when identifying or repaying test debt. - Removed obsolete `skill-card.md`; improved license and usage notes. - General polish and clarifications, no core logic changes to workflow or guidance.","fileCount":4,"zipByteSize":6042},{"version":"1.7.7","createdAt":"2026-09-27T14:41:42.601Z","changelog":"1.7.7","fileCount":3,"zipByteSize":5171},{"version":"1.7.6","createdAt":"2026-09-01T12:47:01.051Z","changelog":"显示名改中文","fileCount":3,"zipByteSize":5423},{"version":"1.7.5","createdAt":"2026-08-30T15:19:52.381Z","changelog":"1.7.5: 版本号升级","fileCount":3,"zipByteSize":5166},{"version":"1.7.0","createdAt":"2026-08-16T14:33:03.240Z","changelog":"Version 1.7.0 – Cleanup and documentation update. - Removed redundant file: skill-card.md. - Updated SKILL.md version and metadata to 1.7.0. - No changes to technical content or logic.","fileCount":3,"zipByteSize":4988},{"version":"1.6.3","createdAt":"2026-08-12T15:28:46.099Z","changelog":"- Added slug and displayName fields to SKILL.md; updated version to 1.6.3. - Minor formatting and metadata improvements in SKILL.md for clarity and consistency. - Removed deprecated skill-card.md file.","fileCount":3,"zipByteSize":4937},{"version":"1.6.0","createdAt":"2026-07-06T17:18:00.101Z","changelog":"Version 1.6.0 - Added categories, depth requirement quantification, and error recovery guidance fields for clearer usage context and process control. - Enhanced output format with traceability requirements for each debt item. - Included a security warning highlighting evaluation risks and workspace-only output scope. - Removed the file skill-card.md for simplification and maintenance. - No core workflow logic was changed; all existing principles, processes, and examples remain unaltered.","fileCount":3,"zipByteSize":5110},{"version":"1.5.0","createdAt":"2026-06-29T12:36:05.745Z","changelog":"Version 1.5.0 – 技能结构升级，聚焦“系统性技术债务管理” - 技能描述和定位显著优化，强调识别技术债务根因与“还款”策略，突出系统性治理理念。 - 更新 input/output 格式：输入增加“测试报告”“代码质量数据”等结构化要求，输出包含“债务清单、影响分析、偿还计划、预防策略”四部分。 - 移除 skill-card.md，精简文档结构，内容前后一致。 - 细化输出示例与典型场景，强调不要对 flaky test 只做被动修复。 - 保留原有债务类型、评估矩阵、治理方法、预防措施内容，统一排版与文本格式。","fileCount":3,"zipByteSize":4488}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-tech-debt-management","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T10:51:26.561Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-tech-debt-management/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T07:55:37.589Z","emptyReason":null},"readme":"Skill: qa-tech-debt-management\n\nOwner: kokxi\n\nSummary: 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans.\n\nTags: latest:1.8.0\n\nVersion history:\n\nv1.8.0 | 2026-09-29T04:28:53.285Z | auto\n\n**Changelog 1.8.0 — Updates for better debt governance reference and metadata structure:**\n\n- Added `references/debt-governance.md` and offloaded detailed治理方法, reducing context bloat on each trigger.\n- Streamlined and standardized metadata structure in SKILL.md for clearer related-skills, input/output formats, and error guidance.\n- Updated the loading flow: refers to the new governance reference when identifying or repaying test debt.\n- Removed obsolete `skill-card.md`; improved license and usage notes.\n- General polish and clarifications, no core logic changes to workflow or guidance.\n\nv1.7.7 | 2026-09-27T14:41:42.601Z | user\n\n1.7.7\n\nv1.7.6 | 2026-09-01T12:47:01.051Z | user\n\n显示名改中文\n\nv1.7.5 | 2026-08-30T15:19:52.381Z | user\n\n1.7.5: 版本号升级\n\nv1.7.0 | 2026-08-16T14:33:03.240Z | auto\n\nVersion 1.7.0 – Cleanup and documentation update.\n\n- Removed redundant file: skill-card.md.\n- Updated SKILL.md version and metadata to 1.7.0.\n- No changes to technical content or logic.\n\nv1.6.3 | 2026-08-12T15:28:46.099Z | auto\n\n- Added slug and displayName fields to SKILL.md; updated version to 1.6.3.\n- Minor formatting and metadata improvements in SKILL.md for clarity and consistency.\n- Removed deprecated skill-card.md file.\n\nv1.6.0 | 2026-07-06T17:18:00.101Z | auto\n\nVersion 1.6.0\n\n- Added categories, depth requirement quantification, and error recovery guidance fields for clearer usage context and process control.\n- Enhanced output format with traceability requirements for each debt item.\n- Included a security warning highlighting evaluation risks and workspace-only output scope.\n- Removed the file skill-card.md for simplification and maintenance.\n- No core workflow logic was changed; all existing principles, processes, and examples remain unaltered.\n\nv1.5.0 | 2026-06-29T12:36:05.745Z | auto\n\nVersion 1.5.0 – 技能结构升级，聚焦“系统性技术债务管理”\n\n- 技能描述和定位显著优化，强调识别技术债务根因与“还款”策略，突出系统性治理理念。\n- 更新 input/output 格式：输入增加“测试报告”“代码质量数据”等结构化要求，输出包含“债务清单、影响分析、偿还计划、预防策略”四部分。\n- 移除 skill-card.md，精简文档结构，内容前后一致。\n- 细化输出示例与典型场景，强调不要对 flaky test 只做被动修复。\n- 保留原有债务类型、评估矩阵、治理方法、预防措施内容，统一排版与文本格式。\n\nv1.4.1 | 2026-06-25T16:57:01.136Z | auto\n\n- Skill description simplified for clarity and focus on system化技术债务管理场景\n- Removed the file skill-card.md\n- Refined skill activation scenarios for more direct triggering\n- No changes to functional content or workflow in guidance and methodology sections\n\nv1.4.0 | 2026-06-24T05:12:53.689Z | auto\n\n- Expanded the skill description with new keywords: “债务治理”, “维护成本”, “债务评估”, “债务追踪”, “重构优先级”, “投资回报率”, “债务量化”.\n- Broadened trigger conditions in when_to_use to cover more scenarios including debt governance and maintenance cost evaluation.\n- Removed the file: skill-card.md.\n- No changes to technical content or procedures in skill logic.\n\nv1.3.0 | 2026-06-23T10:50:28.114Z | auto\n\nVersion 1.3.0 Summary: Major enhancement with comprehensive guidelines, classifications, and practical templates for QA技术债务管理.\n\n- Expanded and detailed definitions of 自动化债务, 测试债务, and 架构债务 with clear表现 and细分类别.\n- Introduced系统化评估维度与优先级矩阵, supporting debt prioritization and action planning.\n- Added step-by-step治理策略与具体治理方法 for each debt type.\n- Included债务预防措施, promoting best practices, code quality, and team improvement.\n- Provided a markdown技术债务看板 template for team tracking and status visibility.\n- Supplemented实际例子 and checklist to guide practical adoption and ensure process completeness.\n\nArchive index:\n\nArchive v1.8.0: 4 files, 6042 bytes\n\nFiles: references/debt-governance.md (2074b), skill-card.md (2040b), SKILL.md (7820b), _meta.json (142b)\n\nFile v1.8.0:SKILL.md\n\n---\nname: qa-tech-debt-management\ndescription: >-\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans.\nlicense: MIT\nallowed-tools: Read Grep Glob Bash\nmetadata:\n display-name: \"Tech Debt Management\"\n version: \"1.8.0\"\n when-to-use: \"用户说\\\"技术债务\\\"、\\\"测试债务\\\"、\\\"自动化债务\\\"、\\\"重构\\\"、\\\"债务治理\\\"、\\\"维护成本\\\"、需要管理技术债务、自动化维护成本高需要评估时\"\n related-skills: \"{\\\"upstream\\\":[\\\"qa-test-automation-arch\\\",\\\"qa-quality-metrics\\\"],\\\"downstream\\\":[\\\"qa-retrospective\\\",\\\"qa-test-strategy-design\\\"]}\"\n references: \"[\\\"references/debt-governance.md\\\"]\"\n input-format: \"{\\\"required\\\":[{\\\"name\\\":\\\"测试报告\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"来自qa-test-reporting的测试报告\\\"},{\\\"name\\\":\\\"代码质量数据\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"代码质量分析数据\\\"}],\\\"optional\\\":[{\\\"name\\\":\\\"历史基线\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"历史技术债务基线\\\"}]}\"\n output-format: \"{\\\"traceability\\\":[\\\"本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\\\"],\\\"structure\\\":[\\\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\\\\\"全覆盖/100%\\\\\\\"绝对化表述；缺失模块标注\\\\\\\"未覆盖+原因\\\\\\\"\\\",{\\\"debt_inventory\\\":\\\"技术债务清单\\\"},{\\\"impact_analysis\\\":\\\"影响分析\\\"},{\\\"repayment_plan\\\":\\\"偿还计划\\\"},{\\\"prevention_strategies\\\":\\\"预防策略\\\"}]}\"\n error-recovery-guidance: \"{\\\"on_failure\\\":\\\"债务治理遗漏高优债务时回退到质量度量补充数据\\\",\\\"retry_behavior\\\":\\\"补充数据后重新评估治理优先级\\\"}\"\n categories: \"[\\\"Development\\\",\\\"Testing\\\"]\"\n depth-requirement: \"{\\\"reference_value\\\":\\\"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\\\",\\\"minimum\\\":\\\"至少完成债务识别、成本评估、治理优先级3步\\\"}\"\n---\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 技术债务管理\n\n## 核心原则\n\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\n\n## 技术债务类型\n\n### 自动化债务\n\n```text\n债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差\n```\n\n### 测试债务\n\n```text\n债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱\n```\n\n### 架构债务\n\n```text\n债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一\n```\n\n## 债务评估\n\n### 评估维度\n\n```text\n├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低\n```\n\n### 评估矩阵\n\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\n|---------|--------|--------|---------|---------|--------|\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\n\n## 加载时机\n\n| 什么时候读 | 读哪个 |\n|-----------|--------|\n| 识别/评估/偿还测试债时 | [`references/debt-governance.md`](references/debt-governance.md) |\n\n> `债务治理`的完整内容已下沉至 `references/debt-governance.md`，避免每次触发都占用上下文。\n\n## 债务预防\n\n### 预防措施\n\n```text\n├─ 代码质量\n│ ├─ 代码评审\n│ ├─ 静态分析\n│ ├─ 测试覆盖\n│ └─ 重构习惯\n│\n├─ 流程规范\n│ ├─ 流程文档化\n│ ├─ 执行标准化\n│ ├─ 定期Review\n│ └─ 持续改进\n│\n├─ 团队能力\n│ ├─ 培训提升\n│ ├─ 知识共享\n│ ├─ 经验沉淀\n│ └─ 最佳实践\n│\n└─ 工具支持\n ├─ 工具自动化\n ├─ 工具标准化\n ├─ 工具维护\n └─ 工具升级\n```\n\n## 债务看板\n\n```markdown\n## 技术债务看板\n\n### P0（立即解决）\n- [ ] 自动化脚本频繁失败\n- [ ] 测试环境不稳定\n\n### P1（计划解决）\n- [ ] 核心流程自动化覆盖不足\n- [ ] 用例过时需要更新\n\n### P2（逐步解决）\n- [ ] 框架版本需要升级\n- [ ] 测试数据管理需要改进\n\n### P3（持续监控）\n- [ ] 测试文档需要完善\n- [ ] 工具链需要统一\n```\n\n## 输出示例\n\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\n\n**代码覆盖率从80%降到了60%**\n→ 识别测试债务：增量代码缺乏单元测试覆盖\n→ 排期治理：每迭代拿出20%容量偿还测试债务\n\n## 检查清单\n\n技术债务管理完成后检查：\n- [ ] 债务是否识别完整？\n- [ ] 债务评估是否准确？\n- [ ] 治理策略是否制定？\n- [ ] 治理计划是否执行？\n- [ ] 预防措施是否实施？\n- [ ] 债务看板是否维护？\n\nFile v1.8.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.8.0\",\n \"publishedAt\": 1790656133285\n}\n\nFile v1.8.0:references/debt-governance.md\n\n# 测试技术债治理详解\n\n> 本文是 `qa-tech-debt-management` 的**测试技术债治理详解**。识别/评估/偿还测试债时读本文；\n其余部分留在 SKILL.md，不必读本文。\n\n---\n\n\n### 治理策略\n\n```text\n├─ 立即解决（P0）\n│ ├─ 阻塞性问题\n│ ├─ 线上问题\n│ └─ 效率严重下降\n│\n├─ 计划解决（P1）\n│ ├─ 影响当前迭代\n│ ├─ 影响团队效率\n│ └─ 风险较高\n│\n├─ 逐步解决（P2）\n│ ├─ 不影响当前工作\n│ ├─ 可以规划解决\n│ └─ 成本较高\n│\n└─ 持续监控（P3）\n ├─ 影响较小\n ├─ 成本较高\n └─ 可以接受\n```\n\n### 治理方法\n\n```text\n自动化债务治理：\n├─ 脚本稳定化\n│ ├─ 修复假阳性\n│ ├─ 优化等待策略\n│ ├─ 增加重试机制\n│ └─ 改进错误处理\n│\n├─ 覆盖提升\n│ ├─ 补充核心流程\n│ ├─ 补充边界场景\n│ ├─ 补充异常场景\n│ └─ 优化测试数据\n│\n└─ 框架升级\n ├─ 版本升级\n ├─ 架构优化\n ├─ 文档完善\n └─ 工具统一\n\n测试债务治理：\n├─ 用例优化\n│ ├─ 清理过时用例\n│ ├─ 合并冗余用例\n│ ├─ 补充覆盖不足\n│ └─ 改进可维护性\n│\n├─ 流程改进\n│ ├─ 规范测试流程\n│ ├─ 完善执行标准\n│ ├─ 改进缺陷管理\n│ └─ 优化回归策略\n│\n└─ 环境改善\n ├─ 稳定测试环境\n ├─ 补充测试数据\n ├─ 升级测试工具\n └─ 完善基础设施\n\n架构债务治理：\n├─ 可测试性改进\n│ ├─ 接口Mock化\n│ ├─ 日志完善\n│ ├─ 配置动态化\n│ └─ 数据构造化\n│\n├─ 架构优化\n│ ├─ 分层清晰化\n│ ├─ 职责单一化\n│ ├─ 扩展性提升\n│ └─ 可维护性提升\n│\n└─ 集成完善\n ├─ CI/CD完善\n ├─ 报告规范化\n ├─ 监控完善\n └─ 工具链统一\n```\n\nFile v1.8.0:skill-card.md\n\n## Description:\n\nHelps QA and engineering teams identify test automation and test-asset debt, estimate maintenance and remediation costs, and plan staged repayment.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA practitioners and developers use this skill to inventory automation, testing, and architecture debt, prioritize remediation by impact and cost, and develop repayment and prevention plans.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad activation terms may invoke the Chinese-language workflow for unrelated requests.\n\nMitigation: Confirm the request concerns QA technical debt and that the workflow language suits the team.\n\nRisk: The optional full skill-set install command does not pin a reviewed version.\n\nMitigation: Verify the source and pin or review the version before running the install command.\n\nRisk: Debt assessments may influence release-blocking or feature-retirement decisions.\n\nMitigation: Confirm the supporting data and discuss risks with development and product owners before acting.\n\n## Reference(s):\n\n- [Test technical-debt governance guide](references/debt-governance.md)\n- [ClawHub skill listing](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Guidance]\n\n**Output Format:** [Markdown debt inventory, impact analysis, repayment plan, and prevention strategies]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Reports are written to the workspace; debt items retain related defect or automation-architecture IDs when available.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill metadata and ClawHub release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.7: 3 files, 5171 bytes\n\nFiles: skill-card.md (1834b), SKILL.md (9272b), _meta.json (142b)\n\nFile v1.7.7:SKILL.md\n\n---\nname: qa-tech-debt-management\nslug: qa-tech-debt-management\ndisplayName: Tech Debt Management\nversion: 1.7.7\ndescription: >-\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\n\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\nallowed-tools: Read Grep Glob Bash\nrelated_skills:\n upstream:\n - qa-test-automation-arch # 输入：自动化架构评估\n - qa-quality-metrics # 输入：质量度量数据\n downstream:\n - qa-retrospective # 输出：债务分析用于复盘\n - qa-test-strategy-design # 输出：债务治理影响测试策略\ninput_format:\n required:\n - name: 测试报告\n type: object\n description: 来自qa-test-reporting的测试报告\n - name: 代码质量数据\n type: object\n description: 代码质量分析数据\n optional:\n - name: 历史基线\n type: object\n description: 历史技术债务基线\noutput_format:\n traceability:\n - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\n structure:\n - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\n - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n - debt_inventory: 技术债务清单\n - impact_analysis: 影响分析\n - repayment_plan: 偿还计划\n - prevention_strategies: 预防策略\ncategories: ['Development','Testing']\ndepth_requirement_quantification:\n reference_value: \"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\"\n minimum: \"至少完成债务识别、成本评估、治理优先级3步\"\nerror_recovery_guidance:\n on_failure: \"债务治理遗漏高优债务时回退到质量度量补充数据\"\n retry_behavior: \"补充数据后重新评估治理优先级\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 技术债务管理\n\n## 核心原则\n\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\n\n## 技术债务类型\n\n### 自动化债务\n\n```text\n债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差\n```\n\n### 测试债务\n\n```text\n债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱\n```\n\n### 架构债务\n\n```text\n债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一\n```\n\n## 债务评估\n\n### 评估维度\n\n```text\n├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低\n```\n\n### 评估矩阵\n\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\n|---------|--------|--------|---------|---------|--------|\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\n\n## 债务治理\n\n### 治理策略\n\n```text\n├─ 立即解决（P0）\n│ ├─ 阻塞性问题\n│ ├─ 线上问题\n│ └─ 效率严重下降\n│\n├─ 计划解决（P1）\n│ ├─ 影响当前迭代\n│ ├─ 影响团队效率\n│ └─ 风险较高\n│\n├─ 逐步解决（P2）\n│ ├─ 不影响当前工作\n│ ├─ 可以规划解决\n│ └─ 成本较高\n│\n└─ 持续监控（P3）\n ├─ 影响较小\n ├─ 成本较高\n └─ 可以接受\n```\n\n### 治理方法\n\n```text\n自动化债务治理：\n├─ 脚本稳定化\n│ ├─ 修复假阳性\n│ ├─ 优化等待策略\n│ ├─ 增加重试机制\n│ └─ 改进错误处理\n│\n├─ 覆盖提升\n│ ├─ 补充核心流程\n│ ├─ 补充边界场景\n│ ├─ 补充异常场景\n│ └─ 优化测试数据\n│\n└─ 框架升级\n ├─ 版本升级\n ├─ 架构优化\n ├─ 文档完善\n └─ 工具统一\n\n测试债务治理：\n├─ 用例优化\n│ ├─ 清理过时用例\n│ ├─ 合并冗余用例\n│ ├─ 补充覆盖不足\n│ └─ 改进可维护性\n│\n├─ 流程改进\n│ ├─ 规范测试流程\n│ ├─ 完善执行标准\n│ ├─ 改进缺陷管理\n│ └─ 优化回归策略\n│\n└─ 环境改善\n ├─ 稳定测试环境\n ├─ 补充测试数据\n ├─ 升级测试工具\n └─ 完善基础设施\n\n架构债务治理：\n├─ 可测试性改进\n│ ├─ 接口Mock化\n│ ├─ 日志完善\n│ ├─ 配置动态化\n│ └─ 数据构造化\n│\n├─ 架构优化\n│ ├─ 分层清晰化\n│ ├─ 职责单一化\n│ ├─ 扩展性提升\n│ └─ 可维护性提升\n│\n└─ 集成完善\n ├─ CI/CD完善\n ├─ 报告规范化\n ├─ 监控完善\n └─ 工具链统一\n```\n\n## 债务预防\n\n### 预防措施\n\n```text\n├─ 代码质量\n│ ├─ 代码评审\n│ ├─ 静态分析\n│ ├─ 测试覆盖\n│ └─ 重构习惯\n│\n├─ 流程规范\n│ ├─ 流程文档化\n│ ├─ 执行标准化\n│ ├─ 定期Review\n│ └─ 持续改进\n│\n├─ 团队能力\n│ ├─ 培训提升\n│ ├─ 知识共享\n│ ├─ 经验沉淀\n│ └─ 最佳实践\n│\n└─ 工具支持\n ├─ 工具自动化\n ├─ 工具标准化\n ├─ 工具维护\n └─ 工具升级\n```\n\n## 债务看板\n\n```markdown\n## 技术债务看板\n\n### P0（立即解决）\n- [ ] 自动化脚本频繁失败\n- [ ] 测试环境不稳定\n\n### P1（计划解决）\n- [ ] 核心流程自动化覆盖不足\n- [ ] 用例过时需要更新\n\n### P2（逐步解决）\n- [ ] 框架版本需要升级\n- [ ] 测试数据管理需要改进\n\n### P3（持续监控）\n- [ ] 测试文档需要完善\n- [ ] 工具链需要统一\n```\n\n## 输出示例\n\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\n\n**代码覆盖率从80%降到了60%**\n→ 识别测试债务：增量代码缺乏单元测试覆盖\n→ 排期治理：每迭代拿出20%容量偿还测试债务\n\n## 检查清单\n\n技术债务管理完成后检查：\n- [ ] 债务是否识别完整？\n- [ ] 债务评估是否准确？\n- [ ] 治理策略是否制定？\n- [ ] 治理计划是否执行？\n- [ ] 预防措施是否实施？\n- [ ] 债务看板是否维护？\n\nFile v1.7.7:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.7.7\",\n \"publishedAt\": 1790520102601\n}\n\nFile v1.7.7:skill-card.md\n\n## Description:\n\nIdentifies QA automation and test-asset debt, estimates maintenance and remediation costs, and proposes a phased repayment plan.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers and development teams use this skill to inventory test automation, test-process, and testability debt, prioritize it by impact and cost, and plan remediation and prevention.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad refactoring or maintenance-cost discussions may activate this Chinese-language QA workflow unexpectedly.\n\nMitigation: Review whether the workflow fits the request before applying its recommendations.\n\nRisk: Debt priorities or production-impact estimates could be mistaken for a release-blocking decision.\n\nMitigation: Confirm release or feature-removal decisions with development and product owners before acting.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n\n## Skill Output:\n\n**Output Type(s):** [Analysis, Markdown, Guidance]\n\n**Output Format:** [Markdown debt inventory, impact analysis, prioritized repayment plan, and prevention strategies]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include tabular test cases and a debt-tracking board; links debt items to related defect or architecture IDs where available.]\n\n## Skill Version(s):\n\n1.7.7 (source: frontmatter and server-resolved release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.6: 3 files, 5423 bytes\n\nFiles: skill-card.md (2039b), SKILL.md (9898b), _meta.json (142b)\n\nFile v1.7.6:SKILL.md\n\n---\r\nname: qa-tech-debt-management\r\nslug: qa-tech-debt-management\r\ndisplayName: 测试技术债管理\r\nversion: 1.7.5\r\ndescription: >-\r\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\r\n 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills\r\n\r\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\r\nallowed-tools: Read Grep Glob Bash\r\nrelated_skills:\r\n upstream:\r\n - qa-test-automation-arch # 输入：自动化架构评估\r\n - qa-quality-metrics # 输入：质量度量数据\r\n downstream:\r\n - qa-retrospective # 输出：债务分析用于复盘\r\n - qa-test-strategy-design # 输出：债务治理影响测试策略\r\ninput_format:\r\n required:\r\n - name: 测试报告\r\n type: object\r\n description: 来自qa-test-reporting的测试报告\r\n - name: 代码质量数据\r\n type: object\r\n description: 代码质量分析数据\r\n optional:\r\n - name: 历史基线\r\n type: object\r\n description: 历史技术债务基线\r\noutput_format:\r\n traceability:\r\n - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\r\n structure:\r\n - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\r\n - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\r\n - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\r\n - debt_inventory: 技术债务清单\r\n - impact_analysis: 影响分析\r\n - repayment_plan: 偿还计划\r\n - prevention_strategies: 预防策略\r\ncategories: ['Development','Testing']\r\ndepth_requirement_quantification:\r\n reference_value: \"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\"\r\n minimum: \"至少完成债务识别、成本评估、治理优先级3步\"\r\nerror_recovery_guidance:\r\n on_failure: \"债务治理遗漏高优债务时回退到质量度量补充数据\"\r\n retry_behavior: \"补充数据后重新评估治理优先级\"\r\n---\r\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\r\n\r\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\r\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\r\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\r\n\r\n# 技术债务管理\r\n\r\n## 核心原则\r\n\r\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\r\n\r\n## 技术债务类型\r\n\r\n### 自动化债务\r\n\r\n```text\r\n债务表现：\r\n├─ 自动化脚本不稳定\r\n│ ├─ 频繁失败（假阳性）\r\n│ ├─ 执行时间过长\r\n│ └─ 维护成本高\r\n│\r\n├─ 自动化覆盖不足\r\n│ ├─ 核心流程未覆盖\r\n│ ├─ 边界场景未覆盖\r\n│ └─ 异常场景未覆盖\r\n│\r\n├─ 框架问题\r\n│ ├─ 框架版本过旧\r\n│ ├─ 框架设计不合理\r\n│ └─ 框架文档缺失\r\n│\r\n└─ 代码质量\r\n ├─ 代码重复\r\n ├─ 代码复杂度高\r\n └─ 代码可读性差\r\n```\r\n\r\n### 测试债务\r\n\r\n```text\r\n债务表现：\r\n├─ 用例问题\r\n│ ├─ 用例过时\r\n│ ├─ 用例冗余\r\n│ ├─ 用例覆盖不足\r\n│ └─ 用例维护困难\r\n│\r\n├─ 流程问题\r\n│ ├─ 测试流程不规范\r\n│ ├─ 测试执行不彻底\r\n│ ├─ 缺陷管理混乱\r\n│ └─ 回归测试不充分\r\n│\r\n└─ 环境问题\r\n ├─ 测试环境不稳定\r\n ├─ 测试数据不足\r\n ├─ 测试工具落后\r\n └─ 测试基础设施薄弱\r\n```\r\n\r\n### 架构债务\r\n\r\n```text\r\n债务表现：\r\n├─ 可测试性差\r\n│ ├─ 接口不可Mock\r\n│ ├─ 日志不完整\r\n│ ├─ 配置不灵活\r\n│ └─ 数据不可构造\r\n│\r\n├─ 测试架构问题\r\n│ ├─ 分层不清晰\r\n│ ├─ 职责不单一\r\n│ ├─ 扩展性差\r\n│ └─ 可维护性差\r\n│\r\n└─ 集成问题\r\n ├─ CI/CD集成不完善\r\n ├─ 报告不规范\r\n ├─ 监控不完善\r\n └─ 工具链不统一\r\n```\r\n\r\n## 债务评估\r\n\r\n### 评估维度\r\n\r\n```text\r\n├─ 影响度\r\n│ ├─ 对测试效率的影响\r\n│ ├─ 对测试质量的影响\r\n│ ├─ 对团队士气的影响\r\n│ └─ 对交付速度的影响\r\n│\r\n├─ 紧迫度\r\n│ ├─ 是否阻塞当前工作\r\n│ ├─ 是否影响发布\r\n│ ├─ 是否导致线上问题\r\n│ └─ 是否影响团队效率\r\n│\r\n├─ 解决成本\r\n│ ├─ 人力成本\r\n│ ├─ 时间成本\r\n│ ├─ 风险成本\r\n│ └─ 机会成本\r\n│\r\n└─ 解决收益\r\n ├─ 效率提升\r\n ├─ 质量提升\r\n ├─ 成本降低\r\n └─ 风险降低\r\n```\r\n\r\n### 评估矩阵\r\n\r\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\r\n|---------|--------|--------|---------|---------|--------|\r\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\r\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\r\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\r\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\r\n\r\n## 债务治理\r\n\r\n### 治理策略\r\n\r\n```text\r\n├─ 立即解决（P0）\r\n│ ├─ 阻塞性问题\r\n│ ├─ 线上问题\r\n│ └─ 效率严重下降\r\n│\r\n├─ 计划解决（P1）\r\n│ ├─ 影响当前迭代\r\n│ ├─ 影响团队效率\r\n│ └─ 风险较高\r\n│\r\n├─ 逐步解决（P2）\r\n│ ├─ 不影响当前工作\r\n│ ├─ 可以规划解决\r\n│ └─ 成本较高\r\n│\r\n└─ 持续监控（P3）\r\n ├─ 影响较小\r\n ├─ 成本较高\r\n └─ 可以接受\r\n```\r\n\r\n### 治理方法\r\n\r\n```text\r\n自动化债务治理：\r\n├─ 脚本稳定化\r\n│ ├─ 修复假阳性\r\n│ ├─ 优化等待策略\r\n│ ├─ 增加重试机制\r\n│ └─ 改进错误处理\r\n│\r\n├─ 覆盖提升\r\n│ ├─ 补充核心流程\r\n│ ├─ 补充边界场景\r\n│ ├─ 补充异常场景\r\n│ └─ 优化测试数据\r\n│\r\n└─ 框架升级\r\n ├─ 版本升级\r\n ├─ 架构优化\r\n ├─ 文档完善\r\n └─ 工具统一\r\n\r\n测试债务治理：\r\n├─ 用例优化\r\n│ ├─ 清理过时用例\r\n│ ├─ 合并冗余用例\r\n│ ├─ 补充覆盖不足\r\n│ └─ 改进可维护性\r\n│\r\n├─ 流程改进\r\n│ ├─ 规范测试流程\r\n│ ├─ 完善执行标准\r\n│ ├─ 改进缺陷管理\r\n│ └─ 优化回归策略\r\n│\r\n└─ 环境改善\r\n ├─ 稳定测试环境\r\n ├─ 补充测试数据\r\n ├─ 升级测试工具\r\n └─ 完善基础设施\r\n\r\n架构债务治理：\r\n├─ 可测试性改进\r\n│ ├─ 接口Mock化\r\n│ ├─ 日志完善\r\n│ ├─ 配置动态化\r\n│ └─ 数据构造化\r\n│\r\n├─ 架构优化\r\n│ ├─ 分层清晰化\r\n│ ├─ 职责单一化\r\n│ ├─ 扩展性提升\r\n│ └─ 可维护性提升\r\n│\r\n└─ 集成完善\r\n ├─ CI/CD完善\r\n ├─ 报告规范化\r\n ├─ 监控完善\r\n └─ 工具链统一\r\n```\r\n\r\n## 债务预防\r\n\r\n### 预防措施\r\n\r\n```text\r\n├─ 代码质量\r\n│ ├─ 代码评审\r\n│ ├─ 静态分析\r\n│ ├─ 测试覆盖\r\n│ └─ 重构习惯\r\n│\r\n├─ 流程规范\r\n│ ├─ 流程文档化\r\n│ ├─ 执行标准化\r\n│ ├─ 定期Review\r\n│ └─ 持续改进\r\n│\r\n├─ 团队能力\r\n│ ├─ 培训提升\r\n│ ├─ 知识共享\r\n│ ├─ 经验沉淀\r\n│ └─ 最佳实践\r\n│\r\n└─ 工具支持\r\n ├─ 工具自动化\r\n ├─ 工具标准化\r\n ├─ 工具维护\r\n └─ 工具升级\r\n```\r\n\r\n## 债务看板\r\n\r\n```markdown\r\n## 技术债务看板\r\n\r\n### P0（立即解决）\r\n- [ ] 自动化脚本频繁失败\r\n- [ ] 测试环境不稳定\r\n\r\n### P1（计划解决）\r\n- [ ] 核心流程自动化覆盖不足\r\n- [ ] 用例过时需要更新\r\n\r\n### P2（逐步解决）\r\n- [ ] 框架版本需要升级\r\n- [ ] 测试数据管理需要改进\r\n\r\n### P3（持续监控）\r\n- [ ] 测试文档需要完善\r\n- [ ] 工具链需要统一\r\n```\r\n\r\n## 输出示例\r\n\r\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\r\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\r\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\r\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\r\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\r\n\r\n**代码覆盖率从80%降到了60%**\r\n→ 识别测试债务：增量代码缺乏单元测试覆盖\r\n→ 排期治理：每迭代拿出20%容量偿还测试债务\r\n\r\n## 检查清单\r\n\r\n技术债务管理完成后检查：\r\n- [ ] 债务是否识别完整？\r\n- [ ] 债务评估是否准确？\r\n- [ ] 治理策略是否制定？\r\n- [ ] 治理计划是否执行？\r\n- [ ] 预防措施是否实施？\r\n- [ ] 债务看板是否维护？\n\nFile v1.7.6:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.7.6\",\n \"publishedAt\": 1788266821051\n}\n\nFile v1.7.6:skill-card.md\n\n## Description:\n\nHelps QA teams identify testing and automation technical debt, estimate maintenance and rewrite costs, and produce a phased repayment plan.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, test automation maintainers, and engineering leads use this skill to assess flaky tests, outdated cases, coverage gaps, framework debt, and testing process debt. It guides debt inventory, impact analysis, repayment planning, and prevention strategy creation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill points users to an unpinned external npx installation path for the broader QA Test Skills bundle.\n\nMitigation: Review and pin the external package before installation, inspect the fetched bundle, and run it in a sandboxed environment.\n\nRisk: The skill can produce release-blocking or production-impact assessments that may be incorrect or incomplete.\n\nMitigation: Treat assessments as advisory and require human review with development and product stakeholders before blocking releases or changing production behavior.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, guidance]\n\n**Output Format:** [Markdown with structured tables, checklists, and inline shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Outputs may include a debt inventory, impact analysis, repayment plan, prevention strategies, and traceability to related defect or automation architecture IDs.]\n\n## Skill Version(s):\n\n1.7.6 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.5: 3 files, 5166 bytes\n\nFiles: skill-card.md (1984b), SKILL.md (9272b), _meta.json (142b)\n\nFile v1.7.5:SKILL.md\n\n---\nname: qa-tech-debt-management\nslug: qa-tech-debt-management\ndisplayName: Tech Debt Management\nversion: 1.7.5\ndescription: >-\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\n\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\nallowed-tools: Read Grep Glob Bash\nrelated_skills:\n upstream:\n - qa-test-automation-arch # 输入：自动化架构评估\n - qa-quality-metrics # 输入：质量度量数据\n downstream:\n - qa-retrospective # 输出：债务分析用于复盘\n - qa-test-strategy-design # 输出：债务治理影响测试策略\ninput_format:\n required:\n - name: 测试报告\n type: object\n description: 来自qa-test-reporting的测试报告\n - name: 代码质量数据\n type: object\n description: 代码质量分析数据\n optional:\n - name: 历史基线\n type: object\n description: 历史技术债务基线\noutput_format:\n traceability:\n - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\n structure:\n - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\n - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n - debt_inventory: 技术债务清单\n - impact_analysis: 影响分析\n - repayment_plan: 偿还计划\n - prevention_strategies: 预防策略\ncategories: ['Development','Testing']\ndepth_requirement_quantification:\n reference_value: \"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\"\n minimum: \"至少完成债务识别、成本评估、治理优先级3步\"\nerror_recovery_guidance:\n on_failure: \"债务治理遗漏高优债务时回退到质量度量补充数据\"\n retry_behavior: \"补充数据后重新评估治理优先级\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 技术债务管理\n\n## 核心原则\n\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\n\n## 技术债务类型\n\n### 自动化债务\n\n```text\n债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差\n```\n\n### 测试债务\n\n```text\n债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱\n```\n\n### 架构债务\n\n```text\n债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一\n```\n\n## 债务评估\n\n### 评估维度\n\n```text\n├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低\n```\n\n### 评估矩阵\n\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\n|---------|--------|--------|---------|---------|--------|\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\n\n## 债务治理\n\n### 治理策略\n\n```text\n├─ 立即解决（P0）\n│ ├─ 阻塞性问题\n│ ├─ 线上问题\n│ └─ 效率严重下降\n│\n├─ 计划解决（P1）\n│ ├─ 影响当前迭代\n│ ├─ 影响团队效率\n│ └─ 风险较高\n│\n├─ 逐步解决（P2）\n│ ├─ 不影响当前工作\n│ ├─ 可以规划解决\n│ └─ 成本较高\n│\n└─ 持续监控（P3）\n ├─ 影响较小\n ├─ 成本较高\n └─ 可以接受\n```\n\n### 治理方法\n\n```text\n自动化债务治理：\n├─ 脚本稳定化\n│ ├─ 修复假阳性\n│ ├─ 优化等待策略\n│ ├─ 增加重试机制\n│ └─ 改进错误处理\n│\n├─ 覆盖提升\n│ ├─ 补充核心流程\n│ ├─ 补充边界场景\n│ ├─ 补充异常场景\n│ └─ 优化测试数据\n│\n└─ 框架升级\n ├─ 版本升级\n ├─ 架构优化\n ├─ 文档完善\n └─ 工具统一\n\n测试债务治理：\n├─ 用例优化\n│ ├─ 清理过时用例\n│ ├─ 合并冗余用例\n│ ├─ 补充覆盖不足\n│ └─ 改进可维护性\n│\n├─ 流程改进\n│ ├─ 规范测试流程\n│ ├─ 完善执行标准\n│ ├─ 改进缺陷管理\n│ └─ 优化回归策略\n│\n└─ 环境改善\n ├─ 稳定测试环境\n ├─ 补充测试数据\n ├─ 升级测试工具\n └─ 完善基础设施\n\n架构债务治理：\n├─ 可测试性改进\n│ ├─ 接口Mock化\n│ ├─ 日志完善\n│ ├─ 配置动态化\n│ └─ 数据构造化\n│\n├─ 架构优化\n│ ├─ 分层清晰化\n│ ├─ 职责单一化\n│ ├─ 扩展性提升\n│ └─ 可维护性提升\n│\n└─ 集成完善\n ├─ CI/CD完善\n ├─ 报告规范化\n ├─ 监控完善\n └─ 工具链统一\n```\n\n## 债务预防\n\n### 预防措施\n\n```text\n├─ 代码质量\n│ ├─ 代码评审\n│ ├─ 静态分析\n│ ├─ 测试覆盖\n│ └─ 重构习惯\n│\n├─ 流程规范\n│ ├─ 流程文档化\n│ ├─ 执行标准化\n│ ├─ 定期Review\n│ └─ 持续改进\n│\n├─ 团队能力\n│ ├─ 培训提升\n│ ├─ 知识共享\n│ ├─ 经验沉淀\n│ └─ 最佳实践\n│\n└─ 工具支持\n ├─ 工具自动化\n ├─ 工具标准化\n ├─ 工具维护\n └─ 工具升级\n```\n\n## 债务看板\n\n```markdown\n## 技术债务看板\n\n### P0（立即解决）\n- [ ] 自动化脚本频繁失败\n- [ ] 测试环境不稳定\n\n### P1（计划解决）\n- [ ] 核心流程自动化覆盖不足\n- [ ] 用例过时需要更新\n\n### P2（逐步解决）\n- [ ] 框架版本需要升级\n- [ ] 测试数据管理需要改进\n\n### P3（持续监控）\n- [ ] 测试文档需要完善\n- [ ] 工具链需要统一\n```\n\n## 输出示例\n\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\n\n**代码覆盖率从80%降到了60%**\n→ 识别测试债务：增量代码缺乏单元测试覆盖\n→ 排期治理：每迭代拿出20%容量偿还测试债务\n\n## 检查清单\n\n技术债务管理完成后检查：\n- [ ] 债务是否识别完整？\n- [ ] 债务评估是否准确？\n- [ ] 治理策略是否制定？\n- [ ] 治理计划是否执行？\n- [ ] 预防措施是否实施？\n- [ ] 债务看板是否维护？\n\nFile v1.7.5:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.7.5\",\n \"publishedAt\": 1788103192381\n}\n\nFile v1.7.5:skill-card.md\n\n## Description:\n\nThis skill helps QA and engineering teams identify test automation and testing asset technical debt, estimate maintenance and rewrite costs, and plan phased repayment.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, QA engineers, and test leads use this skill when automation maintenance costs, flaky tests, testing debt, or refactoring needs require a structured debt inventory, impact analysis, repayment plan, and prevention strategy.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Debt analysis could be overused as a release-blocking signal.\n\nMitigation: Review conclusions with engineering and product teams before blocking releases, taking systems offline, or making operational decisions.\n\nRisk: Broad trigger terms such as technical debt, refactoring, and maintenance cost could activate the skill unintentionally.\n\nMitigation: Narrow activation terms during installation if accidental activation would disrupt normal QA or engineering workflows.\n\n## Reference(s):\n\n- [ClawHub skill release page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown analysis with structured debt inventory, impact analysis, repayment plan, and prevention strategies.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Local workspace output only; conclusions should be reviewed before they are used for release or operational decisions.]\n\n## Skill Version(s):\n\n1.7.5 (source: SKILL.md frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.0: 3 files, 4988 bytes\n\nFiles: skill-card.md (2111b), SKILL.md (8831b), _meta.json (142b)\n\nFile v1.7.0:SKILL.md\n\n---\nname: qa-tech-debt-management\nslug: qa-tech-debt-management\ndisplayName: Tech Debt Management\nversion: 1.7.0\ndescription: >-\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\n\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\nallowed-tools: Read Grep Glob Bash\nrelated_skills:\n upstream:\n - qa-test-automation-arch # 输入：自动化架构评估\n - qa-quality-metrics # 输入：质量度量数据\n downstream:\n - qa-retrospective # 输出：债务分析用于复盘\n - qa-test-strategy-design # 输出：债务治理影响测试策略\ninput_format:\n required:\n - name: 测试报告\n type: object\n description: 来自qa-test-reporting的测试报告\n - name: 代码质量数据\n type: object\n description: 代码质量分析数据\n optional:\n - name: 历史基线\n type: object\n description: 历史技术债务基线\noutput_format:\n traceability:\n - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\n structure:\n - debt_inventory: 技术债务清单\n - impact_analysis: 影响分析\n - repayment_plan: 偿还计划\n - prevention_strategies: 预防策略\ncategories: ['Development','Testing']\ndepth_requirement_quantification:\n reference_value: \"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\"\n minimum: \"至少完成债务识别、成本评估、治理优先级3步\"\nerror_recovery_guidance:\n on_failure: \"债务治理遗漏高优债务时回退到质量度量补充数据\"\n retry_behavior: \"补充数据后重新评估治理优先级\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 技术债务管理\n\n## 核心原则\n\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\n\n## 技术债务类型\n\n### 自动化债务\n\n```text\n债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差\n```\n\n### 测试债务\n\n```text\n债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱\n```\n\n### 架构债务\n\n```text\n债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一\n```\n\n## 债务评估\n\n### 评估维度\n\n```text\n├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低\n```\n\n### 评估矩阵\n\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\n|---------|--------|--------|---------|---------|--------|\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\n\n## 债务治理\n\n### 治理策略\n\n```text\n├─ 立即解决（P0）\n│ ├─ 阻塞性问题\n│ ├─ 线上问题\n│ └─ 效率严重下降\n│\n├─ 计划解决（P1）\n│ ├─ 影响当前迭代\n│ ├─ 影响团队效率\n│ └─ 风险较高\n│\n├─ 逐步解决（P2）\n│ ├─ 不影响当前工作\n│ ├─ 可以规划解决\n│ └─ 成本较高\n│\n└─ 持续监控（P3）\n ├─ 影响较小\n ├─ 成本较高\n └─ 可以接受\n```\n\n### 治理方法\n\n```text\n自动化债务治理：\n├─ 脚本稳定化\n│ ├─ 修复假阳性\n│ ├─ 优化等待策略\n│ ├─ 增加重试机制\n│ └─ 改进错误处理\n│\n├─ 覆盖提升\n│ ├─ 补充核心流程\n│ ├─ 补充边界场景\n│ ├─ 补充异常场景\n│ └─ 优化测试数据\n│\n└─ 框架升级\n ├─ 版本升级\n ├─ 架构优化\n ├─ 文档完善\n └─ 工具统一\n\n测试债务治理：\n├─ 用例优化\n│ ├─ 清理过时用例\n│ ├─ 合并冗余用例\n│ ├─ 补充覆盖不足\n│ └─ 改进可维护性\n│\n├─ 流程改进\n│ ├─ 规范测试流程\n│ ├─ 完善执行标准\n│ ├─ 改进缺陷管理\n│ └─ 优化回归策略\n│\n└─ 环境改善\n ├─ 稳定测试环境\n ├─ 补充测试数据\n ├─ 升级测试工具\n └─ 完善基础设施\n\n架构债务治理：\n├─ 可测试性改进\n│ ├─ 接口Mock化\n│ ├─ 日志完善\n│ ├─ 配置动态化\n│ └─ 数据构造化\n│\n├─ 架构优化\n│ ├─ 分层清晰化\n│ ├─ 职责单一化\n│ ├─ 扩展性提升\n│ └─ 可维护性提升\n│\n└─ 集成完善\n ├─ CI/CD完善\n ├─ 报告规范化\n ├─ 监控完善\n └─ 工具链统一\n```\n\n## 债务预防\n\n### 预防措施\n\n```text\n├─ 代码质量\n│ ├─ 代码评审\n│ ├─ 静态分析\n│ ├─ 测试覆盖\n│ └─ 重构习惯\n│\n├─ 流程规范\n│ ├─ 流程文档化\n│ ├─ 执行标准化\n│ ├─ 定期Review\n│ └─ 持续改进\n│\n├─ 团队能力\n│ ├─ 培训提升\n│ ├─ 知识共享\n│ ├─ 经验沉淀\n│ └─ 最佳实践\n│\n└─ 工具支持\n ├─ 工具自动化\n ├─ 工具标准化\n ├─ 工具维护\n └─ 工具升级\n```\n\n## 债务看板\n\n```markdown\n## 技术债务看板\n\n### P0（立即解决）\n- [ ] 自动化脚本频繁失败\n- [ ] 测试环境不稳定\n\n### P1（计划解决）\n- [ ] 核心流程自动化覆盖不足\n- [ ] 用例过时需要更新\n\n### P2（逐步解决）\n- [ ] 框架版本需要升级\n- [ ] 测试数据管理需要改进\n\n### P3（持续监控）\n- [ ] 测试文档需要完善\n- [ ] 工具链需要统一\n```\n\n## 输出示例\n\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\n\n**代码覆盖率从80%降到了60%**\n→ 识别测试债务：增量代码缺乏单元测试覆盖\n→ 排期治理：每迭代拿出20%容量偿还测试债务\n\n## 检查清单\n\n技术债务管理完成后检查：\n- [ ] 债务是否识别完整？\n- [ ] 债务评估是否准确？\n- [ ] 治理策略是否制定？\n- [ ] 治理计划是否执行？\n- [ ] 预防措施是否实施？\n- [ ] 债务看板是否维护？\n\nFile v1.7.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.7.0\",\n \"publishedAt\": 1786890783240\n}\n\nFile v1.7.0:skill-card.md\n\n## Description:\n\nThis skill helps QA, test automation, and engineering teams identify automation and test asset technical debt, estimate maintenance and rewrite costs, and plan staged repayment work.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, QA engineers, and test automation owners use this skill when automation cases are costly to maintain, flaky failures are systemic, or test assets need debt inventory, impact analysis, repayment planning, and prevention strategies.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may be triggered for broad refactoring or maintenance-cost discussions outside QA and test automation debt.\n\nMitigation: Use it for QA, testing, automation stability, flaky tests, and test asset debt scenarios; choose a more specific engineering skill for unrelated refactoring work.\n\nRisk: Debt analysis can imply release-blocking or production-risk conclusions.\n\nMitigation: Review those conclusions with engineering and product owners before blocking releases, taking features offline, or changing production plans.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n- [Publisher profile](https://clawhub.ai/user/kokxi)\n\n## Skill Output:\n\n**Output Type(s):** [Analysis, Markdown, Guidance, Files]\n\n**Output Format:** [Markdown with structured debt inventory, impact analysis, repayment plan, prevention strategies, and checklists]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Outputs should preserve traceability to related defect IDs or automation architecture IDs when available.]\n\n## Skill Version(s):\n\n1.7.0 (source: server release evidence and SKILL.md frontmatter)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.6.3: 3 files, 4937 bytes\n\nFiles: skill-card.md (1970b), SKILL.md (8831b), _meta.json (142b)\n\nFile v1.6.3:SKILL.md\n\n---\nname: qa-tech-debt-management\nslug: qa-tech-debt-management\ndisplayName: Tech Debt Management\nversion: 1.6.3\ndescription: >-\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\n\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\nallowed-tools: Read Grep Glob Bash\nrelated_skills:\n upstream:\n - qa-test-automation-arch # 输入：自动化架构评估\n - qa-quality-metrics # 输入：质量度量数据\n downstream:\n - qa-retrospective # 输出：债务分析用于复盘\n - qa-test-strategy-design # 输出：债务治理影响测试策略\ninput_format:\n required:\n - name: 测试报告\n type: object\n description: 来自qa-test-reporting的测试报告\n - name: 代码质量数据\n type: object\n description: 代码质量分析数据\n optional:\n - name: 历史基线\n type: object\n description: 历史技术债务基线\noutput_format:\n traceability:\n - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\n structure:\n - debt_inventory: 技术债务清单\n - impact_analysis: 影响分析\n - repayment_plan: 偿还计划\n - prevention_strategies: 预防策略\ncategories: ['Development','Testing']\ndepth_requirement_quantification:\n reference_value: \"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\"\n minimum: \"至少完成债务识别、成本评估、治理优先级3步\"\nerror_recovery_guidance:\n on_failure: \"债务治理遗漏高优债务时回退到质量度量补充数据\"\n retry_behavior: \"补充数据后重新评估治理优先级\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 技术债务管理\n\n## 核心原则\n\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\n\n## 技术债务类型\n\n### 自动化债务\n\n```text\n债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差\n```\n\n### 测试债务\n\n```text\n债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱\n```\n\n### 架构债务\n\n```text\n债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一\n```\n\n## 债务评估\n\n### 评估维度\n\n```text\n├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低\n```\n\n### 评估矩阵\n\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\n|---------|--------|--------|---------|---------|--------|\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\n\n## 债务治理\n\n### 治理策略\n\n```text\n├─ 立即解决（P0）\n│ ├─ 阻塞性问题\n│ ├─ 线上问题\n│ └─ 效率严重下降\n│\n├─ 计划解决（P1）\n│ ├─ 影响当前迭代\n│ ├─ 影响团队效率\n│ └─ 风险较高\n│\n├─ 逐步解决（P2）\n│ ├─ 不影响当前工作\n│ ├─ 可以规划解决\n│ └─ 成本较高\n│\n└─ 持续监控（P3）\n ├─ 影响较小\n ├─ 成本较高\n └─ 可以接受\n```\n\n### 治理方法\n\n```text\n自动化债务治理：\n├─ 脚本稳定化\n│ ├─ 修复假阳性\n│ ├─ 优化等待策略\n│ ├─ 增加重试机制\n│ └─ 改进错误处理\n│\n├─ 覆盖提升\n│ ├─ 补充核心流程\n│ ├─ 补充边界场景\n│ ├─ 补充异常场景\n│ └─ 优化测试数据\n│\n└─ 框架升级\n ├─ 版本升级\n ├─ 架构优化\n ├─ 文档完善\n └─ 工具统一\n\n测试债务治理：\n├─ 用例优化\n│ ├─ 清理过时用例\n│ ├─ 合并冗余用例\n│ ├─ 补充覆盖不足\n│ └─ 改进可维护性\n│\n├─ 流程改进\n│ ├─ 规范测试流程\n│ ├─ 完善执行标准\n│ ├─ 改进缺陷管理\n│ └─ 优化回归策略\n│\n└─ 环境改善\n ├─ 稳定测试环境\n ├─ 补充测试数据\n ├─ 升级测试工具\n └─ 完善基础设施\n\n架构债务治理：\n├─ 可测试性改进\n│ ├─ 接口Mock化\n│ ├─ 日志完善\n│ ├─ 配置动态化\n│ └─ 数据构造化\n│\n├─ 架构优化\n│ ├─ 分层清晰化\n│ ├─ 职责单一化\n│ ├─ 扩展性提升\n│ └─ 可维护性提升\n│\n└─ 集成完善\n ├─ CI/CD完善\n ├─ 报告规范化\n ├─ 监控完善\n └─ 工具链统一\n```\n\n## 债务预防\n\n### 预防措施\n\n```text\n├─ 代码质量\n│ ├─ 代码评审\n│ ├─ 静态分析\n│ ├─ 测试覆盖\n│ └─ 重构习惯\n│\n├─ 流程规范\n│ ├─ 流程文档化\n│ ├─ 执行标准化\n│ ├─ 定期Review\n│ └─ 持续改进\n│\n├─ 团队能力\n│ ├─ 培训提升\n│ ├─ 知识共享\n│ ├─ 经验沉淀\n│ └─ 最佳实践\n│\n└─ 工具支持\n ├─ 工具自动化\n ├─ 工具标准化\n ├─ 工具维护\n └─ 工具升级\n```\n\n## 债务看板\n\n```markdown\n## 技术债务看板\n\n### P0（立即解决）\n- [ ] 自动化脚本频繁失败\n- [ ] 测试环境不稳定\n\n### P1（计划解决）\n- [ ] 核心流程自动化覆盖不足\n- [ ] 用例过时需要更新\n\n### P2（逐步解决）\n- [ ] 框架版本需要升级\n- [ ] 测试数据管理需要改进\n\n### P3（持续监控）\n- [ ] 测试文档需要完善\n- [ ] 工具链需要统一\n```\n\n## 输出示例\n\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\n\n**代码覆盖率从80%降到了60%**\n→ 识别测试债务：增量代码缺乏单元测试覆盖\n→ 排期治理：每迭代拿出20%容量偿还测试债务\n\n## 检查清单\n\n技术债务管理完成后检查：\n- [ ] 债务是否识别完整？\n- [ ] 债务评估是否准确？\n- [ ] 治理策略是否制定？\n- [ ] 治理计划是否执行？\n- [ ] 预防措施是否实施？\n- [ ] 债务看板是否维护？\n\nFile v1.6.3:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.6.3\",\n \"publishedAt\": 1786548526099\n}\n\nFile v1.6.3:skill-card.md\n\n## Description:\n\nHelps QA and test automation teams systematically identify test automation and test asset technical debt, estimate maintenance and rewrite costs, and create phased repayment plans.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, test automation engineers, and quality leads use this skill to convert flaky tests, high maintenance cost, outdated cases, and coverage gaps into a debt inventory, impact analysis, repayment plan, and prevention strategy.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate on broad refactoring or maintenance-cost requests outside QA technical-debt work.\n\nMitigation: Use it when the request is specifically about QA or test automation debt analysis.\n\nRisk: Debt assessments may be mistaken for release-blocking or production-impact decisions.\n\nMitigation: Treat recommendations as review inputs and confirm release or product-impact decisions with the relevant development and product owners before acting.\n\n## Reference(s):\n\n- [ClawHub skill release: qa-tech-debt-management](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n\n## Skill Output:\n\n**Output Type(s):** [Analysis, Markdown, Guidance]\n\n**Output Format:** [Markdown with structured debt inventory, impact analysis, repayment plan, and prevention strategy sections]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes traceability to related defect IDs or automation architecture IDs when available.]\n\n## Skill Version(s):\n\n1.6.3 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.6.0: 3 files, 5110 bytes\n\nFiles: skill-card.md (2361b), SKILL.md (9092b), _meta.json (142b)\n\nFile v1.6.0:SKILL.md\n\n---\r\nname: qa-tech-debt-management\r\nversion: 1.6.0\r\ndescription: >-\r\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\r\n\r\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\r\nallowed-tools: Read Grep Glob Bash\r\nrelated_skills:\r\n upstream:\r\n - qa-test-automation-arch # 输入：自动化架构评估\r\n - qa-quality-metrics # 输入：质量度量数据\r\n downstream:\r\n - qa-retrospective # 输出：债务分析用于复盘\r\n - qa-test-strategy-design # 输出：债务治理影响测试策略\r\ninput_format:\r\n required:\r\n - name: 测试报告\r\n type: object\r\n description: 来自qa-test-reporting的测试报告\r\n - name: 代码质量数据\r\n type: object\r\n description: 代码质量分析数据\r\n optional:\r\n - name: 历史基线\r\n type: object\r\n description: 历史技术债务基线\r\noutput_format:\r\n traceability:\r\n - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\r\n structure:\r\n - debt_inventory: 技术债务清单\r\n - impact_analysis: 影响分析\r\n - repayment_plan: 偿还计划\r\n - prevention_strategies: 预防策略\r\ncategories: ['Development','Testing']\r\ndepth_requirement_quantification:\r\n reference_value: \"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\"\r\n minimum: \"至少完成债务识别、成本评估、治理优先级3步\"\r\nerror_recovery_guidance:\r\n on_failure: \"债务治理遗漏高优债务时回退到质量度量补充数据\"\r\n retry_behavior: \"补充数据后重新评估治理优先级\"\r\n---\r\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\r\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\r\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\r\n\r\n# 技术债务管理\r\n\r\n## 核心原则\r\n\r\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\r\n\r\n## 技术债务类型\r\n\r\n### 自动化债务\r\n\r\n```text\r\n债务表现：\r\n├─ 自动化脚本不稳定\r\n│ ├─ 频繁失败（假阳性）\r\n│ ├─ 执行时间过长\r\n│ └─ 维护成本高\r\n│\r\n├─ 自动化覆盖不足\r\n│ ├─ 核心流程未覆盖\r\n│ ├─ 边界场景未覆盖\r\n│ └─ 异常场景未覆盖\r\n│\r\n├─ 框架问题\r\n│ ├─ 框架版本过旧\r\n│ ├─ 框架设计不合理\r\n│ └─ 框架文档缺失\r\n│\r\n└─ 代码质量\r\n ├─ 代码重复\r\n ├─ 代码复杂度高\r\n └─ 代码可读性差\r\n```\r\n\r\n### 测试债务\r\n\r\n```text\r\n债务表现：\r\n├─ 用例问题\r\n│ ├─ 用例过时\r\n│ ├─ 用例冗余\r\n│ ├─ 用例覆盖不足\r\n│ └─ 用例维护困难\r\n│\r\n├─ 流程问题\r\n│ ├─ 测试流程不规范\r\n│ ├─ 测试执行不彻底\r\n│ ├─ 缺陷管理混乱\r\n│ └─ 回归测试不充分\r\n│\r\n└─ 环境问题\r\n ├─ 测试环境不稳定\r\n ├─ 测试数据不足\r\n ├─ 测试工具落后\r\n └─ 测试基础设施薄弱\r\n```\r\n\r\n### 架构债务\r\n\r\n```text\r\n债务表现：\r\n├─ 可测试性差\r\n│ ├─ 接口不可Mock\r\n│ ├─ 日志不完整\r\n│ ├─ 配置不灵活\r\n│ └─ 数据不可构造\r\n│\r\n├─ 测试架构问题\r\n│ ├─ 分层不清晰\r\n│ ├─ 职责不单一\r\n│ ├─ 扩展性差\r\n│ └─ 可维护性差\r\n│\r\n└─ 集成问题\r\n ├─ CI/CD集成不完善\r\n ├─ 报告不规范\r\n ├─ 监控不完善\r\n └─ 工具链不统一\r\n```\r\n\r\n## 债务评估\r\n\r\n### 评估维度\r\n\r\n```text\r\n├─ 影响度\r\n│ ├─ 对测试效率的影响\r\n│ ├─ 对测试质量的影响\r\n│ ├─ 对团队士气的影响\r\n│ └─ 对交付速度的影响\r\n│\r\n├─ 紧迫度\r\n│ ├─ 是否阻塞当前工作\r\n│ ├─ 是否影响发布\r\n│ ├─ 是否导致线上问题\r\n│ └─ 是否影响团队效率\r\n│\r\n├─ 解决成本\r\n│ ├─ 人力成本\r\n│ ├─ 时间成本\r\n│ ├─ 风险成本\r\n│ └─ 机会成本\r\n│\r\n└─ 解决收益\r\n ├─ 效率提升\r\n ├─ 质量提升\r\n ├─ 成本降低\r\n └─ 风险降低\r\n```\r\n\r\n### 评估矩阵\r\n\r\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\r\n|---------|--------|--------|---------|---------|--------|\r\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\r\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\r\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\r\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\r\n\r\n## 债务治理\r\n\r\n### 治理策略\r\n\r\n```text\r\n├─ 立即解决（P0）\r\n│ ├─ 阻塞性问题\r\n│ ├─ 线上问题\r\n│ └─ 效率严重下降\r\n│\r\n├─ 计划解决（P1）\r\n│ ├─ 影响当前迭代\r\n│ ├─ 影响团队效率\r\n│ └─ 风险较高\r\n│\r\n├─ 逐步解决（P2）\r\n│ ├─ 不影响当前工作\r\n│ ├─ 可以规划解决\r\n│ └─ 成本较高\r\n│\r\n└─ 持续监控（P3）\r\n ├─ 影响较小\r\n ├─ 成本较高\r\n └─ 可以接受\r\n```\r\n\r\n### 治理方法\r\n\r\n```text\r\n自动化债务治理：\r\n├─ 脚本稳定化\r\n│ ├─ 修复假阳性\r\n│ ├─ 优化等待策略\r\n│ ├─ 增加重试机制\r\n│ └─ 改进错误处理\r\n│\r\n├─ 覆盖提升\r\n│ ├─ 补充核心流程\r\n│ ├─ 补充边界场景\r\n│ ├─ 补充异常场景\r\n│ └─ 优化测试数据\r\n│\r\n└─ 框架升级\r\n ├─ 版本升级\r\n ├─ 架构优化\r\n ├─ 文档完善\r\n └─ 工具统一\r\n\r\n测试债务治理：\r\n├─ 用例优化\r\n│ ├─ 清理过时用例\r\n│ ├─ 合并冗余用例\r\n│ ├─ 补充覆盖不足\r\n│ └─ 改进可维护性\r\n│\r\n├─ 流程改进\r\n│ ├─ 规范测试流程\r\n│ ├─ 完善执行标准\r\n│ ├─ 改进缺陷管理\r\n│ └─ 优化回归策略\r\n│\r\n└─ 环境改善\r\n ├─ 稳定测试环境\r\n ├─ 补充测试数据\r\n ├─ 升级测试工具\r\n └─ 完善基础设施\r\n\r\n架构债务治理：\r\n├─ 可测试性改进\r\n│ ├─ 接口Mock化\r\n│ ├─ 日志完善\r\n│ ├─ 配置动态化\r\n│ └─ 数据构造化\r\n│\r\n├─ 架构优化\r\n│ ├─ 分层清晰化\r\n│ ├─ 职责单一化\r\n│ ├─ 扩展性提升\r\n│ └─ 可维护性提升\r\n│\r\n└─ 集成完善\r\n ├─ CI/CD完善\r\n ├─ 报告规范化\r\n ├─ 监控完善\r\n └─ 工具链统一\r\n```\r\n\r\n## 债务预防\r\n\r\n### 预防措施\r\n\r\n```text\r\n├─ 代码质量\r\n│ ├─ 代码评审\r\n│ ├─ 静态分析\r\n│ ├─ 测试覆盖\r\n│ └─ 重构习惯\r\n│\r\n├─ 流程规范\r\n│ ├─ 流程文档化\r\n│ ├─ 执行标准化\r\n│ ├─ 定期Review\r\n│ └─ 持续改进\r\n│\r\n├─ 团队能力\r\n│ ├─ 培训提升\r\n│ ├─ 知识共享\r\n│ ├─ 经验沉淀\r\n│ └─ 最佳实践\r\n│\r\n└─ 工具支持\r\n ├─ 工具自动化\r\n ├─ 工具标准化\r\n ├─ 工具维护\r\n └─ 工具升级\r\n```\r\n\r\n## 债务看板\r\n\r\n```markdown\r\n## 技术债务看板\r\n\r\n### P0（立即解决）\r\n- [ ] 自动化脚本频繁失败\r\n- [ ] 测试环境不稳定\r\n\r\n### P1（计划解决）\r\n- [ ] 核心流程自动化覆盖不足\r\n- [ ] 用例过时需要更新\r\n\r\n### P2（逐步解决）\r\n- [ ] 框架版本需要升级\r\n- [ ] 测试数据管理需要改进\r\n\r\n### P3（持续监控）\r\n- [ ] 测试文档需要完善\r\n- [ ] 工具链需要统一\r\n```\r\n\r\n## 输出示例\r\n\r\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\r\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\r\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\r\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\r\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\r\n\r\n**代码覆盖率从80%降到了60%**\r\n→ 识别测试债务：增量代码缺乏单元测试覆盖\r\n→ 排期治理：每迭代拿出20%容量偿还测试债务\r\n\r\n## 检查清单\r\n\r\n技术债务管理完成后检查：\r\n- [ ] 债务是否识别完整？\r\n- [ ] 债务评估是否准确？\r\n- [ ] 治理策略是否制定？\r\n- [ ] 治理计划是否执行？\r\n- [ ] 预防措施是否实施？\r\n- [ ] 债务看板是否维护？\n\nFile v1.6.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.6.0\",\n \"publishedAt\": 1783358280101\n}\n\nFile v1.6.0:skill-card.md\n\n## Description:
\nGuides QA teams through identifying test automation and test asset technical debt, estimating maintenance and rewrite costs, and planning phased repayment.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[kokxi](https://clawhub.ai/user/kokxi)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nQA engineers, test automation maintainers, and quality leaders use this skill to organize flaky automation, stale test cases, weak test architecture, and related QA debt into a traceable inventory with impact analysis and a repayment plan.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill includes examples about release blocking and production impact that could be mistaken for automatic go/no-go decisions.
\nMitigation: Require human review with development and product stakeholders before blocking a release or changing production behavior.
\nRisk: The broad activation wording may be applied outside QA or test automation debt workflows.
\nMitigation: Confirm the scope is QA or test automation debt before relying on the skill's prioritization and repayment guidance.
\nRisk: Debt priorities and cost estimates depend on the completeness and freshness of the supplied test reports, quality data, and baselines.
\nMitigation: Validate findings against current evidence before committing repayment capacity or changing team plans.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown guidance with structured debt inventory, impact analysis, repayment plan, and prevention strategies.]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Debt items should preserve traceability to related defect IDs or automation architecture IDs when available.]
\n\n## Skill Version(s):
\n1.6.0 (source: frontmatter and server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.5.0: 3 files, 4488 bytes\n\nFiles: skill-card.md (1865b), SKILL.md (8445b), _meta.json (142b)\n\nFile v1.5.0:SKILL.md\n\n---\r\nname: qa-tech-debt-management\r\nversion: 1.5.0\r\ndescription: >-\r\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。\r\n\r\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\r\nallowed-tools: Read Grep Glob Bash\r\nrelated_skills:\r\n upstream:\r\n - qa-test-automation-arch # 输入：自动化架构评估\r\n - qa-quality-metrics # 输入：质量度量数据\r\n downstream:\r\n - qa-retrospective # 输出：债务分析用于复盘\r\n - qa-test-strategy-design # 输出：债务治理影响测试策略\r\ninput_format:\r\n required:\r\n - name: 测试报告\r\n type: object\r\n description: 来自qa-test-reporting的测试报告\r\n - name: 代码质量数据\r\n type: object\r\n description: 代码质量分析数据\r\n optional:\r\n - name: 历史基线\r\n type: object\r\n description: 历史技术债务基线\r\noutput_format:\r\n structure:\r\n - debt_inventory: 技术债务清单\r\n - impact_analysis: 影响分析\r\n - repayment_plan: 偿还计划\r\n - prevention_strategies: 预防策略\r\n---\r\n\r\n# 技术债务管理\r\n\r\n## 核心原则\r\n\r\n你是一位技术债务管理专家，擅长识别、评估、治理测试技术债务。\r\n**核心原则**：技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\r\n本技能覆盖债务类型识别、评估矩阵、治理策略和预防措施。\r\n\r\n## 技术债务类型\r\n\r\n### 自动化债务\r\n\r\n```text\r\n债务表现：\r\n├─ 自动化脚本不稳定\r\n│ ├─ 频繁失败（假阳性）\r\n│ ├─ 执行时间过长\r\n│ └─ 维护成本高\r\n│\r\n├─ 自动化覆盖不足\r\n│ ├─ 核心流程未覆盖\r\n│ ├─ 边界场景未覆盖\r\n│ └─ 异常场景未覆盖\r\n│\r\n├─ 框架问题\r\n│ ├─ 框架版本过旧\r\n│ ├─ 框架设计不合理\r\n│ └─ 框架文档缺失\r\n│\r\n└─ 代码质量\r\n ├─ 代码重复\r\n ├─ 代码复杂度高\r\n └─ 代码可读性差\r\n```\r\n\r\n### 测试债务\r\n\r\n```text\r\n债务表现：\r\n├─ 用例问题\r\n│ ├─ 用例过时\r\n│ ├─ 用例冗余\r\n│ ├─ 用例覆盖不足\r\n│ └─ 用例维护困难\r\n│\r\n├─ 流程问题\r\n│ ├─ 测试流程不规范\r\n│ ├─ 测试执行不彻底\r\n│ ├─ 缺陷管理混乱\r\n│ └─ 回归测试不充分\r\n│\r\n└─ 环境问题\r\n ├─ 测试环境不稳定\r\n ├─ 测试数据不足\r\n ├─ 测试工具落后\r\n └─ 测试基础设施薄弱\r\n```\r\n\r\n### 架构债务\r\n\r\n```text\r\n债务表现：\r\n├─ 可测试性差\r\n│ ├─ 接口不可Mock\r\n│ ├─ 日志不完整\r\n│ ├─ 配置不灵活\r\n│ └─ 数据不可构造\r\n│\r\n├─ 测试架构问题\r\n│ ├─ 分层不清晰\r\n│ ├─ 职责不单一\r\n│ ├─ 扩展性差\r\n│ └─ 可维护性差\r\n│\r\n└─ 集成问题\r\n ├─ CI/CD集成不完善\r\n ├─ 报告不规范\r\n ├─ 监控不完善\r\n └─ 工具链不统一\r\n```\r\n\r\n## 债务评估\r\n\r\n### 评估维度\r\n\r\n```text\r\n├─ 影响度\r\n│ ├─ 对测试效率的影响\r\n│ ├─ 对测试质量的影响\r\n│ ├─ 对团队士气的影响\r\n│ └─ 对交付速度的影响\r\n│\r\n├─ 紧迫度\r\n│ ├─ 是否阻塞当前工作\r\n│ ├─ 是否影响发布\r\n│ ├─ 是否导致线上问题\r\n│ └─ 是否影响团队效率\r\n│\r\n├─ 解决成本\r\n│ ├─ 人力成本\r\n│ ├─ 时间成本\r\n│ ├─ 风险成本\r\n│ └─ 机会成本\r\n│\r\n└─ 解决收益\r\n ├─ 效率提升\r\n ├─ 质量提升\r\n ├─ 成本降低\r\n └─ 风险降低\r\n```\r\n\r\n### 评估矩阵\r\n\r\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\r\n|---------|--------|--------|---------|---------|--------|\r\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\r\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\r\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\r\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\r\n\r\n## 债务治理\r\n\r\n### 治理策略\r\n\r\n```text\r\n├─ 立即解决（P0）\r\n│ ├─ 阻塞性问题\r\n│ ├─ 线上问题\r\n│ └─ 效率严重下降\r\n│\r\n├─ 计划解决（P1）\r\n│ ├─ 影响当前迭代\r\n│ ├─ 影响团队效率\r\n│ └─ 风险较高\r\n│\r\n├─ 逐步解决（P2）\r\n│ ├─ 不影响当前工作\r\n│ ├─ 可以规划解决\r\n│ └─ 成本较高\r\n│\r\n└─ 持续监控（P3）\r\n ├─ 影响较小\r\n ├─ 成本较高\r\n └─ 可以接受\r\n```\r\n\r\n### 治理方法\r\n\r\n```text\r\n自动化债务治理：\r\n├─ 脚本稳定化\r\n│ ├─ 修复假阳性\r\n│ ├─ 优化等待策略\r\n│ ├─ 增加重试机制\r\n│ └─ 改进错误处理\r\n│\r\n├─ 覆盖提升\r\n│ ├─ 补充核心流程\r\n│ ├─ 补充边界场景\r\n│ ├─ 补充异常场景\r\n│ └─ 优化测试数据\r\n│\r\n└─ 框架升级\r\n ├─ 版本升级\r\n ├─ 架构优化\r\n ├─ 文档完善\r\n └─ 工具统一\r\n\r\n测试债务治理：\r\n├─ 用例优化\r\n│ ├─ 清理过时用例\r\n│ ├─ 合并冗余用例\r\n│ ├─ 补充覆盖不足\r\n│ └─ 改进可维护性\r\n│\r\n├─ 流程改进\r\n│ ├─ 规范测试流程\r\n│ ├─ 完善执行标准\r\n│ ├─ 改进缺陷管理\r\n│ └─ 优化回归策略\r\n│\r\n└─ 环境改善\r\n ├─ 稳定测试环境\r\n ├─ 补充测试数据\r\n ├─ 升级测试工具\r\n └─ 完善基础设施\r\n\r\n架构债务治理：\r\n├─ 可测试性改进\r\n│ ├─ 接口Mock化\r\n│ ├─ 日志完善\r\n│ ├─ 配置动态化\r\n│ └─ 数据构造化\r\n│\r\n├─ 架构优化\r\n│ ├─ 分层清晰化\r\n│ ├─ 职责单一化\r\n│ ├─ 扩展性提升\r\n│ └─ 可维护性提升\r\n│\r\n└─ 集成完善\r\n ├─ CI/CD完善\r\n ├─ 报告规范化\r\n ├─ 监控完善\r\n └─ 工具链统一\r\n```\r\n\r\n## 债务预防\r\n\r\n### 预防措施\r\n\r\n```text\r\n├─ 代码质量\r\n│ ├─ 代码评审\r\n│ ├─ 静态分析\r\n│ ├─ 测试覆盖\r\n│ └─ 重构习惯\r\n│\r\n├─ 流程规范\r\n│ ├─ 流程文档化\r\n│ ├─ 执行标准化\r\n│ ├─ 定期Review\r\n│ └─ 持续改进\r\n│\r\n├─ 团队能力\r\n│ ├─ 培训提升\r\n│ ├─ 知识共享\r\n│ ├─ 经验沉淀\r\n│ └─ 最佳实践\r\n│\r\n└─ 工具支持\r\n ├─ 工具自动化\r\n ├─ 工具标准化\r\n ├─ 工具维护\r\n └─ 工具升级\r\n```\r\n\r\n## 债务看板\r\n\r\n```markdown\r\n## 技术债务看板\r\n\r\n### P0（立即解决）\r\n- [ ] 自动化脚本频繁失败\r\n- [ ] 测试环境不稳定\r\n\r\n### P1（计划解决）\r\n- [ ] 核心流程自动化覆盖不足\r\n- [ ] 用例过时需要更新\r\n\r\n### P2（逐步解决）\r\n- [ ] 框架版本需要升级\r\n- [ ] 测试数据管理需要改进\r\n\r\n### P3（持续监控）\r\n- [ ] 测试文档需要完善\r\n- [ ] 工具链需要统一\r\n```\r\n\r\n## 输出示例\r\n\r\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\r\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\r\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\r\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\r\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\r\n\r\n**代码覆盖率从80%降到了60%**\r\n→ 识别测试债务：增量代码缺乏单元测试覆盖\r\n→ 排期治理：每迭代拿出20%容量偿还测试债务\r\n\r\n## 检查清单\r\n\r\n技术债务管理完成后检查：\r\n- [ ] 债务是否识别完整？\r\n- [ ] 债务评估是否准确？\r\n- [ ] 治理策略是否制定？\r\n- [ ] 治理计划是否执行？\r\n- [ ] 预防措施是否实施？\r\n- [ ] 债务看板是否维护？\n\nFile v1.5.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.5.0\",\n \"publishedAt\": 1782736565745\n}\n\nFile v1.5.0:skill-card.md\n\n## Description:
\nProvides Chinese-language guidance for identifying QA and test automation technical debt, estimating maintenance and rewrite costs, and planning staged repayment and prevention work.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[kokxi](https://clawhub.ai/user/kokxi)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nQA engineers, test automation developers, and engineering leads use this skill to turn test reports and code-quality data into a debt inventory, impact analysis, repayment plan, and prevention strategy for testing assets.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may activate for broad technical-debt or refactoring requests where QA and testing debt is not the user's actual focus.
\nMitigation: Confirm that recommendations are relevant to QA, test automation, or testing assets before applying the suggested debt plan.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)
\n\n\n## Skill Output:
\n**Output Type(s):** [guidance, markdown, text]
\n**Output Format:** [Markdown guidance with structured debt inventory, impact analysis, repayment plan, and prevention strategies.]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Documentation-only skill; evidence reports no hidden execution, persistence, or data-sharing behavior.]
\n\n## Skill Version(s):
\n1.5.0 (source: frontmatter and server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.4.1: 3 files, 4283 bytes\n\nFiles: skill-card.md (2122b), SKILL.md (7732b), _meta.json (142b)\n\nFile v1.4.1:SKILL.md\n\n---\r\nname: qa-tech-debt-management\r\ndescription: >-\r\n 技术债务管理，系统化识别/评估/治理测试自动化债务和测试资产技术债。当需要优化测试维护成本或重构自动化时激活。\r\n\r\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\r\nallowed-tools: Read Grep Glob Bash\r\nrelated_skills:\r\n upstream:\r\n - qa-test-automation-arch # 输入：自动化架构评估\r\n - qa-quality-metrics # 输入：质量度量数据\r\n downstream:\r\n - qa-retrospective # 输出：债务分析用于复盘\r\n - qa-test-strategy-design # 输出：债务治理影响测试策略\r\ninput_format: 自动化架构 + 质量度量\r\noutput_format: 技术债务管理方案（债务识别+评估+治理+预防）\r\n---\r\n\r\n# 技术债务管理\r\n\r\n## Overview\r\n\r\n你是一位技术债务管理专家，擅长识别、评估、治理测试技术债务。\r\n**核心原则**：技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\r\n本技能覆盖债务类型识别、评估矩阵、治理策略和预防措施。\r\n\r\n## 技术债务类型\r\n\r\n### 自动化债务\r\n\r\n```\r\n债务表现：\r\n├─ 自动化脚本不稳定\r\n│ ├─ 频繁失败（假阳性）\r\n│ ├─ 执行时间过长\r\n│ └─ 维护成本高\r\n│\r\n├─ 自动化覆盖不足\r\n│ ├─ 核心流程未覆盖\r\n│ ├─ 边界场景未覆盖\r\n│ └─ 异常场景未覆盖\r\n│\r\n├─ 框架问题\r\n│ ├─ 框架版本过旧\r\n│ ├─ 框架设计不合理\r\n│ └─ 框架文档缺失\r\n│\r\n└─ 代码质量\r\n ├─ 代码重复\r\n ├─ 代码复杂度高\r\n └─ 代码可读性差\r\n```\r\n\r\n### 测试债务\r\n\r\n```\r\n债务表现：\r\n├─ 用例问题\r\n│ ├─ 用例过时\r\n│ ├─ 用例冗余\r\n│ ├─ 用例覆盖不足\r\n│ └─ 用例维护困难\r\n│\r\n├─ 流程问题\r\n│ ├─ 测试流程不规范\r\n│ ├─ 测试执行不彻底\r\n│ ├─ 缺陷管理混乱\r\n│ └─ 回归测试不充分\r\n│\r\n└─ 环境问题\r\n ├─ 测试环境不稳定\r\n ├─ 测试数据不足\r\n ├─ 测试工具落后\r\n └─ 测试基础设施薄弱\r\n```\r\n\r\n### 架构债务\r\n\r\n```\r\n债务表现：\r\n├─ 可测试性差\r\n│ ├─ 接口不可Mock\r\n│ ├─ 日志不完整\r\n│ ├─ 配置不灵活\r\n│ └─ 数据不可构造\r\n│\r\n├─ 测试架构问题\r\n│ ├─ 分层不清晰\r\n│ ├─ 职责不单一\r\n│ ├─ 扩展性差\r\n│ └─ 可维护性差\r\n│\r\n└─ 集成问题\r\n ├─ CI/CD集成不完善\r\n ├─ 报告不规范\r\n ├─ 监控不完善\r\n └─ 工具链不统一\r\n```\r\n\r\n## 债务评估\r\n\r\n### 评估维度\r\n\r\n```\r\n├─ 影响度\r\n│ ├─ 对测试效率的影响\r\n│ ├─ 对测试质量的影响\r\n│ ├─ 对团队士气的影响\r\n│ └─ 对交付速度的影响\r\n│\r\n├─ 紧迫度\r\n│ ├─ 是否阻塞当前工作\r\n│ ├─ 是否影响发布\r\n│ ├─ 是否导致线上问题\r\n│ └─ 是否影响团队效率\r\n│\r\n├─ 解决成本\r\n│ ├─ 人力成本\r\n│ ├─ 时间成本\r\n│ ├─ 风险成本\r\n│ └─ 机会成本\r\n│\r\n└─ 解决收益\r\n ├─ 效率提升\r\n ├─ 质量提升\r\n ├─ 成本降低\r\n └─ 风险降低\r\n```\r\n\r\n### 评估矩阵\r\n\r\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\r\n|---------|--------|--------|---------|---------|--------|\r\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\r\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\r\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\r\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\r\n\r\n## 债务治理\r\n\r\n### 治理策略\r\n\r\n```\r\n├─ 立即解决（P0）\r\n│ ├─ 阻塞性问题\r\n│ ├─ 线上问题\r\n│ └─ 效率严重下降\r\n│\r\n├─ 计划解决（P1）\r\n│ ├─ 影响当前迭代\r\n│ ├─ 影响团队效率\r\n│ └─ 风险较高\r\n│\r\n├─ 逐步解决（P2）\r\n│ ├─ 不影响当前工作\r\n│ ├─ 可以规划解决\r\n│ └─ 成本较高\r\n│\r\n└─ 持续监控（P3）\r\n ├─ 影响较小\r\n ├─ 成本较高\r\n └─ 可以接受\r\n```\r\n\r\n### 治理方法\r\n\r\n```\r\n自动化债务治理：\r\n├─ 脚本稳定化\r\n│ ├─ 修复假阳性\r\n│ ├─ 优化等待策略\r\n│ ├─ 增加重试机制\r\n│ └─ 改进错误处理\r\n│\r\n├─ 覆盖提升\r\n│ ├─ 补充核心流程\r\n│ ├─ 补充边界场景\r\n│ ├─ 补充异常场景\r\n│ └─ 优化测试数据\r\n│\r\n└─ 框架升级\r\n ├─ 版本升级\r\n ├─ 架构优化\r\n ├─ 文档完善\r\n └─ 工具统一\r\n\r\n测试债务治理：\r\n├─ 用例优化\r\n│ ├─ 清理过时用例\r\n│ ├─ 合并冗余用例\r\n│ ├─ 补充覆盖不足\r\n│ └─ 改进可维护性\r\n│\r\n├─ 流程改进\r\n│ ├─ 规范测试流程\r\n│ ├─ 完善执行标准\r\n│ ├─ 改进缺陷管理\r\n│ └─ 优化回归策略\r\n│\r\n└─ 环境改善\r\n ├─ 稳定测试环境\r\n ├─ 补充测试数据\r\n ├─ 升级测试工具\r\n └─ 完善基础设施\r\n\r\n架构债务治理：\r\n├─ 可测试性改进\r\n│ ├─ 接口Mock化\r\n│ ├─ 日志完善\r\n│ ├─ 配置动态化\r\n│ └─ 数据构造化\r\n│\r\n├─ 架构优化\r\n│ ├─ 分层清晰化\r\n│ ├─ 职责单一化\r\n│ ├─ 扩展性提升\r\n│ └─ 可维护性提升\r\n│\r\n└─ 集成完善\r\n ├─ CI/CD完善\r\n ├─ 报告规范化\r\n ├─ 监控完善\r\n └─ 工具链统一\r\n```\r\n\r\n## 债务预防\r\n\r\n### 预防措施\r\n\r\n```\r\n├─ 代码质量\r\n│ ├─ 代码评审\r\n│ ├─ 静态分析\r\n│ ├─ 测试覆盖\r\n│ └─ 重构习惯\r\n│\r\n├─ 流程规范\r\n│ ├─ 流程文档化\r\n│ ├─ 执行标准化\r\n│ ├─ 定期Review\r\n│ └─ 持续改进\r\n│\r\n├─ 团队能力\r\n│ ├─ 培训提升\r\n│ ├─ 知识共享\r\n│ ├─ 经验沉淀\r\n│ └─ 最佳实践\r\n│\r\n└─ 工具支持\r\n ├─ 工具自动化\r\n ├─ 工具标准化\r\n ├─ 工具维护\r\n └─ 工具升级\r\n```\r\n\r\n## 债务看板\r\n\r\n```markdown\r\n## 技术债务看板\r\n\r\n### P0（立即解决）\r\n- [ ] 自动化脚本频繁失败\r\n- [ ] 测试环境不稳定\r\n\r\n### P1（计划解决）\r\n- [ ] 核心流程自动化覆盖不足\r\n- [ ] 用例过时需要更新\r\n\r\n### P2（逐步解决）\r\n- [ ] 框架版本需要升级\r\n- [ ] 测试数据管理需要改进\r\n\r\n### P3（持续监控）\r\n- [ ] 测试文档需要完善\r\n- [ ] 工具链需要统一\r\n```\r\n\r\n## Examples\r\n\r\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\r\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\r\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\r\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\r\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\r\n\r\n**代码覆盖率从80%降到了60%**\r\n→ 识别测试债务：增量代码缺乏单元测试覆盖\r\n→ 排期治理：每迭代拿出20%容量偿还测试债务\r\n\r\n## Guidelines\r\n\r\n技术债务管理完成后检查：\r\n- [ ] 债务是否识别完整？\r\n- [ ] 债务评估是否准确？\r\n- [ ] 治理策略是否制定？\r\n- [ ] 治理计划是否执行？\r\n- [ ] 预防措施是否实施？\r\n- [ ] 债务看板是否维护？\n\nFile v1.4.1:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.4.1\",\n \"publishedAt\": 1782406621136\n}\n\nFile v1.4.1:skill-card.md\n\n## Description:
\nProvides Chinese-language guidance for systematically identifying, assessing, governing, and preventing QA automation and testing-asset technical debt.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[kokxi](https://clawhub.ai/user/kokxi)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nQA engineers, test automation engineers, and engineering teams use this skill to assess testing debt, prioritize remediation work, create debt governance plans, and reduce automation maintenance cost.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The artifact contains invisible characters and broad activation wording that could make invocation harder to audit.
\nMitigation: Review the full SKILL.md before installation and narrow activation triggers to testing-asset or automation-maintenance debt workflows when deploying.
\nRisk: Debt-management recommendations may be incomplete or mismatched to the team's testing architecture and delivery constraints.
\nMitigation: Have QA or engineering leads review proposed debt classifications, priorities, and remediation plans before adding work to delivery commitments.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)
\n- [Publisher profile](https://clawhub.ai/user/kokxi)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown guidance with assessment matrices, prioritized action plans, checklists, and examples]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Chinese-language responses focused on QA technical-debt management]
\n\n## Skill Version(s):
\n1.4.1 (source: server-resolved release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.4.0: 3 files, 4306 bytes\n\nFiles: skill-card.md (2020b), SKILL.md (7993b), _meta.json (142b)\n\nFile v1.4.0:SKILL.md\n\n---\r\nname: qa-tech-debt-management\r\ndescription: >-\r\n 技术债务管理，识别、评估、治理测试技术债务。当用户需要管理技术债务、测试债务、自动化债务或重构测试时自动触发。\r\n 也适用于：自动化测试维护成本高需要评估，或测试资产需要系统化治理时。\r\n 关键词：技术债务、测试债务、自动化维护、债务治理、债务评估、债务追踪、重构优先级、投资回报率、债务量化。\nwhen_to_use: 用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时\r\nallowed-tools: Read Grep Glob Bash\r\nrelated_skills:\r\n upstream:\r\n - qa-test-automation-arch # 输入：自动化架构评估\r\n - qa-quality-metrics # 输入：质量度量数据\r\n downstream:\r\n - qa-retrospective # 输出：债务分析用于复盘\r\n - qa-test-strategy-design # 输出：债务治理影响测试策略\r\ninput_format: 自动化架构 + 质量度量\r\noutput_format: 技术债务管理方案（债务识别+评估+治理+预防）\r\n---\r\n\r\n# 技术债务管理\r\n\r\n## Overview\r\n\r\n你是一位技术债务管理专家，擅长识别、评估、治理测试技术债务。\r\n**核心原则**：技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\r\n本技能覆盖债务类型识别、评估矩阵、治理策略和预防措施。\r\n\r\n## 技术债务类型\r\n\r\n### 自动化债务\r\n\r\n```\r\n债务表现：\r\n├─ 自动化脚本不稳定\r\n│ ├─ 频繁失败（假阳性）\r\n│ ├─ 执行时间过长\r\n│ └─ 维护成本高\r\n│\r\n├─ 自动化覆盖不足\r\n│ ├─ 核心流程未覆盖\r\n│ ├─ 边界场景未覆盖\r\n│ └─ 异常场景未覆盖\r\n│\r\n├─ 框架问题\r\n│ ├─ 框架版本过旧\r\n│ ├─ 框架设计不合理\r\n│ └─ 框架文档缺失\r\n│\r\n└─ 代码质量\r\n ├─ 代码重复\r\n ├─ 代码复杂度高\r\n └─ 代码可读性差\r\n```\r\n\r\n### 测试债务\r\n\r\n```\r\n债务表现：\r\n├─ 用例问题\r\n│ ├─ 用例过时\r\n│ ├─ 用例冗余\r\n│ ├─ 用例覆盖不足\r\n│ └─ 用例维护困难\r\n│\r\n├─ 流程问题\r\n│ ├─ 测试流程不规范\r\n│ ├─ 测试执行不彻底\r\n│ ├─ 缺陷管理混乱\r\n│ └─ 回归测试不充分\r\n│\r\n└─ 环境问题\r\n ├─ 测试环境不稳定\r\n ├─ 测试数据不足\r\n ├─ 测试工具落后\r\n └─ 测试基础设施薄弱\r\n```\r\n\r\n### 架构债务\r\n\r\n```\r\n债务表现：\r\n├─ 可测试性差\r\n│ ├─ 接口不可Mock\r\n│ ├─ 日志不完整\r\n│ ├─ 配置不灵活\r\n│ └─ 数据不可构造\r\n│\r\n├─ 测试架构问题\r\n│ ├─ 分层不清晰\r\n│ ├─ 职责不单一\r\n│ ├─ 扩展性差\r\n│ └─ 可维护性差\r\n│\r\n└─ 集成问题\r\n ├─ CI/CD集成不完善\r\n ├─ 报告不规范\r\n ├─ 监控不完善\r\n └─ 工具链不统一\r\n```\r\n\r\n## 债务评估\r\n\r\n### 评估维度\r\n\r\n```\r\n├─ 影响度\r\n│ ├─ 对测试效率的影响\r\n│ ├─ 对测试质量的影响\r\n│ ├─ 对团队士气的影响\r\n│ └─ 对交付速度的影响\r\n│\r\n├─ 紧迫度\r\n│ ├─ 是否阻塞当前工作\r\n│ ├─ 是否影响发布\r\n│ ├─ 是否导致线上问题\r\n│ └─ 是否影响团队效率\r\n│\r\n├─ 解决成本\r\n│ ├─ 人力成本\r\n│ ├─ 时间成本\r\n│ ├─ 风险成本\r\n│ └─ 机会成本\r\n│\r\n└─ 解决收益\r\n ├─ 效率提升\r\n ├─ 质量提升\r\n ├─ 成本降低\r\n └─ 风险降低\r\n```\r\n\r\n### 评估矩阵\r\n\r\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\r\n|---------|--------|--------|---------|---------|--------|\r\n| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |\r\n| 用例过时 | 中 | 中 | 低 | 中 | P1 |\r\n| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |\r\n| 文档缺失 | 低 | 低 | 低 | 低 | P3 |\r\n\r\n## 债务治理\r\n\r\n### 治理策略\r\n\r\n```\r\n├─ 立即解决（P0）\r\n│ ├─ 阻塞性问题\r\n│ ├─ 线上问题\r\n│ └─ 效率严重下降\r\n│\r\n├─ 计划解决（P1）\r\n│ ├─ 影响当前迭代\r\n│ ├─ 影响团队效率\r\n│ └─ 风险较高\r\n│\r\n├─ 逐步解决（P2）\r\n│ ├─ 不影响当前工作\r\n│ ├─ 可以规划解决\r\n│ └─ 成本较高\r\n│\r\n└─ 持续监控（P3）\r\n ├─ 影响较小\r\n ├─ 成本较高\r\n └─ 可以接受\r\n```\r\n\r\n### 治理方法\r\n\r\n```\r\n自动化债务治理：\r\n├─ 脚本稳定化\r\n│ ├─ 修复假阳性\r\n│ ├─ 优化等待策略\r\n│ ├─ 增加重试机制\r\n│ └─ 改进错误处理\r\n│\r\n├─ 覆盖提升\r\n│ ├─ 补充核心流程\r\n│ ├─ 补充边界场景\r\n│ ├─ 补充异常场景\r\n│ └─ 优化测试数据\r\n│\r\n└─ 框架升级\r\n ├─ 版本升级\r\n ├─ 架构优化\r\n ├─ 文档完善\r\n └─ 工具统一\r\n\r\n测试债务治理：\r\n├─ 用例优化\r\n│ ├─ 清理过时用例\r\n│ ├─ 合并冗余用例\r\n│ ├─ 补充覆盖不足\r\n│ └─ 改进可维护性\r\n│\r\n├─ 流程改进\r\n│ ├─ 规范测试流程\r\n│ ├─ 完善执行标准\r\n│ ├─ 改进缺陷管理\r\n│ └─ 优化回归策略\r\n│\r\n└─ 环境改善\r\n ├─ 稳定测试环境\r\n ├─ 补充测试数据\r\n ├─ 升级测试工具\r\n └─ 完善基础设施\r\n\r\n架构债务治理：\r\n├─ 可测试性改进\r\n│ ├─ 接口Mock化\r\n│ ├─ 日志完善\r\n│ ├─ 配置动态化\r\n│ └─ 数据构造化\r\n│\r\n├─ 架构优化\r\n│ ├─ 分层清晰化\r\n│ ├─ 职责单一化\r\n│ ├─ 扩展性提升\r\n│ └─ 可维护性提升\r\n│\r\n└─ 集成完善\r\n ├─ CI/CD完善\r\n ├─ 报告规范化\r\n ├─ 监控完善\r\n └─ 工具链统一\r\n```\r\n\r\n## 债务预防\r\n\r\n### 预防措施\r\n\r\n```\r\n├─ 代码质量\r\n│ ├─ 代码评审\r\n│ ├─ 静态分析\r\n│ ├─ 测试覆盖\r\n│ └─ 重构习惯\r\n│\r\n├─ 流程规范\r\n│ ├─ 流程文档化\r\n│ ├─ 执行标准化\r\n│ ├─ 定期Review\r\n│ └─ 持续改进\r\n│\r\n├─ 团队能力\r\n│ ├─ 培训提升\r\n│ ├─ 知识共享\r\n│ ├─ 经验沉淀\r\n│ └─ 最佳实践\r\n│\r\n└─ 工具支持\r\n ├─ 工具自动化\r\n ├─ 工具标准化\r\n ├─ 工具维护\r\n └─ 工具升级\r\n```\r\n\r\n## 债务看板\r\n\r\n```markdown\r\n## 技术债务看板\r\n\r\n### P0（立即解决）\r\n- [ ] 自动化脚本频繁失败\r\n- [ ] 测试环境不稳定\r\n\r\n### P1（计划解决）\r\n- [ ] 核心流程自动化覆盖不足\r\n- [ ] 用例过时需要更新\r\n\r\n### P2（逐步解决）\r\n- [ ] 框架版本需要升级\r\n- [ ] 测试数据管理需要改进\r\n\r\n### P3（持续监控）\r\n- [ ] 测试文档需要完善\r\n- [ ] 工具链需要统一\r\n```\r\n\r\n## Examples\r\n\r\n**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**\r\n→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）\r\n→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天\r\n→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式\r\n→ 预防：制定自动化规范，新增功能必须添加自定义属性\r\n\r\n**代码覆盖率从80%降到了60%**\r\n→ 识别测试债务：增量代码缺乏单元测试覆盖\r\n→ 排期治理：每迭代拿出20%容量偿还测试债务\r\n\r\n## Guidelines\r\n\r\n技术债务管理完成后检查：\r\n- [ ] 债务是否识别完整？\r\n- [ ] 债务评估是否准确？\r\n- [ ] 治理策略是否制定？\r\n- [ ] 治理计划是否执行？\r\n- [ ] 预防措施是否实施？\r\n- [ ] 债务看板是否维护？\n\nFile v1.4.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.4.0\",\n \"publishedAt\": 1782277973689\n}\n\nFile v1.4.0:skill-card.md\n\n## Description:
\nThis Chinese-language skill helps QA teams identify, assess, govern, and prevent testing technical debt across automation, test process, and test architecture.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[kokxi](https://clawhub.ai/user/kokxi)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nQA engineers, test automation engineers, and engineering managers use this skill to classify testing technical debt, evaluate impact and repayment priority, and produce a governance plan with prevention practices.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Broad activation terms may cause the skill to run in more QA or refactoring conversations than intended.
\nMitigation: Invoke the skill explicitly for technical-debt work or narrow activation terms in environments where accidental activation would disrupt workflows.
\nRisk: The skill declares Bash access even though the security evidence reports no executable payload or hidden behavior.
\nMitigation: Review any shell commands proposed during use before execution and keep normal command-approval controls enabled.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Markdown, Guidance]
\n**Output Format:** [Markdown guidance and planning tables]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a technical-debt management plan covering debt identification, assessment, governance, prevention, and tracking.]
\n\n## Skill Version(s):
\n1.4.0 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
","readmeExcerpt":"Skill: qa-tech-debt-management Owner: kokxi Summary: 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans. Tags: ","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差"},{"language":"text","snippet":"债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱"},{"language":"text","snippet":"债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一"},{"language":"text","snippet":"├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低"},{"language":"text","snippet":"├─ 代码质量\n│ ├─ 代码评审\n│ ├─ 静态分析\n│ ├─ 测试覆盖\n│ └─ 重构习惯\n│\n├─ 流程规范\n│ ├─ 流程文档化\n│ ├─ 执行标准化\n│ ├─ 定期Review\n│ └─ 持续改进\n│\n├─ 团队能力\n│ ├─ 培训提升\n│ ├─ 知识共享\n│ ├─ 经验沉淀\n│ └─ 最佳实践\n│\n└─ 工具支持\n ├─ 工具自动化\n ├─ 工具标准化\n ├─ 工具维护\n └─ 工具升级"},{"language":"markdown","snippet":"## 技术债务看板\n\n### P0（立即解决）\n- [ ] 自动化脚本频繁失败\n- [ ] 测试环境不稳定\n\n### P1（计划解决）\n- [ ] 核心流程自动化覆盖不足\n- [ ] 用例过时需要更新\n\n### P2（逐步解决）\n- [ ] 框架版本需要升级\n- [ ] 测试数据管理需要改进\n\n### P3（持续监控）\n- [ ] 测试文档需要完善\n- [ ] 工具链需要统一"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: qa-tech-debt-management\ndescription: >-\n 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans.\nlicense: MIT\nallowed-tools: Read Grep Glob Bash\nmetadata:\n display-name: \"Tech Debt Management\"\n version: \"1.8.0\"\n when-to-use: \"用户说\\\"技术债务\\\"、\\\"测试债务\\\"、\\\"自动化债务\\\"、\\\"重构\\\"、\\\"债务治理\\\"、\\\"维护成本\\\"、需要管理技术债务、自动化维护成本高需要评估时\"\n related-skills: \"{\\\"upstream\\\":[\\\"qa-test-automation-arch\\\",\\\"qa-quality-metrics\\\"],\\\"downstream\\\":[\\\"qa-retrospective\\\",\\\"qa-test-strategy-design\\\"]}\"\n references: \"[\\\"references/debt-governance.md\\\"]\"\n input-format: \"{\\\"required\\\":[{\\\"name\\\":\\\"测试报告\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"来自qa-test-reporting的测试报告\\\"},{\\\"name\\\":\\\"代码质量数据\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"代码质量分析数据\\\"}],\\\"optional\\\":[{\\\"name\\\":\\\"历史基线\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"历史技术债务基线\\\"}]}\"\n output-format: \"{\\\"traceability\\\":[\\\"本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID\\\"],\\\"structure\\\":[\\\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\\\\\"全覆盖/100%\\\\\\\"绝对化表述；缺失模块标注\\\\\\\"未覆盖+原因\\\\\\\"\\\",{\\\"debt_inventory\\\":\\\"技术债务清单\\\"},{\\\"impact_analysis\\\":\\\"影响分析\\\"},{\\\"repayment_plan\\\":\\\"偿还计划\\\"},{\\\"prevention_strategies\\\":\\\"预防策略\\\"}]}\"\n error-recovery-guidance: \"{\\\"on_failure\\\":\\\"债务治理遗漏高优债务时回退到质量度量补充数据\\\",\\\"retry_behavior\\\":\\\"补充数据后重新评估治理优先级\\\"}\"\n categories: \"[\\\"Development\\\",\\\"Testing\\\"]\"\n depth-requirement: \"{\\\"reference_value\\\":\\\"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\\\",\\\"minimum\\\":\\\"至少完成债务识别、成本评估、治理优先级3步\\\"}\"\n---\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。\n> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 技术债务管理\n\n## 核心原则\n\n技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。\n\n## 技术债务类型\n\n### 自动化债务\n\n```text\n债务表现：\n├─ 自动化脚本不稳定\n│ ├─ 频繁失败（假阳性）\n│ ├─ 执行时间过长\n│ └─ 维护成本高\n│\n├─ 自动化覆盖不足\n│ ├─ 核心流程未覆盖\n│ ├─ 边界场景未覆盖\n│ └─ 异常场景未覆盖\n│\n├─ 框架问题\n│ ├─ 框架版本过旧\n│ ├─ 框架设计不合理\n│ └─ 框架文档缺失\n│\n└─ 代码质量\n ├─ 代码重复\n ├─ 代码复杂度高\n └─ 代码可读性差\n```\n\n### 测试债务\n\n```text\n债务表现：\n├─ 用例问题\n│ ├─ 用例过时\n│ ├─ 用例冗余\n│ ├─ 用例覆盖不足\n│ └─ 用例维护困难\n│\n├─ 流程问题\n│ ├─ 测试流程不规范\n│ ├─ 测试执行不彻底\n│ ├─ 缺陷管理混乱\n│ └─ 回归测试不充分\n│\n└─ 环境问题\n ├─ 测试环境不稳定\n ├─ 测试数据不足\n ├─ 测试工具落后\n └─ 测试基础设施薄弱\n```\n\n### 架构债务\n\n```text\n债务表现：\n├─ 可测试性差\n│ ├─ 接口不可Mock\n│ ├─ 日志不完整\n│ ├─ 配置不灵活\n│ └─ 数据不可构造\n│\n├─ 测试架构问题\n│ ├─ 分层不清晰\n│ ├─ 职责不单一\n│ ├─ 扩展性差\n│ └─ 可维护性差\n│\n└─ 集成问题\n ├─ CI/CD集成不完善\n ├─ 报告不规范\n ├─ 监控不完善\n └─ 工具链不统一\n```\n\n## 债务评估\n\n### 评估维度\n\n```text\n├─ 影响度\n│ ├─ 对测试效率的影响\n│ ├─ 对测试质量的影响\n│ ├─ 对团队士气的影响\n│ └─ 对交付速度的影响\n│\n├─ 紧迫度\n│ ├─ 是否阻塞当前工作\n│ ├─ 是否影响发布\n│ ├─ 是否导致线上问题\n│ └─ 是否影响团队效率\n│\n├─ 解决成本\n│ ├─ 人力成本\n│ ├─ 时间成本\n│ ├─ 风险成本\n│ └─ 机会成本\n│\n└─ 解决收益\n ├─ 效率提升\n ├─ 质量提升\n ├─ 成本降低\n └─ 风险降低\n```\n\n### 评估矩阵\n\n| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |\n|---------|--------|--"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-tech-debt-management\",\n \"version\": \"1.8.0\",\n \"publishedAt\": 1790656133285\n}"},{"path":"references/debt-governance.md","content":"# 测试技术债治理详解\n\n> 本文是 `qa-tech-debt-management` 的**测试技术债治理详解**。识别/评估/偿还测试债时读本文；\n其余部分留在 SKILL.md，不必读本文。\n\n---\n\n\n### 治理策略\n\n```text\n├─ 立即解决（P0）\n│ ├─ 阻塞性问题\n│ ├─ 线上问题\n│ └─ 效率严重下降\n│\n├─ 计划解决（P1）\n│ ├─ 影响当前迭代\n│ ├─ 影响团队效率\n│ └─ 风险较高\n│\n├─ 逐步解决（P2）\n│ ├─ 不影响当前工作\n│ ├─ 可以规划解决\n│ └─ 成本较高\n│\n└─ 持续监控（P3）\n ├─ 影响较小\n ├─ 成本较高\n └─ 可以接受\n```\n\n### 治理方法\n\n```text\n自动化债务治理：\n├─ 脚本稳定化\n│ ├─ 修复假阳性\n│ ├─ 优化等待策略\n│ ├─ 增加重试机制\n│ └─ 改进错误处理\n│\n├─ 覆盖提升\n│ ├─ 补充核心流程\n│ ├─ 补充边界场景\n│ ├─ 补充异常场景\n│ └─ 优化测试数据\n│\n└─ 框架升级\n ├─ 版本升级\n ├─ 架构优化\n ├─ 文档完善\n └─ 工具统一\n\n测试债务治理：\n├─ 用例优化\n│ ├─ 清理过时用例\n│ ├─ 合并冗余用例\n│ ├─ 补充覆盖不足\n│ └─ 改进可维护性\n│\n├─ 流程改进\n│ ├─ 规范测试流程\n│ ├─ 完善执行标准\n│ ├─ 改进缺陷管理\n│ └─ 优化回归策略\n│\n└─ 环境改善\n ├─ 稳定测试环境\n ├─ 补充测试数据\n ├─ 升级测试工具\n └─ 完善基础设施\n\n架构债务治理：\n├─ 可测试性改进\n│ ├─ 接口Mock化\n│ ├─ 日志完善\n│ ├─ 配置动态化\n│ └─ 数据构造化\n│\n├─ 架构优化\n│ ├─ 分层清晰化\n│ ├─ 职责单一化\n│ ├─ 扩展性提升\n│ └─ 可维护性提升\n│\n└─ 集成完善\n ├─ CI/CD完善\n ├─ 报告规范化\n ├─ 监控完善\n └─ 工具链统一\n```"},{"path":"skill-card.md","content":"## Description:\n\nHelps QA and engineering teams identify test automation and test-asset debt, estimate maintenance and remediation costs, and plan staged repayment.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA practitioners and developers use this skill to inventory automation, testing, and architecture debt, prioritize remediation by impact and cost, and develop repayment and prevention plans.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad activation terms may invoke the Chinese-language workflow for unrelated requests.\n\nMitigation: Confirm the request concerns QA technical debt and that the workflow language suits the team.\n\nRisk: The optional full skill-set install command does not pin a reviewed version.\n\nMitigation: Verify the source and pin or review the version before running the install command.\n\nRisk: Debt assessments may influence release-blocking or feature-retirement decisions.\n\nMitigation: Confirm the supporting data and discuss risks with development and product owners before acting.\n\n## Reference(s):\n\n- [Test technical-debt governance guide](references/debt-governance.md)\n- [ClawHub skill listing](https://clawhub.ai/kokxi/skills/qa-tech-debt-management)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Guidance]\n\n**Output Format:** [Markdown debt inventory, impact analysis, repayment plan, and prevention strategies]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Reports are written to the workspace; debt items retain related defect or automation-architecture IDs when available.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill metadata and ClawHub release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans. Skill: qa-tech-debt-management Owner: kokxi Summary: 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是\"为什么有这么多 flaky test\"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans. Tags:","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1001,"uniquenessScore":50,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T07:55:37.589Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T07:55:37.589Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:51:26.562Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}