[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751NTS8G6NERW00X30JHB4Z":3,"skill-same:01M751NTS8G6NERW00X30JHB4Z":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},"01M751NTS8G6NERW00X30JHB4Z","sales-proposal-writer",null,"Writes a B2B sales proposal or SOW that restates the buyer's problem in their own words, quantifies the cost of inaction, presents price as anchored options, and drives one dated next step. Use when someone asks \"write a proposal for this client\", \"turn my discovery notes into a proposal\", \"how should I present pricing in this proposal\", or when a deal needs a document to move from discovery to close. Do NOT use for a one-page internal decision brief - use one-pager-designer instead; for investor decks use pitch-deck-builder; for setting the underlying price model use pricing-strategy.","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\u002Fsales-proposal-writer\u002FSKILL.md",[],[],"2026-11-11 18:21:06",false,"---\nname: sales-proposal-writer\ndescription: Writes a B2B sales proposal or SOW that restates the buyer's problem in their own words, quantifies the cost of inaction, presents price as anchored options, and drives one dated next step. Use when someone asks \"write a proposal for this client\", \"turn my discovery notes into a proposal\", \"how should I present pricing in this proposal\", or when a deal needs a document to move from discovery to close. Do NOT use for a one-page internal decision brief - use one-pager-designer instead; for investor decks use pitch-deck-builder; for setting the underlying price model use pricing-strategy.\nmetadata:\n  title: \"Sales Proposal Writer\"\n---\n\n# Sales Proposal Writer\n\nA proposal should make the buyer feel understood before it sells anything. If the first page is about the vendor, the buyer stops reading; if the price appears as one take-it-or-leave-it number, the negotiation becomes about discounting instead of scope. This skill produces a proposal that mirrors the buyer's own words back to them, anchors the price with options, and expires - so the deal has a reason to move.\n\n## Inputs to collect\n\nGather these before drafting. Where an input is missing, use the default and label the guess as a guess.\n\n1. **Discovery notes or call transcript** - the buyer's own phrasing of the problem is the raw material for the opening. Without at least one direct quote or near-quote, the proposal will read as a template.\n2. **The quantified pain** - numbers the buyer gave (hours lost, revenue at risk, headcount cost). If none surfaced, compute a reasonable range and flag it: \"estimated, based on your stated team size of 12.\"\n3. **Named stakeholders** - who signs, who uses, who blocks.\n4. **Deal size and complexity** - determines document length and whether itemization is warranted.\n5. **Proposed scope options** - what a lean, standard, and expanded engagement would each contain.\n6. **Desired start date** - anchors the validity window and the next step.\n\n## Operating procedure\n\nOrder matters: the buyer's problem must be established before any solution appears, and price must never appear before value.\n\n1. **Restate their problem in their words, first.** Open with a two-to-three-sentence situation summary that mirrors discovery. Quote the buyer directly where possible. This section mentions the vendor zero times.\n2. **Make the cost of inaction concrete.** Use the buyer's numbers. \"Your team currently spends ~40 hours\u002Fmonth reconciling exports, roughly $48K\u002Fyear at your stated loaded cost\" beats any adjective. Label estimates as estimates.\n3. **Present the approach as outcomes, not activities.** \"Your team will be able to close the books in 3 days instead of 9\" beats \"We will deliver a data pipeline.\" One paragraph per outcome.\n4. **Define scope and deliverables per phase or workstream.** Specific enough to be credible, loose enough to avoid scope arguments before the contract is signed. Push technical detail to an appendix.\n5. **Present the investment as options with an anchor.** Offer two or three tiers, listed highest first - the anchor. The middle option is the one most buyers should choose; design it that way. Do not itemize line-by-line unless the buyer asked or the deal is complex enough to require it: itemized pricing invites nickel-and-diming. A single number is acceptable only for transactional deals under roughly $10K.\n6. **Add a validity window.** Every proposal expires - 30 days is standard; 14 days for a deal with a stated urgent start date. An open-ended proposal gives the buyer permission to stall indefinitely.\n7. **Close with one dated next step.** One action, one suggested date within 5 business days: \"If this looks right, the simplest path forward is a 30-minute call Tuesday to align on the start date.\"\n8. **Run the customization check.** Confirm at least three details that could only apply to this buyer: their team size, a specific pain they named, a named stakeholder. Fewer than three and the proposal reads as a mail merge - and will be treated like one.\n\n## Thresholds\n\n- Body length: under **3 pages** for a typical mid-market deal; readable in under **5 minutes**. Appendices carry technical specs and legal terms.\n- Situation summary: 2-3 sentences, at least one buyer quote or near-quote.\n- Pricing: 2-3 options, anchor listed first; middle option designed as the intended choice.\n- Validity: 30 days standard, 14 days when urgency is real.\n- Next step: dated within 5 business days of sending.\n- Customization: minimum 3 buyer-specific details.\n\n## Proposal skeleton (copy and fill)\n\n```\n[BUYER COMPANY] - Proposal: [OUTCOME, NOT PRODUCT NAME]\nPrepared for [STAKEHOLDER NAME], [DATE] · Valid through [DATE + 30 DAYS]\n\n1. YOUR SITUATION\n[2-3 sentences mirroring discovery. Include: \"[DIRECT BUYER QUOTE]\"]\n\n2. WHAT THIS IS COSTING YOU\n[FILL: buyer's numbers → annualized cost. Label estimates: \"estimated, based on [STATED FACT]\"]\n\n3. PROPOSED APPROACH\n[FILL: 2-3 outcome statements - \"Your team will be able to X\"]\n\n4. SCOPE & DELIVERABLES\nPhase 1 - [NAME]: [deliverables, duration]\nPhase 2 - [NAME]: [deliverables, duration]\n\n5. INVESTMENT\nOption A - [EXPANDED SCOPE]: $[ANCHOR PRICE]\nOption B - [STANDARD SCOPE]: $[INTENDED PRICE]   ← most clients choose this\nOption C - [LEAN SCOPE]: $[FLOOR PRICE]\nPricing valid through [DATE].\n\n6. NEXT STEP\n[ONE action, ONE date]: \"If this looks right, a 30-minute call on [DAY] to align on start date.\"\n\nAppendix: [technical specs \u002F legal terms \u002F assumptions]\n```\n\n## Deliverable\n\nProduce a proposal document containing: the buyer-worded situation summary, the quantified cost of inaction, outcome-framed approach, phased scope, a 2-3 option anchored investment section with a validity date, one dated next step, and an appendix for anything technical or legal.\n\n## Do NOT\n\n- **Do NOT lead with a company bio or awards page** - it signals a template and the buyer stops reading.\n- **Do NOT list features the buyer never asked about** - every unrequested feature dilutes the ones they did.\n- **Do NOT include a generic ROI calculator** not built from the buyer's actual data - it undermines credibility more than it helps.\n- **Do NOT present price before value** - investment is section 5, never section 1.\n- **Do NOT skip the expiry date** - an undated proposal has no forcing function.\n- **Do NOT write a formal document for a small transactional deal.** Use the same structure - situation, value, scope, price, next step - as three short paragraphs in an email instead.\n\n## Quality bar\n\nBefore sending, verify: the first section contains zero vendor mentions and at least one buyer quote; the cost of inaction has a number; pricing shows options with the anchor first and a validity date; the next step names a date; at least three buyer-specific details appear; the body reads in under five minutes with no jargon, buzzwords, or passive voice. Any sentence that does not add information the buyer needs to decide gets cut.\n","# Sales Proposal Writer\n\nA proposal should make the buyer feel understood before it sells anything. If the first page is about the vendor, the buyer stops reading; if the price appears as one take-it-or-leave-it number, the negotiation becomes about discounting instead of scope. This skill produces a proposal that mirrors the buyer's own words back to them, anchors the price with options, and expires - so the deal has a reason to move.\n\n## Inputs to collect\n\nGather these before drafting. Where an input is missing, use the default and label the guess as a guess.\n\n1. **Discovery notes or call transcript** - the buyer's own phrasing of the problem is the raw material for the opening. Without at least one direct quote or near-quote, the proposal will read as a template.\n2. **The quantified pain** - numbers the buyer gave (hours lost, revenue at risk, headcount cost). If none surfaced, compute a reasonable range and flag it: \"estimated, based on your stated team size of 12.\"\n3. **Named stakeholders** - who signs, who uses, who blocks.\n4. **Deal size and complexity** - determines document length and whether itemization is warranted.\n5. **Proposed scope options** - what a lean, standard, and expanded engagement would each contain.\n6. **Desired start date** - anchors the validity window and the next step.\n\n## Operating procedure\n\nOrder matters: the buyer's problem must be established before any solution appears, and price must never appear before value.\n\n1. **Restate their problem in their words, first.** Open with a two-to-three-sentence situation summary that mirrors discovery. Quote the buyer directly where possible. This section mentions the vendor zero times.\n2. **Make the cost of inaction concrete.** Use the buyer's numbers. \"Your team currently spends ~40 hours\u002Fmonth reconciling exports, roughly $48K\u002Fyear at your stated loaded cost\" beats any adjective. Label estimates as estimates.\n3. **Present the approach as outcomes, not activities.** \"Your team will be able to close the books in 3 days instead of 9\" beats \"We will deliver a data pipeline.\" One paragraph per outcome.\n4. **Define scope and deliverables per phase or workstream.** Specific enough to be credible, loose enough to avoid scope arguments before the contract is signed. Push technical detail to an appendix.\n5. **Present the investment as options with an anchor.** Offer two or three tiers, listed highest first - the anchor. The middle option is the one most buyers should choose; design it that way. Do not itemize line-by-line unless the buyer asked or the deal is complex enough to require it: itemized pricing invites nickel-and-diming. A single number is acceptable only for transactional deals under roughly $10K.\n6. **Add a validity window.** Every proposal expires - 30 days is standard; 14 days for a deal with a stated urgent start date. An open-ended proposal gives the buyer permission to stall indefinitely.\n7. **Close with one dated next step.** One action, one suggested date within 5 business days: \"If this looks right, the simplest path forward is a 30-minute call Tuesday to align on the start date.\"\n8. **Run the customization check.** Confirm at least three details that could only apply to this buyer: their team size, a specific pain they named, a named stakeholder. Fewer than three and the proposal reads as a mail merge - and will be treated like one.\n\n## Thresholds\n\n- Body length: under **3 pages** for a typical mid-market deal; readable in under **5 minutes**. Appendices carry technical specs and legal terms.\n- Situation summary: 2-3 sentences, at least one buyer quote or near-quote.\n- Pricing: 2-3 options, anchor listed first; middle option designed as the intended choice.\n- Validity: 30 days standard, 14 days when urgency is real.\n- Next step: dated within 5 business days of sending.\n- Customization: minimum 3 buyer-specific details.\n\n## Proposal skeleton (copy and fill)\n\n```\n[BUYER COMPANY] - Proposal: [OUTCOME, NOT PRODUCT NAME]\nPrepared for [STAKEHOLDER NAME], [DATE] · Valid through [DATE + 30 DAYS]\n\n1. YOUR SITUATION\n[2-3 sentences mirroring discovery. Include: \"[DIRECT BUYER QUOTE]\"]\n\n2. WHAT THIS IS COSTING YOU\n[FILL: buyer's numbers → annualized cost. Label estimates: \"estimated, based on [STATED FACT]\"]\n\n3. PROPOSED APPROACH\n[FILL: 2-3 outcome statements - \"Your team will be able to X\"]\n\n4. SCOPE & DELIVERABLES\nPhase 1 - [NAME]: [deliverables, duration]\nPhase 2 - [NAME]: [deliverables, duration]\n\n5. INVESTMENT\nOption A - [EXPANDED SCOPE]: $[ANCHOR PRICE]\nOption B - [STANDARD SCOPE]: $[INTENDED PRICE]   ← most clients choose this\nOption C - [LEAN SCOPE]: $[FLOOR PRICE]\nPricing valid through [DATE].\n\n6. NEXT STEP\n[ONE action, ONE date]: \"If this looks right, a 30-minute call on [DAY] to align on start date.\"\n\nAppendix: [technical specs \u002F legal terms \u002F assumptions]\n```\n\n## Deliverable\n\nProduce a proposal document containing: the buyer-worded situation summary, the quantified cost of inaction, outcome-framed approach, phased scope, a 2-3 option anchored investment section with a validity date, one dated next step, and an appendix for anything technical or legal.\n\n## Do NOT\n\n- **Do NOT lead with a company bio or awards page** - it signals a template and the buyer stops reading.\n- **Do NOT list features the buyer never asked about** - every unrequested feature dilutes the ones they did.\n- **Do NOT include a generic ROI calculator** not built from the buyer's actual data - it undermines credibility more than it helps.\n- **Do NOT present price before value** - investment is section 5, never section 1.\n- **Do NOT skip the expiry date** - an undated proposal has no forcing function.\n- **Do NOT write a formal document for a small transactional deal.** Use the same structure - situation, value, scope, price, next step - as three short paragraphs in an email instead.\n\n## Quality bar\n\nBefore sending, verify: the first section contains zero vendor mentions and at least one buyer quote; the cost of inaction has a number; pricing shows options with the anchor first and a validity date; the next step names a date; at least three buyer-specific details appear; the body reads in under five minutes with no jargon, buzzwords, or passive voice. Any sentence that does not add information the buyer needs to decide gets cut.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Sales Proposal Writer","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fsales-proposal-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 sales-proposal-writer",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill sales-proposal-writer",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill sales-proposal-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsales-proposal-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",[],[]]