[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M750H083GSAZQ8HT93XCC3K8":3,"skill-same:01M750H083GSAZQ8HT93XCC3K8":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},"01M750H083GSAZQ8HT93XCC3K8","fpa-model",null,"Builds a driver-based FP&A operating model linking business inputs to P&L, balance sheet, and cash flow outputs. Use when building an annual plan, preparing investor materials, running scenario analysis, or stress-testing the business.","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\u002Ffpa-model\u002FSKILL.md",[],[],"2026-11-11 17:59:37",false,"---\nname: fpa-model\ndescription: Builds a driver-based FP&A operating model linking business inputs to P&L, balance sheet, and cash flow outputs. Use when building an annual plan, preparing investor materials, running scenario analysis, or stress-testing the business.\nmetadata:\n  title: \"FP&A Operating Model\"\n---\n\n# FP&A Operating Model\n\nA driver-based model is built on the belief that financial outputs are the result of measurable business actions. Revenue is not a number pulled from a goal - it is a function of pipeline, conversion rate, average contract value, and sales capacity. Every assumption should be traceable to a business driver, not a wish.\n\n## Model Architecture\n\nStructure the model in four layers. The Assumptions layer holds every input: growth rates, hiring plan, pricing, margins, DSO, and macro variables. The Revenue layer translates demand drivers into recognized revenue. The Expense layer translates the headcount plan and operational drivers into opex and COGS line items. The Output layer assembles the three financial statements automatically from the above. Never hardcode a number in the output layer - it must flow from the assumptions.\n\n## Revenue Build\n\nFor SaaS or subscription: start with beginning ARR, add new ARR from new logos (pipeline times close rate times ACV), add expansion ARR, subtract churn ARR (beginning ARR times churn rate), to get ending ARR. Monthly revenue equals ending ARR divided by 12. For transaction businesses: units sold times ASP, by segment. For services: billable headcount times utilization rate times bill rate. Make the revenue build auditable - one row per driver. Sanity-check the drivers against benchmarks: a modeled close rate above 25-30% on cold pipeline, or gross churn assumptions below 5% annually for an SMB product, deserve a written justification because they are outside typical ranges.\n\n## Expense Build\n\nHeadcount is the anchor. Build a headcount roster with role, department, start month, fully-loaded cost per head (salary plus benefits plus payroll tax, typically 1.2 to 1.3 times base). Derive compensation expense from the roster. Non-headcount opex should be modeled as either a fixed amount per month or a variable rate tied to a driver (e.g., hosting costs as a percentage of revenue - commonly 8-15% for a SaaS business, and a red flag above 20% - or sales commissions as a percentage of new ARR, typically in the 8-12% range). Avoid modeling opex as a flat year-over-year growth rate - it obscures the underlying drivers. Ramp new hires realistically: a sales hire typically reaches full productivity in month 4-6, not month one.\n\n## Scenario Framework\n\nBuild three scenarios into the assumptions layer: Base (most likely), Bull (upside on revenue drivers, flat costs), Bear (revenue miss, cost reduction response). The model outputs should change automatically when the scenario selector changes. The gap between Bull and Bear operating cash flow in month 18 is your planning uncertainty band. If that band is wider than your cash on hand, you need either a larger reserve or a tighter cost structure. In the Bear case, runway dropping below 12 months is the trigger line for action - either a raise or a cost plan - because a fundraise itself consumes 6+ months.\n\n## Model Hygiene\n\nOne formula per row - do not mix hardcoded numbers and formulas in the same column range. Color-code inputs (blue) versus calculated cells (black) so any reviewer can spot manual overrides. Date the version and lock the prior actuals columns. A model that is easy to audit will be used; one that is not will be replaced with a spreadsheet in someone's desktop.\n\n## Key Outputs to Surface\n\nGross margin percentage by period. Operating margin. Headcount by department end of period. Net new ARR (for SaaS). Operating cash flow. Runway in months. These six metrics should appear on a summary dashboard tab that updates from the model automatically.\n\n## Do NOT\n\n- Do not back into revenue from a target (\"we need $10M so the model says $10M\") - the drivers must produce the number, or the plan is a wish with formatting.\n- Do not model opex as last year plus a growth percentage; it hides the headcount and unit-cost decisions the model exists to expose.\n- Do not hardcode values in calculated ranges to \"fix\" a bad output - the override survives the review, poisons every scenario, and is the most common way models silently rot.\n- Do not let headcount live outside the roster (a \"misc hires\" line); every head needs a role, start month, and loaded cost or the expense build is fiction.\n- Do not present a single-scenario model to a board or investor; without a Bear case the model cannot answer the only question that matters - what happens if revenue misses.\n- Do not update assumptions without re-dating the version and noting what changed; an unlabeled model fork destroys trust in every number downstream.\n\n## Quality bar\n\n- Every output-layer number traces to an assumptions-layer input; zero hardcodes in calculated ranges.\n- The three scenarios switch from one selector and the Bear case includes a costed response, not just lower revenue.\n- The headcount roster fully explains compensation expense, with loaded costs at 1.2-1.3x base and realistic ramp.\n- The six dashboard metrics update automatically and runway is visible in every scenario.\n- Drivers outside typical benchmark ranges carry a written justification.\n","# FP&A Operating Model\n\nA driver-based model is built on the belief that financial outputs are the result of measurable business actions. Revenue is not a number pulled from a goal - it is a function of pipeline, conversion rate, average contract value, and sales capacity. Every assumption should be traceable to a business driver, not a wish.\n\n## Model Architecture\n\nStructure the model in four layers. The Assumptions layer holds every input: growth rates, hiring plan, pricing, margins, DSO, and macro variables. The Revenue layer translates demand drivers into recognized revenue. The Expense layer translates the headcount plan and operational drivers into opex and COGS line items. The Output layer assembles the three financial statements automatically from the above. Never hardcode a number in the output layer - it must flow from the assumptions.\n\n## Revenue Build\n\nFor SaaS or subscription: start with beginning ARR, add new ARR from new logos (pipeline times close rate times ACV), add expansion ARR, subtract churn ARR (beginning ARR times churn rate), to get ending ARR. Monthly revenue equals ending ARR divided by 12. For transaction businesses: units sold times ASP, by segment. For services: billable headcount times utilization rate times bill rate. Make the revenue build auditable - one row per driver. Sanity-check the drivers against benchmarks: a modeled close rate above 25-30% on cold pipeline, or gross churn assumptions below 5% annually for an SMB product, deserve a written justification because they are outside typical ranges.\n\n## Expense Build\n\nHeadcount is the anchor. Build a headcount roster with role, department, start month, fully-loaded cost per head (salary plus benefits plus payroll tax, typically 1.2 to 1.3 times base). Derive compensation expense from the roster. Non-headcount opex should be modeled as either a fixed amount per month or a variable rate tied to a driver (e.g., hosting costs as a percentage of revenue - commonly 8-15% for a SaaS business, and a red flag above 20% - or sales commissions as a percentage of new ARR, typically in the 8-12% range). Avoid modeling opex as a flat year-over-year growth rate - it obscures the underlying drivers. Ramp new hires realistically: a sales hire typically reaches full productivity in month 4-6, not month one.\n\n## Scenario Framework\n\nBuild three scenarios into the assumptions layer: Base (most likely), Bull (upside on revenue drivers, flat costs), Bear (revenue miss, cost reduction response). The model outputs should change automatically when the scenario selector changes. The gap between Bull and Bear operating cash flow in month 18 is your planning uncertainty band. If that band is wider than your cash on hand, you need either a larger reserve or a tighter cost structure. In the Bear case, runway dropping below 12 months is the trigger line for action - either a raise or a cost plan - because a fundraise itself consumes 6+ months.\n\n## Model Hygiene\n\nOne formula per row - do not mix hardcoded numbers and formulas in the same column range. Color-code inputs (blue) versus calculated cells (black) so any reviewer can spot manual overrides. Date the version and lock the prior actuals columns. A model that is easy to audit will be used; one that is not will be replaced with a spreadsheet in someone's desktop.\n\n## Key Outputs to Surface\n\nGross margin percentage by period. Operating margin. Headcount by department end of period. Net new ARR (for SaaS). Operating cash flow. Runway in months. These six metrics should appear on a summary dashboard tab that updates from the model automatically.\n\n## Do NOT\n\n- Do not back into revenue from a target (\"we need $10M so the model says $10M\") - the drivers must produce the number, or the plan is a wish with formatting.\n- Do not model opex as last year plus a growth percentage; it hides the headcount and unit-cost decisions the model exists to expose.\n- Do not hardcode values in calculated ranges to \"fix\" a bad output - the override survives the review, poisons every scenario, and is the most common way models silently rot.\n- Do not let headcount live outside the roster (a \"misc hires\" line); every head needs a role, start month, and loaded cost or the expense build is fiction.\n- Do not present a single-scenario model to a board or investor; without a Bear case the model cannot answer the only question that matters - what happens if revenue misses.\n- Do not update assumptions without re-dating the version and noting what changed; an unlabeled model fork destroys trust in every number downstream.\n\n## Quality bar\n\n- Every output-layer number traces to an assumptions-layer input; zero hardcodes in calculated ranges.\n- The three scenarios switch from one selector and the Bear case includes a costed response, not just lower revenue.\n- The headcount roster fully explains compensation expense, with loaded costs at 1.2-1.3x base and realistic ramp.\n- The six dashboard metrics update automatically and runway is visible in every scenario.\n- Drivers outside typical benchmark ranges carry a written justification.\n",{"name":5,"metadata":24,"description":7},{"title":25},"FP&A Operating Model","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Ffpa-model",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 fpa-model",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill fpa-model",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill fpa-model","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ffpa-model\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",[],[]]