[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQ3VSP2XTVX98SC101SQY8":3,"skill-same:01M6JQ3VSP2XTVX98SC101SQY8":81},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":14,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6JQ3VSP2XTVX98SC101SQY8","build-vs-buy",null,"Decide whether to build in-house, buy a vendor\u002FSaaS product, or adopt OSS — core-vs-commodity framing, multi-year total cost of ownership, integration and maintenance burden, vendor viability, lock-in and exit costs. Triggers: build vs buy, build or buy, vendor evaluation, SaaS vs in-house, should we adopt this open source, TCO, total cost of ownership, lock-in, exit cost, make or buy, off the shelf. Internal-structure decisions (patterns, service boundaries, ADRs for your own code) → architecture-design.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-vs-buy\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"build vs buy","buy","build","patterns","source","for","lock","make","triggers","adopt","structure","design","decide","open","Evaluation","open source","product","code","core","architecture","2026-11-10 10:12:30",false,"---\nname: build-vs-buy\ndescription: \"Decide whether to build in-house, buy a vendor\u002FSaaS product, or adopt OSS — core-vs-commodity framing, multi-year total cost of ownership, integration and maintenance burden, vendor viability, lock-in and exit costs. Triggers: build vs buy, build or buy, vendor evaluation, SaaS vs in-house, should we adopt this open source, TCO, total cost of ownership, lock-in, exit cost, make or buy, off the shelf. Internal-structure decisions (patterns, service boundaries, ADRs for your own code) → architecture-design.\"\n---\n\n# Build vs Buy\n\nMake the build\u002Fbuy\u002Fadopt decision on total cost and strategic fit, not on\nwhichever option the room already favors. The two systematic errors this skill\nexists to counter: engineers underestimate the *ongoing* cost of building\n(maintenance routinely exceeds the initial build within a few years), and\neveryone underestimates the *exit* cost of buying (discovered only when\nleaving). Boundary: this skill decides whether the capability comes from\noutside; how you structure your own code is `architecture-design`'s ADR\nterritory, and vetting an individual library is `dependency-management`.\n\n## Workflow\n\n### Step 1: Frame the Capability — Core or Commodity?\n\nName the capability precisely, then ask the question that dominates the whole\ndecision: **does doing this better than anyone else win you customers?** If yes\n(core differentiator), building earns strategic control; if it's commodity\nplumbing (auth, feature flags, payments, analytics infra, CRUD admin), every\nengineer-month spent building it is a month not spent on what differentiates\nyou. Then split requirements into *must-have* and *nice-to-have* — a vendor\ncovering 90% of must-haves usually beats a build covering 100% of a wishlist.\n\n### Step 2: Inventory the Real Options\n\nThere are usually more than two:\n\n- **Build** in-house\n- **Buy** a vendor\u002FSaaS product\n- **Adopt** OSS self-hosted (you're not buying — you're taking an operations job)\n- **Hybrid** — buy\u002Fadopt the commodity core, build the thin differentiating layer\n- **Defer** — do nothing yet; a legitimate option when the need is unproven\n\nVerify current facts (pricing, licensing, maintenance status) with live sources\n— vendor pricing pages and OSS repos, not memory.\n\n### Step 3: TCO Over 3 Years — Not the Sticker Price\n\nCost each finalist over a 3-year horizon; year-1 comparisons systematically\nfavor building (the build cost is visible, the ownership cost isn't):\n\n- **Build**: initial engineering + **ongoing ownership** (maintenance, on-call,\n  security patching, feature parity as needs grow — commonly comparable to the\n  initial build per year for actively-used systems) + **opportunity cost** (what\n  those engineers would otherwise ship — usually the largest and least-counted line).\n- **Buy**: subscription *at projected usage*, not today's (model the pricing\n  curve at 3× growth — usage-based pricing is where vendors recover their\n  discounts) + integration + admin.\n- **Adopt (OSS)**: hosting + operations + upgrades + security response + the\n  expertise to run it; \"free\" describes the license, not the ownership.\n- **Everyone forgets**: migration of existing data\u002Fflows, training, compliance\n  and security review, vendor management overhead.\n\n### Step 4: Risk — Lock-in, Exit, and Viability\n\nWrite the **exit plan now**, while you have leverage — the exit cost you can't\nestimate is the one that traps you:\n\n- What does leaving take? Data export (format? completeness? egress fees?),\n  proprietary APIs\u002Ffeatures you'd re-implement, contract terms (lock-in period,\n  auto-renewal, price-increase caps).\n- **Vendor viability**: funding\u002Fprofitability, roadmap alignment, acquisition\n  risk, what happens to your data if they fold.\n- **OSS health**: maintainer bus factor, release cadence, CVE responsiveness,\n  license (copyleft implications, and watch relicensing-to-source-available\n  history in the space) — delegate a deep package-level check to `dependency-management`.\n- **Build risk** is real too: key-person dependency, and the \"internal vendor\"\n  failure mode — a team obligated to maintain a product nobody funds.\n\n### Step 5: Decide and Record\n\nScore the finalists in a weighted matrix — criteria and weights fixed *before*\nscoring (after, the matrix just rationalizes the favorite). State a clear\nrecommendation with the dominant reasons, name the runner-up and what would\nhave flipped the decision, and set a **revisit trigger** (\"revisit if usage\nexceeds X \u002F pricing changes >Y% \u002F the maintainer goes dark\"). Record it like an\nADR — decision, context, alternatives, consequences — so the next team\nunderstands *why*, not just *what*.\n\n### Step 6: De-risk Before Committing\n\nFor close calls or large commitments, run a time-boxed pilot against your top\nmust-haves and your real data volumes before signing multi-year terms or\nstaffing a build. A two-week PoC is the cheapest insurance in this workflow —\nand pilot the *exit* too (run the data export once and look at what comes out).\n\n## Principles Applied\n\n- **Commodity → buy bias; differentiator → build bias** — most wrong decisions\n  invert this because building is more fun than integrating.\n- **Compare TCO, not sticker price** — the build's cost is mostly after launch;\n  the vendor's is mostly at renewal and exit.\n- **A decision without a revisit trigger is dogma** — pricing, vendors, and\n  your scale all change.\n\n## Cross-Skill References\n\n- `architecture-design` — internal-structure decisions and the ADR format\n- `dependency-management` — deep evaluation of a specific library\u002Fpackage\n- `project-proposal` — wrap the decision in a business case for approval\n- `effort-estimation` — sizing the build option honestly\n- `strategic-review` — when the decision touches positioning or the moat\n","# Build vs Buy\n\nMake the build\u002Fbuy\u002Fadopt decision on total cost and strategic fit, not on\nwhichever option the room already favors. The two systematic errors this skill\nexists to counter: engineers underestimate the *ongoing* cost of building\n(maintenance routinely exceeds the initial build within a few years), and\neveryone underestimates the *exit* cost of buying (discovered only when\nleaving). Boundary: this skill decides whether the capability comes from\noutside; how you structure your own code is `architecture-design`'s ADR\nterritory, and vetting an individual library is `dependency-management`.\n\n## Workflow\n\n### Step 1: Frame the Capability — Core or Commodity?\n\nName the capability precisely, then ask the question that dominates the whole\ndecision: **does doing this better than anyone else win you customers?** If yes\n(core differentiator), building earns strategic control; if it's commodity\nplumbing (auth, feature flags, payments, analytics infra, CRUD admin), every\nengineer-month spent building it is a month not spent on what differentiates\nyou. Then split requirements into *must-have* and *nice-to-have* — a vendor\ncovering 90% of must-haves usually beats a build covering 100% of a wishlist.\n\n### Step 2: Inventory the Real Options\n\nThere are usually more than two:\n\n- **Build** in-house\n- **Buy** a vendor\u002FSaaS product\n- **Adopt** OSS self-hosted (you're not buying — you're taking an operations job)\n- **Hybrid** — buy\u002Fadopt the commodity core, build the thin differentiating layer\n- **Defer** — do nothing yet; a legitimate option when the need is unproven\n\nVerify current facts (pricing, licensing, maintenance status) with live sources\n— vendor pricing pages and OSS repos, not memory.\n\n### Step 3: TCO Over 3 Years — Not the Sticker Price\n\nCost each finalist over a 3-year horizon; year-1 comparisons systematically\nfavor building (the build cost is visible, the ownership cost isn't):\n\n- **Build**: initial engineering + **ongoing ownership** (maintenance, on-call,\n  security patching, feature parity as needs grow — commonly comparable to the\n  initial build per year for actively-used systems) + **opportunity cost** (what\n  those engineers would otherwise ship — usually the largest and least-counted line).\n- **Buy**: subscription *at projected usage*, not today's (model the pricing\n  curve at 3× growth — usage-based pricing is where vendors recover their\n  discounts) + integration + admin.\n- **Adopt (OSS)**: hosting + operations + upgrades + security response + the\n  expertise to run it; \"free\" describes the license, not the ownership.\n- **Everyone forgets**: migration of existing data\u002Fflows, training, compliance\n  and security review, vendor management overhead.\n\n### Step 4: Risk — Lock-in, Exit, and Viability\n\nWrite the **exit plan now**, while you have leverage — the exit cost you can't\nestimate is the one that traps you:\n\n- What does leaving take? Data export (format? completeness? egress fees?),\n  proprietary APIs\u002Ffeatures you'd re-implement, contract terms (lock-in period,\n  auto-renewal, price-increase caps).\n- **Vendor viability**: funding\u002Fprofitability, roadmap alignment, acquisition\n  risk, what happens to your data if they fold.\n- **OSS health**: maintainer bus factor, release cadence, CVE responsiveness,\n  license (copyleft implications, and watch relicensing-to-source-available\n  history in the space) — delegate a deep package-level check to `dependency-management`.\n- **Build risk** is real too: key-person dependency, and the \"internal vendor\"\n  failure mode — a team obligated to maintain a product nobody funds.\n\n### Step 5: Decide and Record\n\nScore the finalists in a weighted matrix — criteria and weights fixed *before*\nscoring (after, the matrix just rationalizes the favorite). State a clear\nrecommendation with the dominant reasons, name the runner-up and what would\nhave flipped the decision, and set a **revisit trigger** (\"revisit if usage\nexceeds X \u002F pricing changes >Y% \u002F the maintainer goes dark\"). Record it like an\nADR — decision, context, alternatives, consequences — so the next team\nunderstands *why*, not just *what*.\n\n### Step 6: De-risk Before Committing\n\nFor close calls or large commitments, run a time-boxed pilot against your top\nmust-haves and your real data volumes before signing multi-year terms or\nstaffing a build. A two-week PoC is the cheapest insurance in this workflow —\nand pilot the *exit* too (run the data export once and look at what comes out).\n\n## Principles Applied\n\n- **Commodity → buy bias; differentiator → build bias** — most wrong decisions\n  invert this because building is more fun than integrating.\n- **Compare TCO, not sticker price** — the build's cost is mostly after launch;\n  the vendor's is mostly at renewal and exit.\n- **A decision without a revisit trigger is dogma** — pricing, vendors, and\n  your scale all change.\n\n## Cross-Skill References\n\n- `architecture-design` — internal-structure decisions and the ADR format\n- `dependency-management` — deep evaluation of a specific library\u002Fpackage\n- `project-proposal` — wrap the decision in a business case for approval\n- `effort-estimation` — sizing the build option honestly\n- `strategic-review` — when the decision touches positioning or the moat\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","skills\u002Fbuild-vs-buy","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill build-vs-buy",{"tool":67,"command":68},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill build-vs-buy",{"tool":70,"command":71},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill build-vs-buy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-vs-buy\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Fevals.json","REFERENCE","参考文档",3990,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-vs-buy\u002Fevals\u002Fevals.json",[82,121,148,172,203,230],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":101,"publishedAt":49},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[88,91,94,95,98],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":96,"categoryName":97,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":99,"categoryName":100,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000040","财务",[102,103,104,105,106,107,108,109,110,111,112,113,37,114,115,116,117,118,119,120],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":128,"publishedAt":49},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[127],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,37,147],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":49},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[154],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[156,157,158,159,160,161,102,162,132,163,164,165,135,166,139,167,168,169,170,171],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":185,"publishedAt":49},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[178,181,182],{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":183,"categoryName":184,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[40,186,187,188,189,190,191,192,193,194,195,196,137,197,198,32,199,200,201,202],"ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","mockup","responsive","form","page",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":211,"publishedAt":49},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[209,210],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[212,213,214,215,216,217,40,218,219,220,46,221,222,223,224,225,226,227,228,229],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":241,"publishedAt":49},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[236,237,238,239,240],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":183,"categoryName":184,"taxonomyType":26,"taxonomyTypeDesc":27},[40,242,243,244,245,246,104,247,248,162,46,249,250,106,251,252,144,253,34,37],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan"]