[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70MB6VR8ERJ4EM8D5KHBMEV":3,"skill-same:01M70MB6VR8ERJ4EM8D5KHBMEV":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M70MB6VR8ERJ4EM8D5KHBMEV","technical-debt-auditor",null,"Scans a codebase and produces a quantified technical debt report with a prioritized remediation plan. Analyzes dead code, TODO\u002FFIXME\u002FHACK markers, dependency staleness, complexity hotspots, code duplication signals, test coverage gaps, unused exports, and outdated patterns. Use this skill when the user asks to audit their codebase for tech debt, wants a health check of their code quality, says things like \"where should I focus refactoring\", \"find code smells\", \"audit my codebase\", \"what technical debt do we have\", \"prioritize cleanup work\", or asks about code quality metrics. Also trigger when the user mentions \"code rot\", \"legacy cleanup\", \"refactoring priorities\", or wants to understand the overall health of a project before a major effort. Trigger even if the user doesn't say \"technical debt\" explicitly — any request to systematically assess code quality and identify improvement priorities belongs here.","davila7\u002Fclaude-code-templates","davila7","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6216945?v=4","01M6ADEWWFPS191NFM0Y1EX1JH","Daniel Avila","01M6ADJHGM78PHQRD3XZTFDVKK",33286,"MIT","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Ftechnical-debt-auditor\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"debt","technical","technical debt auditor","auditor","technical debt","dependency","audit","signals","focus","plan","work","todo","code","when","unused","cleanup","project","markers","complexity","coverage","2026-11-10 10:12:30",false,"---\nname: technical-debt-auditor\ndescription: >\n  Scans a codebase and produces a quantified technical debt report with a prioritized remediation\n  plan. Analyzes dead code, TODO\u002FFIXME\u002FHACK markers, dependency staleness, complexity hotspots,\n  code duplication signals, test coverage gaps, unused exports, and outdated patterns. Use this\n  skill when the user asks to audit their codebase for tech debt, wants a health check of their\n  code quality, says things like \"where should I focus refactoring\", \"find code smells\", \"audit\n  my codebase\", \"what technical debt do we have\", \"prioritize cleanup work\", or asks about code\n  quality metrics. Also trigger when the user mentions \"code rot\", \"legacy cleanup\", \"refactoring\n  priorities\", or wants to understand the overall health of a project before a major effort.\n  Trigger even if the user doesn't say \"technical debt\" explicitly — any request to systematically\n  assess code quality and identify improvement priorities belongs here.\n---\n\n# Technical Debt Auditor\n\nYou are performing a systematic technical debt audit of this codebase. Your goal: produce a\nquantified, actionable report that tells the team exactly where their debt is, how severe it is,\nand what to fix first. This is not a vague \"code review\" — it's a structured scan with concrete\nmetrics and a prioritized remediation plan.\n\nTechnical debt is like financial debt — it accumulates interest. A quick hack today costs 10x more\nto fix in six months when three features depend on it. Your job is to find the debt before the\ninterest compounds, quantify it so it can be prioritized against feature work, and give the team\na realistic plan to pay it down.\n\n## What you're scanning for\n\n| Debt category | What to look for | Why it matters |\n|---|---|---|\n| **Marker debt** | TODO, FIXME, HACK, XXX, TEMP, WORKAROUND comments | Developers flagged these as known shortcuts — they're self-reported debt |\n| **Dead code** | Unused exports, unreachable branches, commented-out code blocks, unused files | Dead code misleads readers, adds cognitive load, and sometimes hides bugs |\n| **Dependency debt** | Outdated packages, deprecated APIs, pinned-to-old-major versions, unused deps in package manifest | Stale deps accumulate security vulns and block upgrades |\n| **Complexity hotspots** | Large files (>300 lines), large functions (>50 lines), deeply nested logic (>3 levels), high cyclomatic complexity | Complex code is where bugs hide and where changes are slowest |\n| **Duplication signals** | Near-identical code blocks, copy-pasted patterns with slight variations | Duplication means bug fixes need to happen in N places instead of 1 |\n| **Test gaps** | Missing test files for modules, low assertion density, test files that only test happy paths | Untested code is where regressions slip through |\n| **Outdated patterns** | Patterns that contradict the project's own conventions, deprecated language features, legacy API usage | Inconsistency slows onboarding and creates confusion |\n| **Config debt** | Stale configs, conflicting settings, environment files with unused variables | Config debt causes \"works on my machine\" bugs and deploy failures |\n\n## PHASE 1 — RECONNAISSANCE\n\nBefore scanning anything, understand the project:\n\n1. **Identify the tech stack** — read package.json, Cargo.toml, pyproject.toml, go.mod, or whatever the project uses. Note the language(s), framework(s), package manager, and build system.\n2. **Find the entry points** — where does the application start? What are the main modules?\n3. **Check for existing quality tooling** — linters, formatters, type checkers, test runners, CI config. Understanding what's already enforced tells you what NOT to flag (e.g., don't report style issues if prettier is configured).\n4. **Read any CLAUDE.md or project docs** — these may contain conventions that inform what counts as \"outdated\" vs \"intentional.\"\n5. **Note the project scale** — file count, approximate lines of code. This calibrates your effort estimates later.\n\nDo not start scanning until you have this context. A \"large function\" in a 200-line CLI script means something different than in a 50,000-line enterprise app.\n\n## PHASE 2 — SYSTEMATIC SCAN\n\nWork through each debt category methodically. For each category, use the appropriate tools:\n\n### Marker debt scan\nSearch for these patterns across all source files (not node_modules, vendor, build output):\n- `TODO`, `FIXME`, `HACK`, `XXX`, `TEMP`, `WORKAROUND`, `KLUDGE`, `DEPRECATED`\n- Note the file, line number, and surrounding context for each\n- Classify each by severity: `HACK`\u002F`FIXME` are higher severity than `TODO`\n- Check dates if present — older markers indicate forgotten debt\n\n### Dead code scan\n- Look for exported functions\u002Fclasses that are never imported elsewhere\n- Find commented-out code blocks (more than 2 consecutive commented lines of code, not documentation comments)\n- Check for files that nothing imports or references\n- Look for unreachable code after return\u002Fthrow\u002Fbreak statements\n- Check for unused variables and imports that linters haven't caught\n\n### Dependency debt scan\n- Read the package manifest and lockfile\n- For Node.js: check `package.json` dependencies against actual imports; flag packages in dependencies that aren't imported anywhere\n- Look for deprecated package warnings in lockfiles\n- Check major version gaps (e.g., package is on v2 but v5 is current)\n- Note any dependency with known security advisories if identifiable from lockfile metadata\n\n### Complexity hotspot scan\n- Find the largest files by line count — list the top 10\n- Within those files, find the largest functions\u002Fmethods\n- Look for deeply nested conditionals (if\u002Felse chains >3 levels deep)\n- Flag god classes\u002Fmodules that do too many things (heuristic: >10 public methods or >5 unrelated responsibilities)\n- Check for overly long parameter lists (>5 parameters)\n\n### Duplication signal scan\n- Look for structurally similar code blocks across files\n- Check for copy-pasted error handling patterns\n- Find repeated business logic that should be extracted into shared utilities\n- Note: you're looking for significant duplication (>10 lines of near-identical logic), not trivial similarities\n\n### Test gap scan\n- Map source files to test files — which source files have no corresponding test?\n- Look at existing tests: are they just smoke tests or do they test edge cases?\n- Check for test files that are skipped (.skip, @Ignore, etc.)\n- Note any mocking that's testing implementation details rather than behavior\n\n### Outdated pattern scan\n- Compare patterns used across the codebase — is most of the code using pattern A while a few files use deprecated pattern B?\n- Look for deprecated language features (e.g., `var` in modern JS, `string.format` over f-strings in Python 3.6+)\n- Check for inconsistent error handling strategies across modules\n- Flag any usage of APIs marked as deprecated in the codebase itself\n\n### Config debt scan\n- Compare `.env.example` (if present) against actual usage — are all vars still needed?\n- Look for conflicting configs (e.g., tsconfig extending differently in subpackages)\n- Check for hardcoded values that should be configurable\n\n## PHASE 3 — QUANTIFY AND SCORE\n\nFor each finding, assign a severity and effort estimate:\n\n### Severity levels\n\n| Level | Criteria | Examples |\n|---|---|---|\n| **Critical** | Actively causing bugs, security risks, or blocking upgrades | Security-vulnerable dependency, dead code hiding a bug, broken test suite |\n| **High** | Will cause significant pain if not addressed soon — compounds quickly | God class everyone's afraid to touch, major version dependency gap, zero test coverage on critical path |\n| **Medium** | Genuine debt that slows development but isn't urgent | TODO markers older than 6 months, moderate duplication, missing tests for non-critical paths |\n| **Low** | Cleanup work that improves quality but has low blast radius | Commented-out code, minor inconsistencies, unused config variables |\n\n### Effort estimates\n\n| Level | Meaning |\n|---|---|\n| **Trivial** | \u003C 30 minutes — delete dead code, remove stale TODOs, drop unused deps |\n| **Small** | 1-4 hours — extract duplicated logic, add missing tests for a module, update a dependency |\n| **Medium** | 1-3 days — refactor a complex module, migrate a deprecated pattern across the codebase |\n| **Large** | 1-2 weeks — rewrite a god class, major dependency upgrade with breaking changes |\n\n## PHASE 4 — REPORT\n\nPresent findings in this exact structure:\n\n```\n# Technical Debt Audit Report\n\n## Executive Summary\n- **Project**: \u003Cname> (\u003Clanguage\u002Fframework>)\n- **Files scanned**: \u003Ccount>\n- **Total findings**: \u003Ccount>\n- **Critical**: \u003Ccount> | **High**: \u003Ccount> | **Medium**: \u003Ccount> | **Low**: \u003Ccount>\n- **Estimated total remediation effort**: \u003Crange>\n- **Top 3 priorities**: \u003Cone-line each>\n\n## Debt Heatmap\n\n\u003CTable showing files with the most findings, sorted by severity-weighted score>\n\n| File | Critical | High | Medium | Low | Debt Score |\n|------|----------|------|--------|-----|------------|\n| ... | ... | ... | ... | ... | ... |\n\n## Findings by Category\n\n### 1. [Category Name] — [count] findings\n\n#### [Severity] [Brief description]\n- **File**: `path\u002Fto\u002Ffile.ts:42`\n- **What**: \u003Cspecific description of the debt>\n- **Why it matters**: \u003Cconcrete consequence if not addressed>\n- **Suggested fix**: \u003Cactionable remediation step>\n- **Effort**: \u003CTrivial|Small|Medium|Large>\n\n(repeat for each finding)\n\n## Remediation Plan\n\n### Immediate (this sprint)\n\u003CCritical and high-severity items with trivial\u002Fsmall effort — highest ROI>\n\n### Short-term (next 2-4 weeks)\n\u003CHigh-severity items with medium effort, critical items with large effort>\n\n### Medium-term (next quarter)\n\u003CMedium-severity items, larger refactoring efforts>\n\n### Backlog\n\u003CLow-severity items to tackle opportunistically>\n\n## Metrics Summary\n\n| Metric | Value |\n|--------|-------|\n| Marker density (TODOs per 1K lines) | ... |\n| Dead code ratio (unused exports \u002F total exports) | ... |\n| Test coverage (files with tests \u002F total source files) | ... |\n| Dependency freshness (up-to-date \u002F total deps) | ... |\n| Average file size (lines) | ... |\n| Largest file (lines) | ... |\n| Files with >3 nesting levels | ... |\n```\n\n## Important behavioral notes\n\n- **Be specific, not vague.** Every finding must reference exact files and line numbers. \"There's some duplication\" is worthless. \"`src\u002Fhandlers\u002Fuser.ts:45-78` and `src\u002Fhandlers\u002Fadmin.ts:32-65` contain nearly identical validation logic\" is actionable.\n\n- **Don't flag what tooling handles.** If the project has eslint configured with `no-unused-vars`, don't report unused variables — the linter catches those. Focus on debt that falls through the cracks of existing tooling.\n\n- **Calibrate to the project.** A 500-line utility script doesn't need the same scrutiny as a production API. If the project is a prototype or early-stage, say so and adjust severity accordingly. Don't recommend enterprise patterns for a weekend project.\n\n- **Respect intentional tradeoffs.** Some \"debt\" is deliberate. If a comment says \"\u002F\u002F Intentionally using X because Y\", don't flag it. If the README says \"we chose library A over B for reason Z\", don't report it as outdated.\n\n- **The remediation plan is the most important part.** Teams can find TODOs themselves — what they need is someone to prioritize the work and explain the ROI of each fix. Spend the most effort making the remediation plan realistic and well-sequenced (don't suggest refactoring module A before module B if B depends on A).\n\n- **Count things.** Actually count the lines, the files, the findings. The executive summary numbers must be accurate. If you say \"42 findings\" the report should contain exactly 42 findings.\n\n- **Debt score formula.** For the heatmap, weight findings: Critical = 8, High = 4, Medium = 2, Low = 1. Sum per file. This gives a single sortable number.\n","# Technical Debt Auditor\n\nYou are performing a systematic technical debt audit of this codebase. Your goal: produce a\nquantified, actionable report that tells the team exactly where their debt is, how severe it is,\nand what to fix first. This is not a vague \"code review\" — it's a structured scan with concrete\nmetrics and a prioritized remediation plan.\n\nTechnical debt is like financial debt — it accumulates interest. A quick hack today costs 10x more\nto fix in six months when three features depend on it. Your job is to find the debt before the\ninterest compounds, quantify it so it can be prioritized against feature work, and give the team\na realistic plan to pay it down.\n\n## What you're scanning for\n\n| Debt category | What to look for | Why it matters |\n|---|---|---|\n| **Marker debt** | TODO, FIXME, HACK, XXX, TEMP, WORKAROUND comments | Developers flagged these as known shortcuts — they're self-reported debt |\n| **Dead code** | Unused exports, unreachable branches, commented-out code blocks, unused files | Dead code misleads readers, adds cognitive load, and sometimes hides bugs |\n| **Dependency debt** | Outdated packages, deprecated APIs, pinned-to-old-major versions, unused deps in package manifest | Stale deps accumulate security vulns and block upgrades |\n| **Complexity hotspots** | Large files (>300 lines), large functions (>50 lines), deeply nested logic (>3 levels), high cyclomatic complexity | Complex code is where bugs hide and where changes are slowest |\n| **Duplication signals** | Near-identical code blocks, copy-pasted patterns with slight variations | Duplication means bug fixes need to happen in N places instead of 1 |\n| **Test gaps** | Missing test files for modules, low assertion density, test files that only test happy paths | Untested code is where regressions slip through |\n| **Outdated patterns** | Patterns that contradict the project's own conventions, deprecated language features, legacy API usage | Inconsistency slows onboarding and creates confusion |\n| **Config debt** | Stale configs, conflicting settings, environment files with unused variables | Config debt causes \"works on my machine\" bugs and deploy failures |\n\n## PHASE 1 — RECONNAISSANCE\n\nBefore scanning anything, understand the project:\n\n1. **Identify the tech stack** — read package.json, Cargo.toml, pyproject.toml, go.mod, or whatever the project uses. Note the language(s), framework(s), package manager, and build system.\n2. **Find the entry points** — where does the application start? What are the main modules?\n3. **Check for existing quality tooling** — linters, formatters, type checkers, test runners, CI config. Understanding what's already enforced tells you what NOT to flag (e.g., don't report style issues if prettier is configured).\n4. **Read any CLAUDE.md or project docs** — these may contain conventions that inform what counts as \"outdated\" vs \"intentional.\"\n5. **Note the project scale** — file count, approximate lines of code. This calibrates your effort estimates later.\n\nDo not start scanning until you have this context. A \"large function\" in a 200-line CLI script means something different than in a 50,000-line enterprise app.\n\n## PHASE 2 — SYSTEMATIC SCAN\n\nWork through each debt category methodically. For each category, use the appropriate tools:\n\n### Marker debt scan\nSearch for these patterns across all source files (not node_modules, vendor, build output):\n- `TODO`, `FIXME`, `HACK`, `XXX`, `TEMP`, `WORKAROUND`, `KLUDGE`, `DEPRECATED`\n- Note the file, line number, and surrounding context for each\n- Classify each by severity: `HACK`\u002F`FIXME` are higher severity than `TODO`\n- Check dates if present — older markers indicate forgotten debt\n\n### Dead code scan\n- Look for exported functions\u002Fclasses that are never imported elsewhere\n- Find commented-out code blocks (more than 2 consecutive commented lines of code, not documentation comments)\n- Check for files that nothing imports or references\n- Look for unreachable code after return\u002Fthrow\u002Fbreak statements\n- Check for unused variables and imports that linters haven't caught\n\n### Dependency debt scan\n- Read the package manifest and lockfile\n- For Node.js: check `package.json` dependencies against actual imports; flag packages in dependencies that aren't imported anywhere\n- Look for deprecated package warnings in lockfiles\n- Check major version gaps (e.g., package is on v2 but v5 is current)\n- Note any dependency with known security advisories if identifiable from lockfile metadata\n\n### Complexity hotspot scan\n- Find the largest files by line count — list the top 10\n- Within those files, find the largest functions\u002Fmethods\n- Look for deeply nested conditionals (if\u002Felse chains >3 levels deep)\n- Flag god classes\u002Fmodules that do too many things (heuristic: >10 public methods or >5 unrelated responsibilities)\n- Check for overly long parameter lists (>5 parameters)\n\n### Duplication signal scan\n- Look for structurally similar code blocks across files\n- Check for copy-pasted error handling patterns\n- Find repeated business logic that should be extracted into shared utilities\n- Note: you're looking for significant duplication (>10 lines of near-identical logic), not trivial similarities\n\n### Test gap scan\n- Map source files to test files — which source files have no corresponding test?\n- Look at existing tests: are they just smoke tests or do they test edge cases?\n- Check for test files that are skipped (.skip, @Ignore, etc.)\n- Note any mocking that's testing implementation details rather than behavior\n\n### Outdated pattern scan\n- Compare patterns used across the codebase — is most of the code using pattern A while a few files use deprecated pattern B?\n- Look for deprecated language features (e.g., `var` in modern JS, `string.format` over f-strings in Python 3.6+)\n- Check for inconsistent error handling strategies across modules\n- Flag any usage of APIs marked as deprecated in the codebase itself\n\n### Config debt scan\n- Compare `.env.example` (if present) against actual usage — are all vars still needed?\n- Look for conflicting configs (e.g., tsconfig extending differently in subpackages)\n- Check for hardcoded values that should be configurable\n\n## PHASE 3 — QUANTIFY AND SCORE\n\nFor each finding, assign a severity and effort estimate:\n\n### Severity levels\n\n| Level | Criteria | Examples |\n|---|---|---|\n| **Critical** | Actively causing bugs, security risks, or blocking upgrades | Security-vulnerable dependency, dead code hiding a bug, broken test suite |\n| **High** | Will cause significant pain if not addressed soon — compounds quickly | God class everyone's afraid to touch, major version dependency gap, zero test coverage on critical path |\n| **Medium** | Genuine debt that slows development but isn't urgent | TODO markers older than 6 months, moderate duplication, missing tests for non-critical paths |\n| **Low** | Cleanup work that improves quality but has low blast radius | Commented-out code, minor inconsistencies, unused config variables |\n\n### Effort estimates\n\n| Level | Meaning |\n|---|---|\n| **Trivial** | \u003C 30 minutes — delete dead code, remove stale TODOs, drop unused deps |\n| **Small** | 1-4 hours — extract duplicated logic, add missing tests for a module, update a dependency |\n| **Medium** | 1-3 days — refactor a complex module, migrate a deprecated pattern across the codebase |\n| **Large** | 1-2 weeks — rewrite a god class, major dependency upgrade with breaking changes |\n\n## PHASE 4 — REPORT\n\nPresent findings in this exact structure:\n\n```\n# Technical Debt Audit Report\n\n## Executive Summary\n- **Project**: \u003Cname> (\u003Clanguage\u002Fframework>)\n- **Files scanned**: \u003Ccount>\n- **Total findings**: \u003Ccount>\n- **Critical**: \u003Ccount> | **High**: \u003Ccount> | **Medium**: \u003Ccount> | **Low**: \u003Ccount>\n- **Estimated total remediation effort**: \u003Crange>\n- **Top 3 priorities**: \u003Cone-line each>\n\n## Debt Heatmap\n\n\u003CTable showing files with the most findings, sorted by severity-weighted score>\n\n| File | Critical | High | Medium | Low | Debt Score |\n|------|----------|------|--------|-----|------------|\n| ... | ... | ... | ... | ... | ... |\n\n## Findings by Category\n\n### 1. [Category Name] — [count] findings\n\n#### [Severity] [Brief description]\n- **File**: `path\u002Fto\u002Ffile.ts:42`\n- **What**: \u003Cspecific description of the debt>\n- **Why it matters**: \u003Cconcrete consequence if not addressed>\n- **Suggested fix**: \u003Cactionable remediation step>\n- **Effort**: \u003CTrivial|Small|Medium|Large>\n\n(repeat for each finding)\n\n## Remediation Plan\n\n### Immediate (this sprint)\n\u003CCritical and high-severity items with trivial\u002Fsmall effort — highest ROI>\n\n### Short-term (next 2-4 weeks)\n\u003CHigh-severity items with medium effort, critical items with large effort>\n\n### Medium-term (next quarter)\n\u003CMedium-severity items, larger refactoring efforts>\n\n### Backlog\n\u003CLow-severity items to tackle opportunistically>\n\n## Metrics Summary\n\n| Metric | Value |\n|--------|-------|\n| Marker density (TODOs per 1K lines) | ... |\n| Dead code ratio (unused exports \u002F total exports) | ... |\n| Test coverage (files with tests \u002F total source files) | ... |\n| Dependency freshness (up-to-date \u002F total deps) | ... |\n| Average file size (lines) | ... |\n| Largest file (lines) | ... |\n| Files with >3 nesting levels | ... |\n```\n\n## Important behavioral notes\n\n- **Be specific, not vague.** Every finding must reference exact files and line numbers. \"There's some duplication\" is worthless. \"`src\u002Fhandlers\u002Fuser.ts:45-78` and `src\u002Fhandlers\u002Fadmin.ts:32-65` contain nearly identical validation logic\" is actionable.\n\n- **Don't flag what tooling handles.** If the project has eslint configured with `no-unused-vars`, don't report unused variables — the linter catches those. Focus on debt that falls through the cracks of existing tooling.\n\n- **Calibrate to the project.** A 500-line utility script doesn't need the same scrutiny as a production API. If the project is a prototype or early-stage, say so and adjust severity accordingly. Don't recommend enterprise patterns for a weekend project.\n\n- **Respect intentional tradeoffs.** Some \"debt\" is deliberate. If a comment says \"\u002F\u002F Intentionally using X because Y\", don't flag it. If the README says \"we chose library A over B for reason Z\", don't report it as outdated.\n\n- **The remediation plan is the most important part.** Teams can find TODOs themselves — what they need is someone to prioritize the work and explain the ROI of each fix. Spend the most effort making the remediation plan realistic and well-sequenced (don't suggest refactoring module A before module B if B depends on A).\n\n- **Count things.** Actually count the lines, the files, the findings. The executive summary numbers must be accurate. If you say \"42 findings\" the report should contain exactly 42 findings.\n\n- **Debt score formula.** For the heatmap, weight findings: Critical = 8, High = 4, Medium = 2, Low = 1. Sum per file. This gives a single sortable number.\n",{"name":5,"description":7},"main","a6e6f93e9a4baaa6ff337aee5505bf5c2bae4ce6","cli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Ftechnical-debt-auditor",3909,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates","https:\u002F\u002Faitmpl.com","https:\u002F\u002Fgithub.com\u002Fdavila7","https:\u002F\u002Fdanielavila.me","Building AI dev tools with LLMs","2026-11-11 11:53:30",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add davila7\u002Fclaude-code-templates --skill technical-debt-auditor",{"tool":65,"command":66},"bunx","bunx skills add davila7\u002Fclaude-code-templates --skill technical-debt-auditor",{"tool":68,"command":69},"pnpm","pnpm dlx skills add davila7\u002Fclaude-code-templates --skill technical-debt-auditor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Ftechnical-debt-auditor\u002FSKILL.md",true,[],[74,101,134,169,193,229],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":81,"publishedAt":44},"01M70NHBTQ8BV0A2SCAZXEPHCX","wealthville-pool-scoring","Score DeFi liquidity pools before providing liquidity. Returns a 0-100 pool score and an Enter\u002FHold\u002FExit\u002FReduce\u002FAvoid verdict with calibrated confidence for ~68,800 Solana pools and 575 EVM pools, plus a public miss-inclusive track record. Use when asked whether a pool is worth LPing into, which pools look best right now, or how accurate the scores have actually been.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fweb-data\u002Fwealthville-pool-scoring\u002FSKILL.md",[80],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[82,83,84,85,86,87,88,89,90,37,91,92,93,94,95,96,97,98,99,100],"scoring","pool","wealthville pool scoring","liquidity","which","for","exit","now","use","reduce","with","record","track","verdict","evm","solana","how","public","look",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":116,"publishedAt":44},"01M70KPYH9QNHCNME5GJQGE22K","readonly-sql-guard","Make an agent's database access provably read-only. Use when an agent runs caller-supplied SQL against a production\u002FERP\u002Fanalytics database (a \"query\" MCP tool, text-to-SQL, an admin console), or when reviewing DB-access code for write\u002FDDL\u002Fside-effect\u002Ftransaction-escape risks. Checks what a statement CALLS, not just its shape.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdatabase\u002Freadonly-sql-guard\u002FSKILL.md",[107,110,111],{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[117,118,119,120,121,122,123,87,124,125,126,127,128,129,130,90,131,132,37,133],"readonly","guard","sql guard","sql","readonly sql guard","erp","effect","read-only","db","just","tool","calls","only","MCP","access","database","query",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":138,"licenseFileUrl":139,"sourceHtmlUrl":140,"categories":141,"keywords":145,"publishedAt":44},"01M6AFY6F7CC2BBZP1QD6VTNVC","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,87,168],"artifacts builder","web","web artifacts builder","artifacts","builder","state","routing","state management","component","css","frontend","ui","Tools","file","components","shadcn","react","Tailwind","suite","jsx","html","single-file","ui components",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":138,"licenseFileUrl":173,"sourceHtmlUrl":174,"categories":175,"keywords":180,"publishedAt":44},"01M6AFWF33SFV9Z3SF4PEEE4BF","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FSKILL.md",[176,179],{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":143,"categoryName":144,"taxonomyType":21,"taxonomyTypeDesc":22},[181,182,183,184,185,147,186,156,157,187,188,189,190,87,191,92,192],"webapp testing","testing","webapp","browser","playwright","applications","debugging","toolkit","logs","screenshots","local","behavior",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":138,"licenseFileUrl":197,"sourceHtmlUrl":198,"categories":199,"keywords":207,"publishedAt":44},"01M6AF67Q67JJJ5V51JR2P52KA","discernment-nudge","After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FSKILL.md",[200,203,204],{"categoryNo":201,"categoryName":202,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":205,"categoryName":206,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000036","内容创作者",[208,209,210,211,212,213,214,215,149,216,159,36,217,218,219,220,221,129,222,37,223,224,225,226,227,98,228],"discernment nudge","nudge","interpretation","help","run","reasoning","data","writing","lookup","content","review","conversation","short","up","invoke","you","analysis","claims","argument","assemble","recommendations",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":138,"licenseFileUrl":233,"sourceHtmlUrl":234,"categories":235,"keywords":240,"publishedAt":44},"01M6AF5ANME9NAHVVR7N1F63MP","academy-guide","Stop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: \"how do I\", \"how can I\", \"getting started with\", \"what can Claude do\", \"teach me\", \"learn to use\"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Facademy-guide\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Facademy-guide\u002FSKILL.md",[236,237],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":238,"categoryName":239,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000039","教师与教育",[241,242,243,244,245,246,130,247,248,149,217,249,250,251,252,253,254,255,256,257,129,258,259,37,260,261,262,263],"academy guide","guide","documentation","product","training","plugins","docs","learn","onboarding","connectors","teach","getting started","projects","resources","never","onboarding content","how to","question","task done","done","ask","team","me"]