[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751ZP8EAB2DVM8BB6JN4ADV":3,"skill-same:01M751ZP8EAB2DVM8BB6JN4ADV":49},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":31,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M751ZP8EAB2DVM8BB6JN4ADV","tech-debt-prioritizer",null,"Inventories tech debt and ranks it economically - scoring each item 1-3 on cost of delay (the interest rate) and leverage (the principal unblocked), multiplying into a priority index, and packaging the winners into a leadership proposal framed on business impact. Use when someone asks \"which tech debt should we tackle first\", \"help me build a case for refactoring to leadership\", \"our backlog of debt is huge, where do we start\", or is preparing quarterly planning. Do NOT use for finding and removing unused code - use dead-code-eliminator instead - for auditing third-party dependency risk - use dependency-risk-audit - or for planning the sprint the work lands in - use sprint-planning instead.","SkillMedev\u002Fskills","SkillMedev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F298078254?v=4","01M74ZSGTQ918CB0VXW4EG3RMX","SkillMe","01M74ZSGVBT497NA95CBT8JTY4",25,"MIT","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftech-debt-prioritizer\u002FSKILL.md",[],[],"2026-11-11 18:22:23",false,"---\nname: tech-debt-prioritizer\ndescription: Inventories tech debt and ranks it economically - scoring each item 1-3 on cost of delay (the interest rate) and leverage (the principal unblocked), multiplying into a priority index, and packaging the winners into a leadership proposal framed on business impact. Use when someone asks \"which tech debt should we tackle first\", \"help me build a case for refactoring to leadership\", \"our backlog of debt is huge, where do we start\", or is preparing quarterly planning. Do NOT use for finding and removing unused code - use dead-code-eliminator instead - for auditing third-party dependency risk - use dependency-risk-audit - or for planning the sprint the work lands in - use sprint-planning instead.\nmetadata:\n  title: \"Tech Debt Prioritizer\"\n---\n\n# Tech Debt Prioritizer\n\nTech debt decisions fail when made on vibes (\"this code is ugly\") or recency bias (whatever hurt last week). This skill applies a lightweight economic frame - debt as a loan, where cost of delay is the interest rate you pay every sprint and leverage is the principal of future work it unblocks - so the right items get funded and the rest stay parked without guilt.\n\n## Operating procedure\n\nThe steps run in order because scoring an unfiltered inventory is what keeps the ranking honest: filtering first means the loudest complaints survive and the quiet, expensive items never get scored.\n\n### Step 1: gather inputs and build the inventory\n\nTimebox to 60 minutes and cap the list at 20 items - past 20, scoring fatigue produces garbage scores. Pull candidates from three sources, one pass each:\n\n- Friction signals: team retros and chat complaints.\n- Reliability signals: incident post-mortems from the last two quarters.\n- Velocity signals: areas with high cycle time or frequent reverts.\n\nEach item gets a one-line description, the system it lives in, and the person who raised it. Do not filter at this stage; resist the urge. If an estimate is a gut call (\"this costs us maybe a day a sprint\"), record it as a guess.\n\n### Step 2: score each item on two axes, 1-3 each\n\n- Cost of delay (the interest rate): what does leaving this unaddressed cost per sprint - engineer time lost, incident risk carried, opportunity cost? 1 = an annoyance under a few hours a sprint; 2 = meaningful drag, roughly half a day to two days of engineer time per sprint or a plausible incident path; 3 = actively bleeding - multiple engineer-days per sprint, a repeat-incident source, or blocking a committed date.\n- Leverage (the principal): how many future features or workflows does fixing this unblock or accelerate? 1 = local cleanup, nothing downstream; 2 = speeds up one team's ongoing work; 3 = unblocks multiple roadmap items or teams.\n\nMultiply for the priority index (1-9). Items scoring 9 are immediate candidates; 6 goes on the quarter plan; 1-2 goes to the parking lot. Score in one sitting with the whole group so the scale stays calibrated across items.\n\n### Step 3: classify by quadrant\n\nPlot on a 2x2 to catch what the index alone hides:\n\n- High cost-of-delay \u002F high leverage: do now.\n- High cost-of-delay \u002F low leverage: schedule this quarter - the interest is real even if nothing downstream is waiting.\n- Low cost-of-delay \u002F high leverage: opportunistic - fold into adjacent feature work rather than scheduling standalone.\n- Low \u002F low: document and defer to the parking lot.\n\nThe parking lot needs a quarterly review gate that drops items older than 6 months. An unbounded parking lot becomes a second backlog nobody trusts.\n\n### Step 4: size and assign\n\nEvery \"do now\" and \"this quarter\" item gets a t-shirt size (S = days, M = 1-2 weeks, L = 3-6 weeks, XL = needs decomposition before it can be scheduled - an XL debt item is a project, not a task). Propose an owner per item, and do not assign all debt to the same two senior engineers: well-scoped debt work is a career-growth opportunity for mid-level engineers, and hoarding it on seniors makes it invisible and unpromotable.\n\n### Step 5: write the proposal\n\nLead with business impact, never code quality. The sentence pattern per item: \"This currently costs us X per sprint \u002F caused incident Y \u002F blocks initiative Z. Fixing it takes N engineer-weeks. The expected return is [time recovered, risk retired, or roadmap unblocked].\" Skip the architecture lecture - leadership funds interest-rate reduction, not elegance. If stakeholders resist all debt investment, propose a debt tax: reserve 15-20% of each sprint for debt, and never negotiate below 10% - below that line the tax exists on paper only.\n\n## Worked artifact: scored table\n\n```\nITEM                                  SYSTEM      CoD  LEV  IDX  QUADRANT       SIZE  OWNER\nFlaky CI suite (retries mask fails)   build        3    3    9   do now          M    Priya\nOrders svc has no staging env         orders       3    2    6   this quarter    L    Marcus\nDuplicated pricing logic (3 places)   billing      2    3    6   this quarter    M    Jen\nLegacy cron with no alerting          reports      2    1    2   parking lot     S    -\nInconsistent lint config              all repos    1    1    1   parking lot     S    -\n```\n\nRead it: the CI suite scores 9 - it taxes every engineer every day (CoD 3) and every future change ships through it (LEV 3) - so it jumps ahead of the staging-env gap even though the staging gap caused the more memorable incident. That inversion of recency bias is the entire point of scoring.\n\n## Deliverable\n\nProduce three artifacts: the scored inventory table (all items, both axes, index, quadrant), the quarter's funded list with t-shirt sizes and proposed owners, and a leadership proposal of no more than one page where every funded item is framed as cost\u002Freturn, plus a parking lot with its 6-month expiry noted.\n\n## Do NOT\n\n- Do not filter the inventory before scoring - pre-filtering re-introduces the vibes the scoring exists to remove.\n- Do not use a finer scale than 1-3. A 1-10 scale invites false precision arguments about whether something is a 6 or a 7; the 2x2 only needs low\u002Fmedium\u002Fhigh.\n- Do not pitch leadership on code quality, elegance, or \"best practices\" - pitch interest payments and unblocked roadmap.\n- Do not schedule low-CoD\u002Fhigh-leverage items standalone; fold them into adjacent feature work or they will lose every prioritization fight.\n- Do not let the parking lot skip its quarterly review; items older than 6 months get dropped or re-scored, not carried silently.\n- Do not put an XL item on the quarter plan un-decomposed.\n\n## Quality bar\n\n- Every inventory item traces to one of the three signal sources; guesses are labeled.\n- Every item has both axis scores, an index, and a quadrant - no unscored pet projects smuggled into \"do now\".\n- The funded list fits the team's realistic capacity after the debt-tax percentage is applied.\n- The proposal contains zero architecture jargon a non-engineer executive would need defined.\n- Owners are spread beyond the two most senior engineers.\n","# Tech Debt Prioritizer\n\nTech debt decisions fail when made on vibes (\"this code is ugly\") or recency bias (whatever hurt last week). This skill applies a lightweight economic frame - debt as a loan, where cost of delay is the interest rate you pay every sprint and leverage is the principal of future work it unblocks - so the right items get funded and the rest stay parked without guilt.\n\n## Operating procedure\n\nThe steps run in order because scoring an unfiltered inventory is what keeps the ranking honest: filtering first means the loudest complaints survive and the quiet, expensive items never get scored.\n\n### Step 1: gather inputs and build the inventory\n\nTimebox to 60 minutes and cap the list at 20 items - past 20, scoring fatigue produces garbage scores. Pull candidates from three sources, one pass each:\n\n- Friction signals: team retros and chat complaints.\n- Reliability signals: incident post-mortems from the last two quarters.\n- Velocity signals: areas with high cycle time or frequent reverts.\n\nEach item gets a one-line description, the system it lives in, and the person who raised it. Do not filter at this stage; resist the urge. If an estimate is a gut call (\"this costs us maybe a day a sprint\"), record it as a guess.\n\n### Step 2: score each item on two axes, 1-3 each\n\n- Cost of delay (the interest rate): what does leaving this unaddressed cost per sprint - engineer time lost, incident risk carried, opportunity cost? 1 = an annoyance under a few hours a sprint; 2 = meaningful drag, roughly half a day to two days of engineer time per sprint or a plausible incident path; 3 = actively bleeding - multiple engineer-days per sprint, a repeat-incident source, or blocking a committed date.\n- Leverage (the principal): how many future features or workflows does fixing this unblock or accelerate? 1 = local cleanup, nothing downstream; 2 = speeds up one team's ongoing work; 3 = unblocks multiple roadmap items or teams.\n\nMultiply for the priority index (1-9). Items scoring 9 are immediate candidates; 6 goes on the quarter plan; 1-2 goes to the parking lot. Score in one sitting with the whole group so the scale stays calibrated across items.\n\n### Step 3: classify by quadrant\n\nPlot on a 2x2 to catch what the index alone hides:\n\n- High cost-of-delay \u002F high leverage: do now.\n- High cost-of-delay \u002F low leverage: schedule this quarter - the interest is real even if nothing downstream is waiting.\n- Low cost-of-delay \u002F high leverage: opportunistic - fold into adjacent feature work rather than scheduling standalone.\n- Low \u002F low: document and defer to the parking lot.\n\nThe parking lot needs a quarterly review gate that drops items older than 6 months. An unbounded parking lot becomes a second backlog nobody trusts.\n\n### Step 4: size and assign\n\nEvery \"do now\" and \"this quarter\" item gets a t-shirt size (S = days, M = 1-2 weeks, L = 3-6 weeks, XL = needs decomposition before it can be scheduled - an XL debt item is a project, not a task). Propose an owner per item, and do not assign all debt to the same two senior engineers: well-scoped debt work is a career-growth opportunity for mid-level engineers, and hoarding it on seniors makes it invisible and unpromotable.\n\n### Step 5: write the proposal\n\nLead with business impact, never code quality. The sentence pattern per item: \"This currently costs us X per sprint \u002F caused incident Y \u002F blocks initiative Z. Fixing it takes N engineer-weeks. The expected return is [time recovered, risk retired, or roadmap unblocked].\" Skip the architecture lecture - leadership funds interest-rate reduction, not elegance. If stakeholders resist all debt investment, propose a debt tax: reserve 15-20% of each sprint for debt, and never negotiate below 10% - below that line the tax exists on paper only.\n\n## Worked artifact: scored table\n\n```\nITEM                                  SYSTEM      CoD  LEV  IDX  QUADRANT       SIZE  OWNER\nFlaky CI suite (retries mask fails)   build        3    3    9   do now          M    Priya\nOrders svc has no staging env         orders       3    2    6   this quarter    L    Marcus\nDuplicated pricing logic (3 places)   billing      2    3    6   this quarter    M    Jen\nLegacy cron with no alerting          reports      2    1    2   parking lot     S    -\nInconsistent lint config              all repos    1    1    1   parking lot     S    -\n```\n\nRead it: the CI suite scores 9 - it taxes every engineer every day (CoD 3) and every future change ships through it (LEV 3) - so it jumps ahead of the staging-env gap even though the staging gap caused the more memorable incident. That inversion of recency bias is the entire point of scoring.\n\n## Deliverable\n\nProduce three artifacts: the scored inventory table (all items, both axes, index, quadrant), the quarter's funded list with t-shirt sizes and proposed owners, and a leadership proposal of no more than one page where every funded item is framed as cost\u002Freturn, plus a parking lot with its 6-month expiry noted.\n\n## Do NOT\n\n- Do not filter the inventory before scoring - pre-filtering re-introduces the vibes the scoring exists to remove.\n- Do not use a finer scale than 1-3. A 1-10 scale invites false precision arguments about whether something is a 6 or a 7; the 2x2 only needs low\u002Fmedium\u002Fhigh.\n- Do not pitch leadership on code quality, elegance, or \"best practices\" - pitch interest payments and unblocked roadmap.\n- Do not schedule low-CoD\u002Fhigh-leverage items standalone; fold them into adjacent feature work or they will lose every prioritization fight.\n- Do not let the parking lot skip its quarterly review; items older than 6 months get dropped or re-scored, not carried silently.\n- Do not put an XL item on the quarter plan un-decomposed.\n\n## Quality bar\n\n- Every inventory item traces to one of the three signal sources; guesses are labeled.\n- Every item has both axis scores, an index, and a quadrant - no unscored pet projects smuggled into \"do now\".\n- The funded list fits the team's realistic capacity after the debt-tax percentage is applied.\n- The proposal contains zero architecture jargon a non-engineer executive would need defined.\n- Owners are spread beyond the two most senior engineers.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Tech Debt Prioritizer","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Ftech-debt-prioritizer",3,"https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills","https:\u002F\u002Fskillme.dev","https:\u002F\u002Fgithub.com\u002FSkillMedev","MCP-native catalog of Claude Agent Skills. Browse, recommend, install, and auto-apply skills in chat. Open source, every skill free and clonable on GitHub.","2026-10-14 03:19:31",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add SkillMedev\u002Fskills --skill tech-debt-prioritizer",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill tech-debt-prioritizer",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill tech-debt-prioritizer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftech-debt-prioritizer\u002FSKILL.md",true,[],[50,58,65,72,79,86],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":57},"01M75271B256DF3FX2VG5VRYEE","zone-2-cardio-plan","Use when someone asks to build a steady-state cardio plan, train an aerobic base or Zone 2, structure easy or endurance weekly cardio, train by heart-rate zones, or improve resting heart rate, VO2, or endurance. Builds a heart-rate-zone aerobic training block with session structure, modality choice, and progression. General fitness guidance, not medical advice. Do NOT use to design a strength or lifting program (use Strength Training Plan), high-intensity interval conditioning, HIIT, or circuits (use Conditioning & HIIT Program), or a mobility\u002Fflexibility routine (use Mobility Routine).","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":57},"01M7526VP1QBBKYBE17S1WR86Y","youtube-script-writer","Writes retention-engineered long-form YouTube scripts on a hook\u002Fbody\u002Fpayoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says \"script my next video\", \"my retention graph dies at the start\", \"tighten this draft\", or \"outline a video on X\". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-writer\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":57},"01M7526P2T0WKMHDXS4Q58237T","win-back-campaign","Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says \"our users went quiet\", \"design a win-back campaign\", \"how do I re-engage lapsed customers\", \"should we email people who haven't logged in for months\", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwin-back-campaign\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":57},"01M7526HF2RCDJ50P93WRZRHVV","wikipedia-style","Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks \"write this like a Wikipedia article\", \"draft a Wikipedia page for this company or person\", \"make this neutral and encyclopedic\", or \"why does my article draft keep getting rejected\". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwikipedia-style\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":57},"01M7526D43CTGRKGKNQ2GB0KVX","whitepapers","Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks \"write a whitepaper on this topic\", \"turn our research into a lead-gen asset\", \"make this credible enough for executives\", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhitepapers\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":57},"01M75268423Y3K50SY5WC2NX2G","white-space-analysis","Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks \"where are the gaps in this market\", \"what's underserved here\", \"where should we play next\", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhite-space-analysis\u002FSKILL.md",[],[]]