[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPF174QENVJSQDFST9MP8B":3,"skill-same:01M6JPF174QENVJSQDFST9MP8B":103},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":14,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6JPF174QENVJSQDFST9MP8B","technical-debt-review",null,"Strategic codebase health assessment — identify hotspots, categorize debt, produce remediation roadmap.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"technical debt review","technical debt","technical","review","roadmap","legacy code","remediation plan","health assessment","tech","triggers","general","categorize","fix","plan","code audit","remediation","audit","produce","code","assessment","2026-11-10 10:12:30",false,"---\nname: technical-debt-review\ndescription: \"Strategic codebase health assessment — identify hotspots, categorize debt, produce remediation roadmap.\"\nwhen_to_use: \"Triggers: technical debt, tech debt, debt review, codebase health, hotspots, debt assessment, remediation plan, what should we fix first, debt roadmap, code rot, legacy code audit.\"\ncontext: fork\nagent: general-purpose\n---\n\n# Technical Debt Review\n\nProduce a strategic picture of where the codebase is accumulating debt and what to do about it. The goal is a prioritized roadmap, not an exhaustive list of every imperfection.\n\n## Step 1: Identify Hotspots\n\nDon't try to review everything. Focus on where pain is concentrated.\n\n**Code complexity signals:**\n- Files or functions with high cyclomatic complexity (many branches, deep nesting)\n- Functions over ~50 lines — usually doing too much (SRP violation)\n- Classes over ~300 lines — usually a God class or multiple responsibilities\n- High number of parameters (> 5 usually indicates missing abstraction)\n\n**Change frequency signals (most valuable):**\n- Files changed in almost every PR — high churn indicates poor separation of concerns or missing abstractions\n- Files that always require changes together — tight coupling that should be decoupled\n- Files with frequent bug fixes — instability indicates unclear ownership or poor test coverage\n- AI-assisted bulk commits — large multi-file commits landing at once and revised within days; churn-shortly-after-landing is the strongest slop signal\n\n**Structural signals:**\n- Circular dependencies between modules\n- Modules that import from many other modules — likely a coordination layer doing too much\n- Dead code (functions\u002Fclasses with no callers)\n\n**Test coverage signals:**\n- Untested code paths in critical or high-churn files\n- Tests that only test happy paths (no edge cases, no error cases)\n- Test files significantly longer than the code they test (over-specified tests that break on refactoring)\n\nIf the request came with team pain points (where engineers slow down, code people avoid touching, where bugs keep appearing), weight those hotspots first. This skill runs in a forked context and cannot ask mid-run — when that input is missing, proceed on the code signals above and list \"where does the team actually hurt?\" under Open questions in the report.\n\n## Step 2: Categorize by Debt Type and Severity\n\nFor each hotspot, classify the debt:\n\n**Debt types:**\n| Type | Description | Typical fix |\n|------|-------------|-------------|\n| **Complexity debt** | Functions\u002Fclasses doing too much | Extract, decompose, simplify |\n| **Duplication debt** | Same logic in multiple places | Extract shared abstraction |\n| **Test debt** | Missing or low-quality tests | Add tests before refactoring anything else |\n| **Documentation debt** | Undocumented non-obvious behavior (docs *missing*) | Add comments, docstrings, decision records |\n| **Documentation drift** | Docs describing behavior, endpoints, or flags that no longer exist | Fix or delete the stale doc |\n| **Architecture debt** | Wrong abstraction at system level | Restructure, introduce proper boundaries |\n| **Dependency debt** | Outdated, vulnerable, or abandoned libraries | Upgrade or replace |\n| **Type debt** | `any`\u002Fcasts silencing the checker, single-implementer interfaces \"for testing\", overly broad types | Restore real types; inline the interface |\n| **Config\u002Fscaffolding debt** | Unread config keys\u002Fflags, orphan `.env` entries, checked-in generated files, TODO scaffolds | Delete what nothing reads; regenerate instead of committing |\n| **Observability debt** | No logging, metrics, or traceability | Add instrumentation |\n\n**Severity:**\n- **Critical**: Causing active bugs or security risks. Address immediately.\n- **High**: Slowing down every sprint. Blocking new features. Schedule for next quarter.\n- **Medium**: Painful but workable. Schedule when capacity allows.\n- **Low**: Noticeable but not impeding. Do it opportunistically when touching related code.\n\nFor the AI-slop lens on these categories (per-pattern tells and when-it's-NOT-slop guidance), read the sibling skill's `code-slop-cleanup\u002Freferences\u002Fslop-patterns.md` if installed.\n\n## AI-Slop Audit Mode\n\nWhen the request is specifically an **AI-slop audit** (not a general debt roadmap for\nplanning) — \"audit this repo for AI slop\", \"full slop review\", \"what slop did the agents\nleave\" — keep the same integrity discipline but shift the output:\n\n- **Score the 14 slop categories, not the debt types.** Duplication · premature\n  abstraction · dead\u002Funreachable code · defensive theater · verbose\u002Finflated · comment\n  slop · naming\u002Forganization · type slop · error-handling slop · test slop · dependency\n  slop · structural\u002Farchitectural · config\u002Fscaffolding · documentation drift. A scorecard\n  row per category (count · worst severity · one-line note) is the map.\n- **Find the systemic patterns — \"fix once at the source.\"** The highest-value section is\n  not the finding list but the handful of **root causes** that parent it: \"the same wiring\n  ritual pasted 18× (P1)\", \"no shared test scaffold, so fixtures duplicate across 6 files\n  (P2)\", \"one impure `resolve()` leaks `SystemExit`, forcing lossy handling at 7 callers\n  (P3).\" Collapse dozens of findings to a few roots, then fix the root.\n- **Use the static-tooling method and the report format** in\n  [references\u002Fslop-audit-method.md](references\u002Fslop-audit-method.md) (per-language tool\n  menu — jscpd\u002Fknip\u002Fvulture\u002Fdeptry\u002Fruff\u002Fmypy — plus git-churn and grep\u002F`diff` verification)\n  and write the report with [templates\u002Fslop-audit.md](templates\u002Fslop-audit.md).\n\nEverything below (Audit Integrity, evidence, \"Explicitly not flagged\", method log) applies\nunchanged — a slop audit that invents findings is worse than one that misses them.\n\n## Audit Integrity — do not generate slop while hunting it\n\nA wrong finding costs the audit more credibility than a missed one, and this skill runs in a forked context: the written report is the only artifact that survives, so an unevidenced finding is unfalsifiable downstream. Rules for every finding:\n\n- **Evidence or it didn't happen.** Cite `path:line-range` and quote the offending code minimally. No location, no finding.\n- **Argue it, don't label it.** State *why the specific instance is unjustified here* — what it costs and why the pattern lacks a reason that survives scrutiny. \"I'd do it differently\" is preference, not debt.\n- **Attempt to disprove before flagging.** Trace callers before declaring code dead (dynamic references, string-based lookups, DI, reflection, external consumers); check history before calling a config key unread. If a legitimate reason emerges, downgrade or drop.\n- **Confidence, not assertion.** Unverifiable usage claims get Confidence: Low with a note on what would confirm it — never asserted as fact.\n- **Record what you didn't flag.** An \"Explicitly not flagged\" section (items considered, reason they survived scrutiny) proves the audit was discerning and stops the team re-litigating.\n- **Log the method.** Tools\u002Fpasses run with their commands, and anything not covered — unreadable files, missing test env — as named blind spots. If a tool wasn't available, say so; don't fabricate its results.\n\n## Step 3: Estimate Effort and Risk\n\nFor each hotspot, estimate:\n\n**Effort**: hours\u002Fdays\u002Fweeks of engineering work to address\n**Risk**: probability that addressing this introduces new bugs (higher for untested, complex code)\n**Prerequisite**: does this require tests before it can be safely changed? (almost always yes for High\u002FCritical)\n\nHigh-risk + no tests = address the tests first, before the underlying debt.\n\n## Step 4: Prioritize by Value-to-Cost Ratio\n\nScore each item: `(Severity × Impact on team velocity) \u002F (Effort × Risk)`\n\nPrioritize in this order:\n1. **Quick wins**: Low effort, meaningful impact (inconsistent naming conventions, easy extractions)\n2. **High pain, medium effort**: The things that slow every sprint down — worth dedicated sprint time\n3. **Strategic investments**: High effort but unlocks future capability — needs executive buy-in and planned downtime from feature work\n4. **Low impact**: Log them, don't schedule them — address opportunistically\n\nAvoid the \"big rewrite\" trap. Long rewrites stall feature work, introduce new bugs, and often fail to ship. Prefer incremental improvement over big-bang rewrites.\n\n## Step 5: Produce the Remediation Roadmap\n\nOutput a prioritized action plan:\n\n**Immediate (this sprint):**\n- [Quick win 1]: estimated [X hours], owner [Name]\n- [Critical fix 1]: estimated [Y days], owner [Name]\n\n**Next quarter:**\n- [High-priority debt 1]: estimated [X weeks], requires [tests\u002Fmigration\u002Fteam availability]\n- [High-priority debt 2]: ...\n\n**Backlog (do when touching related code):**\n- [Medium items to address opportunistically]\n\n**Accepted debt (won't address):**\n- [Items acknowledged but explicitly not worth fixing] — revisit if severity changes\n\nUse [templates\u002Fdebt-audit.md](templates\u002Fdebt-audit.md) for the full audit format.\n\n**Write the full audit to a file** (default a gitignored location, e.g.\n`.local\u002Fdebt-review-\u003Cdate>.md`) and state its path in your final summary — this\nskill runs in a forked context: only the summary returns, everything unwritten is\nlost. Judgment calls that need user input (e.g. which subsystem matters most,\nunknown team pain points) go in an **Open questions** section of the report, never\nguessed silently.\n\n## Principles Applied\n\n- **KISS**: Simplify complexity first — complex code is the root cause of most other debt\n- **DRY**: Eliminate duplication — find the patterns, create the abstraction\n- **SRP**: Split God classes and functions doing multiple jobs into focused units\n- **Tests before refactoring**: Never refactor untested code without adding tests first — you won't know if the refactor is correct\n\n## Cross-Skill References\n\n- `refactoring` — use for the actual small-scale, test-protected code improvements identified in this review\n- `architecture-design` — use when debt is architectural (wrong boundaries, wrong abstractions at system level)\n- `performance-optimization` — use when debt is causing measurable performance problems, not just code cleanliness\n","# Technical Debt Review\n\nProduce a strategic picture of where the codebase is accumulating debt and what to do about it. The goal is a prioritized roadmap, not an exhaustive list of every imperfection.\n\n## Step 1: Identify Hotspots\n\nDon't try to review everything. Focus on where pain is concentrated.\n\n**Code complexity signals:**\n- Files or functions with high cyclomatic complexity (many branches, deep nesting)\n- Functions over ~50 lines — usually doing too much (SRP violation)\n- Classes over ~300 lines — usually a God class or multiple responsibilities\n- High number of parameters (> 5 usually indicates missing abstraction)\n\n**Change frequency signals (most valuable):**\n- Files changed in almost every PR — high churn indicates poor separation of concerns or missing abstractions\n- Files that always require changes together — tight coupling that should be decoupled\n- Files with frequent bug fixes — instability indicates unclear ownership or poor test coverage\n- AI-assisted bulk commits — large multi-file commits landing at once and revised within days; churn-shortly-after-landing is the strongest slop signal\n\n**Structural signals:**\n- Circular dependencies between modules\n- Modules that import from many other modules — likely a coordination layer doing too much\n- Dead code (functions\u002Fclasses with no callers)\n\n**Test coverage signals:**\n- Untested code paths in critical or high-churn files\n- Tests that only test happy paths (no edge cases, no error cases)\n- Test files significantly longer than the code they test (over-specified tests that break on refactoring)\n\nIf the request came with team pain points (where engineers slow down, code people avoid touching, where bugs keep appearing), weight those hotspots first. This skill runs in a forked context and cannot ask mid-run — when that input is missing, proceed on the code signals above and list \"where does the team actually hurt?\" under Open questions in the report.\n\n## Step 2: Categorize by Debt Type and Severity\n\nFor each hotspot, classify the debt:\n\n**Debt types:**\n| Type | Description | Typical fix |\n|------|-------------|-------------|\n| **Complexity debt** | Functions\u002Fclasses doing too much | Extract, decompose, simplify |\n| **Duplication debt** | Same logic in multiple places | Extract shared abstraction |\n| **Test debt** | Missing or low-quality tests | Add tests before refactoring anything else |\n| **Documentation debt** | Undocumented non-obvious behavior (docs *missing*) | Add comments, docstrings, decision records |\n| **Documentation drift** | Docs describing behavior, endpoints, or flags that no longer exist | Fix or delete the stale doc |\n| **Architecture debt** | Wrong abstraction at system level | Restructure, introduce proper boundaries |\n| **Dependency debt** | Outdated, vulnerable, or abandoned libraries | Upgrade or replace |\n| **Type debt** | `any`\u002Fcasts silencing the checker, single-implementer interfaces \"for testing\", overly broad types | Restore real types; inline the interface |\n| **Config\u002Fscaffolding debt** | Unread config keys\u002Fflags, orphan `.env` entries, checked-in generated files, TODO scaffolds | Delete what nothing reads; regenerate instead of committing |\n| **Observability debt** | No logging, metrics, or traceability | Add instrumentation |\n\n**Severity:**\n- **Critical**: Causing active bugs or security risks. Address immediately.\n- **High**: Slowing down every sprint. Blocking new features. Schedule for next quarter.\n- **Medium**: Painful but workable. Schedule when capacity allows.\n- **Low**: Noticeable but not impeding. Do it opportunistically when touching related code.\n\nFor the AI-slop lens on these categories (per-pattern tells and when-it's-NOT-slop guidance), read the sibling skill's `code-slop-cleanup\u002Freferences\u002Fslop-patterns.md` if installed.\n\n## AI-Slop Audit Mode\n\nWhen the request is specifically an **AI-slop audit** (not a general debt roadmap for\nplanning) — \"audit this repo for AI slop\", \"full slop review\", \"what slop did the agents\nleave\" — keep the same integrity discipline but shift the output:\n\n- **Score the 14 slop categories, not the debt types.** Duplication · premature\n  abstraction · dead\u002Funreachable code · defensive theater · verbose\u002Finflated · comment\n  slop · naming\u002Forganization · type slop · error-handling slop · test slop · dependency\n  slop · structural\u002Farchitectural · config\u002Fscaffolding · documentation drift. A scorecard\n  row per category (count · worst severity · one-line note) is the map.\n- **Find the systemic patterns — \"fix once at the source.\"** The highest-value section is\n  not the finding list but the handful of **root causes** that parent it: \"the same wiring\n  ritual pasted 18× (P1)\", \"no shared test scaffold, so fixtures duplicate across 6 files\n  (P2)\", \"one impure `resolve()` leaks `SystemExit`, forcing lossy handling at 7 callers\n  (P3).\" Collapse dozens of findings to a few roots, then fix the root.\n- **Use the static-tooling method and the report format** in\n  [references\u002Fslop-audit-method.md](references\u002Fslop-audit-method.md) (per-language tool\n  menu — jscpd\u002Fknip\u002Fvulture\u002Fdeptry\u002Fruff\u002Fmypy — plus git-churn and grep\u002F`diff` verification)\n  and write the report with [templates\u002Fslop-audit.md](templates\u002Fslop-audit.md).\n\nEverything below (Audit Integrity, evidence, \"Explicitly not flagged\", method log) applies\nunchanged — a slop audit that invents findings is worse than one that misses them.\n\n## Audit Integrity — do not generate slop while hunting it\n\nA wrong finding costs the audit more credibility than a missed one, and this skill runs in a forked context: the written report is the only artifact that survives, so an unevidenced finding is unfalsifiable downstream. Rules for every finding:\n\n- **Evidence or it didn't happen.** Cite `path:line-range` and quote the offending code minimally. No location, no finding.\n- **Argue it, don't label it.** State *why the specific instance is unjustified here* — what it costs and why the pattern lacks a reason that survives scrutiny. \"I'd do it differently\" is preference, not debt.\n- **Attempt to disprove before flagging.** Trace callers before declaring code dead (dynamic references, string-based lookups, DI, reflection, external consumers); check history before calling a config key unread. If a legitimate reason emerges, downgrade or drop.\n- **Confidence, not assertion.** Unverifiable usage claims get Confidence: Low with a note on what would confirm it — never asserted as fact.\n- **Record what you didn't flag.** An \"Explicitly not flagged\" section (items considered, reason they survived scrutiny) proves the audit was discerning and stops the team re-litigating.\n- **Log the method.** Tools\u002Fpasses run with their commands, and anything not covered — unreadable files, missing test env — as named blind spots. If a tool wasn't available, say so; don't fabricate its results.\n\n## Step 3: Estimate Effort and Risk\n\nFor each hotspot, estimate:\n\n**Effort**: hours\u002Fdays\u002Fweeks of engineering work to address\n**Risk**: probability that addressing this introduces new bugs (higher for untested, complex code)\n**Prerequisite**: does this require tests before it can be safely changed? (almost always yes for High\u002FCritical)\n\nHigh-risk + no tests = address the tests first, before the underlying debt.\n\n## Step 4: Prioritize by Value-to-Cost Ratio\n\nScore each item: `(Severity × Impact on team velocity) \u002F (Effort × Risk)`\n\nPrioritize in this order:\n1. **Quick wins**: Low effort, meaningful impact (inconsistent naming conventions, easy extractions)\n2. **High pain, medium effort**: The things that slow every sprint down — worth dedicated sprint time\n3. **Strategic investments**: High effort but unlocks future capability — needs executive buy-in and planned downtime from feature work\n4. **Low impact**: Log them, don't schedule them — address opportunistically\n\nAvoid the \"big rewrite\" trap. Long rewrites stall feature work, introduce new bugs, and often fail to ship. Prefer incremental improvement over big-bang rewrites.\n\n## Step 5: Produce the Remediation Roadmap\n\nOutput a prioritized action plan:\n\n**Immediate (this sprint):**\n- [Quick win 1]: estimated [X hours], owner [Name]\n- [Critical fix 1]: estimated [Y days], owner [Name]\n\n**Next quarter:**\n- [High-priority debt 1]: estimated [X weeks], requires [tests\u002Fmigration\u002Fteam availability]\n- [High-priority debt 2]: ...\n\n**Backlog (do when touching related code):**\n- [Medium items to address opportunistically]\n\n**Accepted debt (won't address):**\n- [Items acknowledged but explicitly not worth fixing] — revisit if severity changes\n\nUse [templates\u002Fdebt-audit.md](templates\u002Fdebt-audit.md) for the full audit format.\n\n**Write the full audit to a file** (default a gitignored location, e.g.\n`.local\u002Fdebt-review-\u003Cdate>.md`) and state its path in your final summary — this\nskill runs in a forked context: only the summary returns, everything unwritten is\nlost. Judgment calls that need user input (e.g. which subsystem matters most,\nunknown team pain points) go in an **Open questions** section of the report, never\nguessed silently.\n\n## Principles Applied\n\n- **KISS**: Simplify complexity first — complex code is the root cause of most other debt\n- **DRY**: Eliminate duplication — find the patterns, create the abstraction\n- **SRP**: Split God classes and functions doing multiple jobs into focused units\n- **Tests before refactoring**: Never refactor untested code without adding tests first — you won't know if the refactor is correct\n\n## Cross-Skill References\n\n- `refactoring` — use for the actual small-scale, test-protected code improvements identified in this review\n- `architecture-design` — use when debt is architectural (wrong boundaries, wrong abstractions at system level)\n- `performance-optimization` — use when debt is causing measurable performance problems, not just code cleanliness\n",{"name":5,"agent":57,"context":58,"description":7,"when_to_use":59},"general-purpose","fork","Triggers: technical debt, tech debt, debt review, codebase health, hotspots, debt assessment, remediation plan, what should we fix first, debt roadmap, code rot, legacy code audit.","main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fem\u002Fskills\u002Ftechnical-debt-review","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-11 09:15:32",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill technical-debt-review",{"tool":73,"command":74},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill technical-debt-review",{"tool":76,"command":77},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill technical-debt-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002FSKILL.md",true,[81,87,91,95,99],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Fevals.json","REFERENCE","参考文档",5049,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002Fevals\u002Fevals.json",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fdebt-taxonomy.md",5988,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002Freferences\u002Fdebt-taxonomy.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fslop-audit-method.md",4526,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002Freferences\u002Fslop-audit-method.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"templates\u002Fdebt-audit.md",3329,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002Ftemplates\u002Fdebt-audit.md",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"templates\u002Fslop-audit.md",4473,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Ftechnical-debt-review\u002Ftemplates\u002Fslop-audit.md",[104,143,170,193,226,251],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":123,"publishedAt":52},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[110,113,116,117,120],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":118,"categoryName":119,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":121,"categoryName":122,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000040","财务",[124,125,126,127,128,129,130,131,132,133,134,135,41,136,137,138,139,140,141,142],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":52},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[149],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,41,169],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":177,"publishedAt":52},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[176],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[178,179,180,181,44,182,124,183,154,184,185,186,157,187,161,188,189,190,191,192],"verification","verification before completion","brief","ready","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":206,"publishedAt":52},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[199,202,203],{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":204,"categoryName":205,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[207,208,209,210,211,212,213,214,215,216,217,218,159,219,220,221,222,223,224,225],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":227,"name":228,"nameZh":6,"description":229,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":230,"categories":231,"keywords":234,"publishedAt":52},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[232,233],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[235,236,237,238,239,240,207,241,242,243,50,35,244,48,245,246,247,248,249,250],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","threat model","security-audit","secure","config","go","security","trust",{"skillNo":252,"name":253,"nameZh":6,"description":254,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":255,"categories":256,"keywords":262,"publishedAt":52},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[257,258,259,260,261],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":204,"categoryName":205,"taxonomyType":26,"taxonomyTypeDesc":27},[207,263,264,265,266,267,126,268,269,183,50,270,45,128,271,272,166,273,274,41],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","add","infrastructure","test plan","for"]