[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751DKQSWAKVXD2K09M1FRZH":3,"skill-same:01M751DKQSWAKVXD2K09M1FRZH":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},"01M751DKQSWAKVXD2K09M1FRZH","product-analytics",null,"Stands up product analytics from decision questions backward - a north-star metric with an input-metric tree, an object-action event taxonomy with a governed tracking plan, and the priority analyses to build first: activation funnels, cohort retention curves, and feature adoption correlated with retention. Use when someone asks \"what events should we track\", \"set up our analytics taxonomy\", \"where do users drop off before first value\", or \"what's our activation moment\". Do NOT use for growth-accounting decompositions of MAU changes - use growth-accounting instead - or for deep funnel diagnosis on existing data - use funnel-analysis 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\u002Fproduct-analytics\u002FSKILL.md",[],[],"2026-11-11 18:11:12",false,"---\nname: product-analytics\ndescription: \"Stands up product analytics from decision questions backward - a north-star metric with an input-metric tree, an object-action event taxonomy with a governed tracking plan, and the priority analyses to build first: activation funnels, cohort retention curves, and feature adoption correlated with retention. Use when someone asks \\\"what events should we track\\\", \\\"set up our analytics taxonomy\\\", \\\"where do users drop off before first value\\\", or \\\"what's our activation moment\\\". Do NOT use for growth-accounting decompositions of MAU changes - use growth-accounting instead - or for deep funnel diagnosis on existing data - use funnel-analysis instead.\"\nmetadata:\n  title: \"Product Analytics\"\n---\n\n# Product Analytics\n\nYou cannot improve what you do not measure, but most teams measure the wrong\nthings badly. A messy event taxonomy is technical debt that misleads every\ndecision built on it. This skill sets up analytics that actually inform product\nwork.\n\n## Start With Questions, Not Events\n\nBefore instrumenting anything, write the decisions analytics must inform:\n\n- Where do users drop off before first value?\n- Which features correlate with retention?\n- What does an activated user do that a churned one did not?\n\nInstrument backward from these questions. Tracking everything \"just in case\"\nproduces noise nobody queries.\n\n## Event Taxonomy\n\nA disciplined naming convention is the foundation. Get it wrong and you spend a\nyear cleaning data.\n\n- Use a consistent structure: object-action (e.g. `project_created`,\n  `invite_sent`). Pick one convention and enforce it.\n- Define properties deliberately: each event carries the context you will\n  segment by (plan, source, role).\n- Maintain a tracking plan - a single source of truth listing every event, its\n  properties, and its owner. This is the contract between product, eng, and\n  data.\n- Size it: an early-stage tracking plan should be roughly 20-50 events, not\n  hundreds. If the plan exceeds ~100 events before product-market fit, it is\n  tracking implementation details, not decisions.\n- Govern changes: new events go through review so the taxonomy does not rot.\n\n## The North Star and Inputs\n\n- Pick one north-star metric that captures delivered value (e.g. weekly active\n  teams, queries run, documents shipped) - not a vanity count.\n- Decompose it into input metrics you can actually move (acquisition,\n  activation, engagement, retention).\n\n## Core Analyses\n\n### Funnels\nMap the path to first value and measure conversion at each step. The biggest\ndrop-off is your highest-leverage fix. Watch time-to-convert, not just rate:\nfor a self-serve product, most activation that will ever happen happens in the\nfirst session or first day - a median time-to-first-value beyond a day is\nitself the finding.\n\n### Cohort Retention\nGroup users by signup period and track retention over time. A healthy product\nshows a retention curve that flattens (a \"smile\" for the best products); a\ncurve decaying to zero means no product-market fit yet.\n\nHow to read the curve:\n\n- Judge where it flattens, not the month-1 number - the asymptote is the\n  product's real retained base.\n- Consumer apps: roughly 40% day-1 \u002F 20% day-7 \u002F 10% day-30 is a good curve;\n  well under that (say ~25\u002F10\u002F5) means the leak comes before the habit forms.\n  A consumer curve flattening above ~20% is a strong signal.\n- B2B SaaS: retention is measured in weeks\u002Fmonths, not days; expect the curve\n  to flatten within the first 4-8 weeks, and monthly logo retention below ~95%\n  (churn above ~5%\u002Fmonth) is a red flag for anything sold to businesses.\n- Compare newer cohorts against older ones - cohorts flattening higher over\n  time is the clearest evidence the product is improving.\n\n### Activation\nDefine the activation event - the action that predicts long-term retention\n(the \"aha moment\"). Find it by comparing what retained users did early versus\nchurned users: take users still active at week 4+, contrast their first 1-7\ndays of behavior against churned users' first 1-7 days, and look for the\nearly action with the biggest retention gap. Then optimize the funnel to it.\n\n### Feature Adoption\nTrack breadth (how many use a feature) and depth (how often). Correlate\nadoption with retention to prioritize the roadmap.\n\n## Avoid Vanity Metrics\n\n- Total signups, total pageviews, cumulative anything - they only go up and\n  inform nothing.\n- Prefer rates and cohorts over totals; prefer leading indicators over lagging\n  ones.\n\n## Tooling and Hygiene\n\n- Choose one analytics tool as the source of truth; pipe to a warehouse for\n  deep analysis.\n- Validate instrumentation regularly - silent tracking bugs corrupt every\n  downstream decision.\n- Document metric definitions so \"active user\" means the same thing to everyone.\n\n## Quality bar\n\n- Every event in the tracking plan traces back to a named decision question;\n  none exist \"just in case\".\n- The taxonomy follows one object-action convention with zero exceptions, and\n  the plan lists properties and an owner per event.\n- The north star measures delivered value (a rate or active count, never\n  cumulative) and decomposes into movable input metrics.\n- The retention read states where the curve flattens and against which\n  benchmark, not just a month-1 percentage.\n- The activation event is backed by a retained-vs-churned comparison, not\n  picked by intuition.\n\n## Deliverable\n\nProduce an analytics plan: the decision questions, a north-star metric with\ninput-metric tree, an event tracking plan with naming convention, and the\npriority analyses (activation funnel, cohort retention) to build first.\n","# Product Analytics\n\nYou cannot improve what you do not measure, but most teams measure the wrong\nthings badly. A messy event taxonomy is technical debt that misleads every\ndecision built on it. This skill sets up analytics that actually inform product\nwork.\n\n## Start With Questions, Not Events\n\nBefore instrumenting anything, write the decisions analytics must inform:\n\n- Where do users drop off before first value?\n- Which features correlate with retention?\n- What does an activated user do that a churned one did not?\n\nInstrument backward from these questions. Tracking everything \"just in case\"\nproduces noise nobody queries.\n\n## Event Taxonomy\n\nA disciplined naming convention is the foundation. Get it wrong and you spend a\nyear cleaning data.\n\n- Use a consistent structure: object-action (e.g. `project_created`,\n  `invite_sent`). Pick one convention and enforce it.\n- Define properties deliberately: each event carries the context you will\n  segment by (plan, source, role).\n- Maintain a tracking plan - a single source of truth listing every event, its\n  properties, and its owner. This is the contract between product, eng, and\n  data.\n- Size it: an early-stage tracking plan should be roughly 20-50 events, not\n  hundreds. If the plan exceeds ~100 events before product-market fit, it is\n  tracking implementation details, not decisions.\n- Govern changes: new events go through review so the taxonomy does not rot.\n\n## The North Star and Inputs\n\n- Pick one north-star metric that captures delivered value (e.g. weekly active\n  teams, queries run, documents shipped) - not a vanity count.\n- Decompose it into input metrics you can actually move (acquisition,\n  activation, engagement, retention).\n\n## Core Analyses\n\n### Funnels\nMap the path to first value and measure conversion at each step. The biggest\ndrop-off is your highest-leverage fix. Watch time-to-convert, not just rate:\nfor a self-serve product, most activation that will ever happen happens in the\nfirst session or first day - a median time-to-first-value beyond a day is\nitself the finding.\n\n### Cohort Retention\nGroup users by signup period and track retention over time. A healthy product\nshows a retention curve that flattens (a \"smile\" for the best products); a\ncurve decaying to zero means no product-market fit yet.\n\nHow to read the curve:\n\n- Judge where it flattens, not the month-1 number - the asymptote is the\n  product's real retained base.\n- Consumer apps: roughly 40% day-1 \u002F 20% day-7 \u002F 10% day-30 is a good curve;\n  well under that (say ~25\u002F10\u002F5) means the leak comes before the habit forms.\n  A consumer curve flattening above ~20% is a strong signal.\n- B2B SaaS: retention is measured in weeks\u002Fmonths, not days; expect the curve\n  to flatten within the first 4-8 weeks, and monthly logo retention below ~95%\n  (churn above ~5%\u002Fmonth) is a red flag for anything sold to businesses.\n- Compare newer cohorts against older ones - cohorts flattening higher over\n  time is the clearest evidence the product is improving.\n\n### Activation\nDefine the activation event - the action that predicts long-term retention\n(the \"aha moment\"). Find it by comparing what retained users did early versus\nchurned users: take users still active at week 4+, contrast their first 1-7\ndays of behavior against churned users' first 1-7 days, and look for the\nearly action with the biggest retention gap. Then optimize the funnel to it.\n\n### Feature Adoption\nTrack breadth (how many use a feature) and depth (how often). Correlate\nadoption with retention to prioritize the roadmap.\n\n## Avoid Vanity Metrics\n\n- Total signups, total pageviews, cumulative anything - they only go up and\n  inform nothing.\n- Prefer rates and cohorts over totals; prefer leading indicators over lagging\n  ones.\n\n## Tooling and Hygiene\n\n- Choose one analytics tool as the source of truth; pipe to a warehouse for\n  deep analysis.\n- Validate instrumentation regularly - silent tracking bugs corrupt every\n  downstream decision.\n- Document metric definitions so \"active user\" means the same thing to everyone.\n\n## Quality bar\n\n- Every event in the tracking plan traces back to a named decision question;\n  none exist \"just in case\".\n- The taxonomy follows one object-action convention with zero exceptions, and\n  the plan lists properties and an owner per event.\n- The north star measures delivered value (a rate or active count, never\n  cumulative) and decomposes into movable input metrics.\n- The retention read states where the curve flattens and against which\n  benchmark, not just a month-1 percentage.\n- The activation event is backed by a retained-vs-churned comparison, not\n  picked by intuition.\n\n## Deliverable\n\nProduce an analytics plan: the decision questions, a north-star metric with\ninput-metric tree, an event tracking plan with naming convention, and the\npriority analyses (activation funnel, cohort retention) to build first.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Product Analytics","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fproduct-analytics",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 product-analytics",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill product-analytics",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill product-analytics","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproduct-analytics\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",[],[]]