[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751RKD0DB4YNQBQVQ5R7QSB":3,"skill-same:01M751RKD0DB4YNQBQVQ5R7QSB":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},"01M751RKD0DB4YNQBQVQ5R7QSB","side-project-launch",null,"Takes a side project from idea to shipped launch with behavior-based validation, a ruthlessly cut MVP, a hard timebox, and explicit kill criteria so nights-and-weekends effort never runs open-loop for months. Use when someone asks \"how do I launch my side project\", \"should I keep building this\", \"how do I validate before building\", \"I've been building for months and haven't shipped\", or \"how do I know when to quit\". Do NOT use for the Product Hunt assets and mechanics specifically - use product-hunt-launch instead - for orchestrating a multi-channel company launch calendar - use launch-plan-sequencer instead - or for running a launch day in real time - use launch-day-runbook 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\u002Fside-project-launch\u002FSKILL.md",[],[],"2026-11-11 18:22:23",false,"---\nname: side-project-launch\ndescription: Takes a side project from idea to shipped launch with behavior-based validation, a ruthlessly cut MVP, a hard timebox, and explicit kill criteria so nights-and-weekends effort never runs open-loop for months. Use when someone asks \"how do I launch my side project\", \"should I keep building this\", \"how do I validate before building\", \"I've been building for months and haven't shipped\", or \"how do I know when to quit\". Do NOT use for the Product Hunt assets and mechanics specifically - use product-hunt-launch instead - for orchestrating a multi-channel company launch calendar - use launch-plan-sequencer instead - or for running a launch day in real time - use launch-day-runbook instead.\nmetadata:\n  title: \"Side Project Launch\"\n---\n\n# Side Project Launch\n\nThe biggest side-project risk is not failure - it is spending six months of evenings building something nobody wants, with no deadline forcing the question. A side project runs on scarce hours, so the discipline is different from a startup's: validate with behavior before building, cut the MVP to one flow, timebox hard, and write the kill criteria before launch, when judgment is still honest.\n\n## Operating procedure\n\nValidation precedes building, and the timebox precedes scoping - scope must be cut to fit the date, never the reverse.\n\n### Step 1: Gather inputs\n\n1. The idea, as a one-liner: \"I help [audience] do [job] better by [approach].\" Force the sentence; vagueness here compounds everywhere.\n2. Weekly hours honestly available (default assumption: 5-10 for a side project).\n3. Skills on hand and preferred tools - boring and familiar wins.\n4. The success motive: revenue, portfolio, learning, or fun. The kill criteria in Step 7 depend on it.\n5. Where the audience already gathers.\n\n### Step 2: Validate before building\n\nTalk to 5-10 potential users. Ask about their current behavior, never about your idea:\n\n- How do you handle this today?\n- What is frustrating about that?\n- Have you paid for or actively sought a solution?\n\nEvidence of real pain is people already spending money, time, or duct-tape effort on the problem. A landing page with a waitlist or a small pre-sale is a stronger signal than any number of compliments - compliments are free, behavior is not. Passing bar: several interviewees describe active workarounds or spend, or a simple landing page converts visitors to signups at a few percent. If nobody exhibits the pain, stop here - that is the cheapest possible kill.\n\n### Step 3: Define a ruthless MVP\n\nList every imagined feature, then cut to the one core flow that delivers the promise once. Ask: what is the smallest thing that lets a user get the main value one time?\n\n- Cut accounts, settings, admin, and edge cases from v1 wherever possible.\n- Manual is fine: do things that do not scale - a concierge MVP where you personally perform the service beats a month of automation code.\n\n### Step 4: Set the timebox\n\nPick a launch date 2-6 weeks out and scope to fit it. The deadline forces the hard cuts that an open-ended project never makes. Track in a simple kanban (To do \u002F Doing \u002F Done). At the halfway mark, apply the timebox rule: if less than half the scope is done, cut scope again - never move the date first. A slipped side-project date slips forever.\n\n### Step 5: Build lean\n\n- Boring, familiar tools; no-code where it is faster.\n- No premature optimization, no scaling work - you do not have a scaling problem, you have a \"does anyone want this\" problem.\n- Ship something embarrassing but working.\n\n### Step 6: Launch\n\n- Build the audience early - waitlist, build-in-public posts, a small community presence - so launch day is not day one of marketing.\n- Prepare three assets: a clear landing page, a short demo, and the honest story of why you built it.\n- Launch where your users already gather: relevant communities, forums, newsletters, and Product Hunt (for the PH assets and mechanics, use product-hunt-launch). Respect each community's norms - a launch that reads as spam burns the channel permanently.\n- Personally invite every person from the Step 2 interviews.\n\n### Step 7: Measure and decide - with pre-written kill criteria\n\nPick one north-star metric (signups, activations, or revenue) and ignore vanity metrics. Watch whether users reach the core value (activation), not just visit.\n\nWrite the kill criteria before launch, while honesty is cheap:\n\n```\nKILL \u002F CONTINUE - decided before launch, reviewed at week 6\nContinue if:  [FILL: e.g., 20+ activated users, or 5 paying, or retention week-over-week]\nKill if:      north-star below [FILL] by [FILL: date, default 6 weeks post-launch]\n              AND no week-over-week growth for 3 straight weeks\nPivot if:     usage exists but concentrated on an unexpected use case - keep the\n              audience, re-run Step 2 on the new job.\n```\n\nAt the review date, judge against the numbers, not the sunk cost. Double down on pull, kill the absence of it, or pivot while keeping the audience. A clean kill at week six is a success of the process: it returned your evenings.\n\n### Step 8: Early growth loops (if continuing)\n\n- Talk to every early user; fix the single top friction point.\n- Ask happy users for referrals and testimonials.\n- Iterate weekly on the one biggest drop-off point - one fix per week beats five half-fixes.\n\n## Worked artifact: timeboxed plan\n\n```\nSIDE PROJECT PLAN - [FILL: name]\nOne-liner:     I help [FILL: audience] do [FILL: job] better by [FILL: approach].\nHours\u002Fweek:    [FILL]      Launch date: [FILL: 2-6 weeks out]\nValidation:    [FILL: 5-10 interviews done? waitlist\u002Fpre-sale signal?]\nMVP (one flow): [FILL: the single core flow]\nCut list:      accounts \u002F settings \u002F [FILL: everything else deferred]\nNorth star:    [FILL: one metric]\nHalfway check: [FILL: date] - if \u003C50% done, cut scope, keep the date\nKill criteria: [FILL: from Step 7, written before launch]\nReview date:   [FILL: launch + 6 weeks]\n```\n\n## Deliverable\n\nDeliver: the one-line value statement, a validation interview script with a pass\u002Ffail bar, the cut-down MVP feature list with the explicit cut list, the timeboxed plan above filled in, a launch checklist naming the communities and the personal invites, the single north-star metric, and the pre-written kill\u002Fcontinue\u002Fpivot criteria with a review date.\n\n## Do NOT\n\n- Do not ask interviewees whether they like the idea - ask what they do today; opinions about hypotheticals are noise.\n- Do not treat compliments as validation; only behavior (signups, pre-sales, workaround spend) counts.\n- Do not move the launch date when behind - cut scope. The date is the only forcing function a side project has.\n- Do not automate what a concierge MVP can do by hand for the first ten users.\n- Do not launch cold into a community you have never participated in; it reads as spam and burns the channel.\n- Do not write kill criteria after launch - post-launch criteria bend to sunk cost every time.\n\n## Quality bar\n\n- The one-liner names a specific audience, job, and approach - no \"everyone\" audiences.\n- Validation cites behavior evidence, and guesses are labeled as guesses.\n- The MVP is one flow; the cut list is longer than the build list.\n- The timebox is 2-6 weeks with a halfway scope check on the calendar.\n- Kill criteria are numeric, dated, and written before launch.\n","# Side Project Launch\n\nThe biggest side-project risk is not failure - it is spending six months of evenings building something nobody wants, with no deadline forcing the question. A side project runs on scarce hours, so the discipline is different from a startup's: validate with behavior before building, cut the MVP to one flow, timebox hard, and write the kill criteria before launch, when judgment is still honest.\n\n## Operating procedure\n\nValidation precedes building, and the timebox precedes scoping - scope must be cut to fit the date, never the reverse.\n\n### Step 1: Gather inputs\n\n1. The idea, as a one-liner: \"I help [audience] do [job] better by [approach].\" Force the sentence; vagueness here compounds everywhere.\n2. Weekly hours honestly available (default assumption: 5-10 for a side project).\n3. Skills on hand and preferred tools - boring and familiar wins.\n4. The success motive: revenue, portfolio, learning, or fun. The kill criteria in Step 7 depend on it.\n5. Where the audience already gathers.\n\n### Step 2: Validate before building\n\nTalk to 5-10 potential users. Ask about their current behavior, never about your idea:\n\n- How do you handle this today?\n- What is frustrating about that?\n- Have you paid for or actively sought a solution?\n\nEvidence of real pain is people already spending money, time, or duct-tape effort on the problem. A landing page with a waitlist or a small pre-sale is a stronger signal than any number of compliments - compliments are free, behavior is not. Passing bar: several interviewees describe active workarounds or spend, or a simple landing page converts visitors to signups at a few percent. If nobody exhibits the pain, stop here - that is the cheapest possible kill.\n\n### Step 3: Define a ruthless MVP\n\nList every imagined feature, then cut to the one core flow that delivers the promise once. Ask: what is the smallest thing that lets a user get the main value one time?\n\n- Cut accounts, settings, admin, and edge cases from v1 wherever possible.\n- Manual is fine: do things that do not scale - a concierge MVP where you personally perform the service beats a month of automation code.\n\n### Step 4: Set the timebox\n\nPick a launch date 2-6 weeks out and scope to fit it. The deadline forces the hard cuts that an open-ended project never makes. Track in a simple kanban (To do \u002F Doing \u002F Done). At the halfway mark, apply the timebox rule: if less than half the scope is done, cut scope again - never move the date first. A slipped side-project date slips forever.\n\n### Step 5: Build lean\n\n- Boring, familiar tools; no-code where it is faster.\n- No premature optimization, no scaling work - you do not have a scaling problem, you have a \"does anyone want this\" problem.\n- Ship something embarrassing but working.\n\n### Step 6: Launch\n\n- Build the audience early - waitlist, build-in-public posts, a small community presence - so launch day is not day one of marketing.\n- Prepare three assets: a clear landing page, a short demo, and the honest story of why you built it.\n- Launch where your users already gather: relevant communities, forums, newsletters, and Product Hunt (for the PH assets and mechanics, use product-hunt-launch). Respect each community's norms - a launch that reads as spam burns the channel permanently.\n- Personally invite every person from the Step 2 interviews.\n\n### Step 7: Measure and decide - with pre-written kill criteria\n\nPick one north-star metric (signups, activations, or revenue) and ignore vanity metrics. Watch whether users reach the core value (activation), not just visit.\n\nWrite the kill criteria before launch, while honesty is cheap:\n\n```\nKILL \u002F CONTINUE - decided before launch, reviewed at week 6\nContinue if:  [FILL: e.g., 20+ activated users, or 5 paying, or retention week-over-week]\nKill if:      north-star below [FILL] by [FILL: date, default 6 weeks post-launch]\n              AND no week-over-week growth for 3 straight weeks\nPivot if:     usage exists but concentrated on an unexpected use case - keep the\n              audience, re-run Step 2 on the new job.\n```\n\nAt the review date, judge against the numbers, not the sunk cost. Double down on pull, kill the absence of it, or pivot while keeping the audience. A clean kill at week six is a success of the process: it returned your evenings.\n\n### Step 8: Early growth loops (if continuing)\n\n- Talk to every early user; fix the single top friction point.\n- Ask happy users for referrals and testimonials.\n- Iterate weekly on the one biggest drop-off point - one fix per week beats five half-fixes.\n\n## Worked artifact: timeboxed plan\n\n```\nSIDE PROJECT PLAN - [FILL: name]\nOne-liner:     I help [FILL: audience] do [FILL: job] better by [FILL: approach].\nHours\u002Fweek:    [FILL]      Launch date: [FILL: 2-6 weeks out]\nValidation:    [FILL: 5-10 interviews done? waitlist\u002Fpre-sale signal?]\nMVP (one flow): [FILL: the single core flow]\nCut list:      accounts \u002F settings \u002F [FILL: everything else deferred]\nNorth star:    [FILL: one metric]\nHalfway check: [FILL: date] - if \u003C50% done, cut scope, keep the date\nKill criteria: [FILL: from Step 7, written before launch]\nReview date:   [FILL: launch + 6 weeks]\n```\n\n## Deliverable\n\nDeliver: the one-line value statement, a validation interview script with a pass\u002Ffail bar, the cut-down MVP feature list with the explicit cut list, the timeboxed plan above filled in, a launch checklist naming the communities and the personal invites, the single north-star metric, and the pre-written kill\u002Fcontinue\u002Fpivot criteria with a review date.\n\n## Do NOT\n\n- Do not ask interviewees whether they like the idea - ask what they do today; opinions about hypotheticals are noise.\n- Do not treat compliments as validation; only behavior (signups, pre-sales, workaround spend) counts.\n- Do not move the launch date when behind - cut scope. The date is the only forcing function a side project has.\n- Do not automate what a concierge MVP can do by hand for the first ten users.\n- Do not launch cold into a community you have never participated in; it reads as spam and burns the channel.\n- Do not write kill criteria after launch - post-launch criteria bend to sunk cost every time.\n\n## Quality bar\n\n- The one-liner names a specific audience, job, and approach - no \"everyone\" audiences.\n- Validation cites behavior evidence, and guesses are labeled as guesses.\n- The MVP is one flow; the cut list is longer than the build list.\n- The timebox is 2-6 weeks with a halfway scope check on the calendar.\n- Kill criteria are numeric, dated, and written before launch.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Side Project Launch","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fside-project-launch",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 side-project-launch",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill side-project-launch",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill side-project-launch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fside-project-launch\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",[],[]]