[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75017NMH9Q3EPWRF1VQ5JS2":3,"skill-same:01M75017NMH9Q3EPWRF1VQ5JS2":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},"01M75017NMH9Q3EPWRF1VQ5JS2","changelog-writer",null,"Translates raw engineering release notes - commits, tickets, PR titles - into a user-facing changelog grouped as New, Improved, and Fixed, with a highlights section on top, benefit-first phrasing in the user's vocabulary, bugs described by their symptoms, and internal-only churn cut and flagged. Use when someone says \"write the changelog for this release\", \"turn these commit messages into release notes users can read\", \"announce what shipped this week\", or their changelog currently reads as internal jargon. Do NOT use for auto-generating a technical changelog from git history for developers - use changelog-generator 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\u002Fchangelog-writer\u002FSKILL.md",[],[],"2026-11-11 17:59:50",false,"---\nname: changelog-writer\ndescription: Translates raw engineering release notes - commits, tickets, PR titles - into a user-facing changelog grouped as New, Improved, and Fixed, with a highlights section on top, benefit-first phrasing in the user's vocabulary, bugs described by their symptoms, and internal-only churn cut and flagged. Use when someone says \"write the changelog for this release\", \"turn these commit messages into release notes users can read\", \"announce what shipped this week\", or their changelog currently reads as internal jargon. Do NOT use for auto-generating a technical changelog from git history for developers - use changelog-generator instead.\nmetadata:\n  title: \"User-Facing Changelog\"\n---\n\n# User-Facing Changelog\n\nYou translate engineering release notes into a changelog real users want to read. Developers describe what changed; users care what it means for them.\n\n## Core principle\n\nLead with the benefit, not the implementation. \"We migrated to a new caching layer\" means nothing to a user. \"Pages now load about twice as fast\" does.\n\n## Process\n\n1. Take the raw notes (commits, tickets, PR titles).\n2. Group them by user impact, drop the invisible internal churn.\n3. Rewrite each meaningful change in user language, benefit first.\n\n## Categories (group entries)\n\n- **New** - features users can now do.\n- **Improved** - things that work better\u002Ffaster.\n- **Fixed** - bugs squashed (describe the symptom the user saw, not the code).\n- (Optionally **Changed\u002FDeprecated** when behavior shifts or something's going away.)\n\n## Writing each entry\n\n- **Benefit first, then feature.** \"Find anything instantly - search now covers comments and attachments.\"\n- **User's vocabulary**, not internal names. Translate \"the FooService timeout\" into \"Reports no longer fail to load on large accounts.\"\n- **Describe the bug by its symptom.** Not \"Fixed null pointer in export handler\" but \"Fixed an issue where exporting an empty list caused an error.\"\n- **Be concrete and specific.** Numbers help: \"30% faster,\" \"supports files up to 1 GB.\"\n- **Keep entries short** - one or two sentences. Link to docs for depth.\n- **Active voice, present tense.** \"You can now...\" \u002F \"We fixed...\"\n- **Show personality** if the brand allows, but never at the expense of clarity.\n\n## What to include vs. cut\n\n- Include: anything a user would notice or benefit from.\n- Cut: internal refactors, dependency bumps, test changes, infra work - unless they produced a user-visible result (then describe the result, not the work).\n- Highlight the headline change at the top; don't bury the best update in a list.\n\n## Structure of a release entry\n\n1. **Version \u002F date** (and a one-line theme if there's a marquee feature).\n2. **Highlights** - the 1-3 things that matter most, with a sentence each.\n3. **Categorized list** - New \u002F Improved \u002F Fixed.\n4. **Links** - to docs, blog post, or migration guide for anything that needs it.\n\n## Tone\n\nClear, warm, confident. You're sharing good news (or honestly owning a fix). Avoid corporate vagueness (\"various improvements and bug fixes\") - that entry tells users nothing and erodes trust. If a release is genuinely minor, say so briefly and honestly.\n\n## Anti-patterns\n\n- Pasting commit messages verbatim.\n- \"Various bug fixes and performance improvements\" as the whole changelog.\n- Internal jargon and service names.\n- Feature-first phrasing that hides the benefit.\n\n## Output\n\nDeliver the changelog grouped by category with a highlights section on top, in user language, benefit-first. Note any raw entries you dropped as internal-only so the user can confirm nothing user-facing was missed.\n","# User-Facing Changelog\n\nYou translate engineering release notes into a changelog real users want to read. Developers describe what changed; users care what it means for them.\n\n## Core principle\n\nLead with the benefit, not the implementation. \"We migrated to a new caching layer\" means nothing to a user. \"Pages now load about twice as fast\" does.\n\n## Process\n\n1. Take the raw notes (commits, tickets, PR titles).\n2. Group them by user impact, drop the invisible internal churn.\n3. Rewrite each meaningful change in user language, benefit first.\n\n## Categories (group entries)\n\n- **New** - features users can now do.\n- **Improved** - things that work better\u002Ffaster.\n- **Fixed** - bugs squashed (describe the symptom the user saw, not the code).\n- (Optionally **Changed\u002FDeprecated** when behavior shifts or something's going away.)\n\n## Writing each entry\n\n- **Benefit first, then feature.** \"Find anything instantly - search now covers comments and attachments.\"\n- **User's vocabulary**, not internal names. Translate \"the FooService timeout\" into \"Reports no longer fail to load on large accounts.\"\n- **Describe the bug by its symptom.** Not \"Fixed null pointer in export handler\" but \"Fixed an issue where exporting an empty list caused an error.\"\n- **Be concrete and specific.** Numbers help: \"30% faster,\" \"supports files up to 1 GB.\"\n- **Keep entries short** - one or two sentences. Link to docs for depth.\n- **Active voice, present tense.** \"You can now...\" \u002F \"We fixed...\"\n- **Show personality** if the brand allows, but never at the expense of clarity.\n\n## What to include vs. cut\n\n- Include: anything a user would notice or benefit from.\n- Cut: internal refactors, dependency bumps, test changes, infra work - unless they produced a user-visible result (then describe the result, not the work).\n- Highlight the headline change at the top; don't bury the best update in a list.\n\n## Structure of a release entry\n\n1. **Version \u002F date** (and a one-line theme if there's a marquee feature).\n2. **Highlights** - the 1-3 things that matter most, with a sentence each.\n3. **Categorized list** - New \u002F Improved \u002F Fixed.\n4. **Links** - to docs, blog post, or migration guide for anything that needs it.\n\n## Tone\n\nClear, warm, confident. You're sharing good news (or honestly owning a fix). Avoid corporate vagueness (\"various improvements and bug fixes\") - that entry tells users nothing and erodes trust. If a release is genuinely minor, say so briefly and honestly.\n\n## Anti-patterns\n\n- Pasting commit messages verbatim.\n- \"Various bug fixes and performance improvements\" as the whole changelog.\n- Internal jargon and service names.\n- Feature-first phrasing that hides the benefit.\n\n## Output\n\nDeliver the changelog grouped by category with a highlights section on top, in user language, benefit-first. Note any raw entries you dropped as internal-only so the user can confirm nothing user-facing was missed.\n",{"name":5,"metadata":24,"description":7},{"title":25},"User-Facing Changelog","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fchangelog-writer",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 changelog-writer",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill changelog-writer",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill changelog-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fchangelog-writer\u002FSKILL.md",true,[],[50,60,67,74,81,88],{"skillNo":51,"name":52,"nameZh":53,"description":54,"descriptionZh":55,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":59},"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).","当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性\u002F柔韧性训练（请使用灵活性训练计划）。","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":59},"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":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":59},"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":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":80,"publishedAt":59},"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":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":59},"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":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":59},"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",[],[]]