[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X6A6T7PX95CF1C3VSTRASC":3,"skill-same:01M6X6A6T7PX95CF1C3VSTRASC":83},{"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":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":66,"ownerDescription":68,"updatedAt":69,"install":70,"resources":82},"01M6X6A6T7PX95CF1C3VSTRASC","build-buy-partner",null,"Use when deciding insource vs outsource vs acquire — integration-cost analysis, dependency-risk, optionality preservation. Triggers on 'should we build', 'buy vs partner'.","event4u-app\u002Fagent-config","event4u-app","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199339632?v=4","01M6X5TWBNCQCE1VDKT4E9KF7N","event4u.app","01M6X5TWF4HRM266RG2Q5VVH1X",19,"MIT","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fbuild-buy-partner\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"build buy partner","partner","build","buy","active","senior","when","true","org","segment","triggers","stage","customer","dependency","acquire","use","strategy","analysis","risk","product","cost analysis","2026-11-10 10:12:30",false,"---\nmodel_tier: inherit\nname: build-buy-partner\ndescription: \"Use when deciding insource vs outsource vs acquire — integration-cost analysis, dependency-risk, optionality preservation. Triggers on 'should we build', 'buy vs partner'.\"\nstatus: active\ntier: senior\ndomain: process\ncontext_spine: [org-stage, product, customer-segment]\nworkspaces:\n  - founder\npacks:\n  - founder-strategy\ninstall:\n  removable: true\n---\n\n# build-buy-partner\n\n## When to use\n\n- A capability gap exists and the question is whether to build internally, buy a vendor \u002F acquisition, or partner.\n- An \"obviously build\" choice has crept in by default; the question is whether it survives a deliberate compare.\n- A vendor \u002F partner relationship is up for renewal; the question is whether to keep buying, switch, or insource.\n- An acquisition has been floated; the question is whether the integration cost justifies the speed-to-capability.\n\nDo NOT use for vendor selection within a \"buy\" decision (different skill), market-entry beachhead choice (route to `market-entry-analysis` (P2)), or scenario-shape comparison (route to `scenario-modeling` (O4); P1 consumes O4's bundle).\n\n## Cognition cluster\n\n- **Mental model 28 — Inversion.** *\"What would force us to undo this choice in 18 months?\"* Inversion surfaces the dependency-risk and integration-cost that the forward case understates. See [`mental-models.md`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Fmental-models.md) § 28.\n- **Mental model 21 — Second-order thinking.** Each option chains: build → ongoing maintenance + opportunity cost; buy → integration + lock-in; partner → dependency + boundary management. Single-order *\"build is cheaper\"* fails on the second-order. See `mental-models.md` § 21.\n- **Mental model 26 — Optionality.** Read each option by which choices it preserves (switch costs, re-build optionality, re-negotiation power) vs forecloses. The option with bounded foreclosure usually wins. See `mental-models.md` § 26.\n- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for capacity (pre-seed should buy almost everything non-core; growth-stage can build deeper). Read **product** for whether the capability is core-differentiation (build) or commodity (buy). Read **customer-segment** for whether enterprise-segment buyers require a build-it-yourself story.\n\n## Procedure\n\n### Step 0: Frame the capability as core vs commodity\n\nTwo questions:\n\n1. *Is this capability a differentiator for our customers?* If yes → build-bias. If no → buy-bias.\n2. *Does it sit on the critical path of our product?* If yes + differentiator → build. If yes + commodity → buy. If no → partner.\n\nThe matrix is the starting frame, not the answer. Override is allowed but requires writing the override reason.\n\n### Step 1: Inventory the three options concretely\n\nDo not compare abstractions. Each option = a concrete plan:\n\n1. **Build** — named team, named timeline, named ongoing-maintenance cost. *\"Squad of 3 engineers for 6 months + 1 FTE ongoing\"* not *\"we'd build it\"*.\n2. **Buy** — named vendor (or vendor shortlist), named pricing band, named integration scope. *\"Vendor X at $80k ARR + 4-week integration\"* not *\"we'd find a vendor\"*.\n3. **Partner** — named partner, named scope of dependency, named exit clause. *\"Partner Y owns the X interface with 90-day exit\"* not *\"we'd partner\"*.\n\nUn-named options compare to nothing.\n\n### Step 1.5: Inspect the differentiator claim\n\nBefore locking the matrix from Step 0, inspect the claim that this is\nor isn't a differentiator. Two questions: *\"would a customer leave us\nif a competitor had a better version of this capability?\"* and *\"is\nthe current build advantage replicable by a vendor with one quarter of\nfocused work?\"* Both `yes` answers → the capability is less of a\ndifferentiator than the frame suggested; bias back to buy.\n\n### Step 2: Compute integration cost honestly\n\nIntegration cost is the most under-counted number. For each option:\n\n1. **Build** — engineering time + management overhead + opportunity cost (what's the team *not* building?).\n2. **Buy** — vendor integration (weeks to first value) + ongoing change-management cost + lock-in (cost to switch off).\n3. **Partner** — boundary management + divergence cost (what happens when partner changes their roadmap?).\n\nA buy decision with 2-week integration is rare; industry-typical ranges (public integration benchmarks — not a prediction of your timeline, per `direct-answers` § no duration estimates) run 4–8 weeks for non-trivial integrations and 3–6 months for enterprise-grade ones.\n\n### Step 3: Inversion — name the failure mode for each option\n\nFor each option, write the 18-month failure mode:\n\n1. **Build fails** — *\"team built the wrong thing because requirements shifted under them\"* \u002F *\"team left and knowledge walked\"*.\n2. **Buy fails** — *\"vendor changed pricing 3×\"* \u002F *\"vendor acquired and roadmap diverged\"* \u002F *\"vendor sunset the product line\"*.\n3. **Partner fails** — *\"partner's incentive misaligned\"* \u002F *\"partner's customer became our competitor\"*.\n\nIf one option's failure mode is *\"can't think of one\"*, the analysis is incomplete; sit with it longer.\n\n### Step 4: Read optionality\n\nFor each option:\n\n1. **Preserved options** — what future choices remain (switch vendor, re-build, deepen the build, expand the partnership).\n2. **Foreclosed options** — what future choices are off the table (re-build after 2 years of vendor lock-in; re-vendor after a build commitment; competing against a former partner).\n\nThe decision is rarely about today's cost; it's about which option preserves the choices we'll need in 18 months.\n\n### Step 5: Decide and emit the ADR\n\nPick one. Emit a build-buy-partner ADR via the `adr-create` skill, citing this skill's output. The ADR is the durable record; the artifacts here are the cognition that justify it.\n\n## Related Skills\n\n**WHEN to use this**\n\n- Insource-vs-outsource-vs-acquire decisions on a capability gap.\n- Vendor renewal \u002F re-evaluation where re-building or switching is on the table.\n\n**WHEN NOT to use this**\n\n- Vendor selection within a locked buy decision — different skill (not in this roadmap).\n- Market-entry beachhead choice — route to [`market-entry-analysis`](..\u002Fmarket-entry-analysis\u002FSKILL.md) (P2).\n- Scenario shape comparison — route to [`scenario-modeling`](..\u002Fscenario-modeling\u002FSKILL.md) (O4); P1 consumes O4's `scenario-bundle.md`.\n- Org-shape changes (reorg, team-split) — route to [`org-design`](..\u002Forg-design\u002FSKILL.md) (Q1); P1 composes Q1 for the \"build\" option's team shape.\n- Decision-record authoring mechanics — route to [`adr-create`](..\u002Fadr-create\u002FSKILL.md); P1 emits an ADR via that skill.\n- A generic multi-option choice on custom user-weighted criteria (not build\u002Fbuy\u002Fpartner-shaped) — route to [`decision-record`](..\u002Fdecision-record\u002FSKILL.md) § Weighted-matrix mode; this skill stays the domain-specific instance.\n\n## When the agent should load this\n\n- \"Should we build this or buy a vendor?\"\n- \"Make-vs-buy on capability X.\"\n- \"Should we partner with Y or build in-house?\"\n- \"Renew vendor Z or insource?\"\n- \"Bauen wir das selber oder kaufen?\"\n\n## Output\n\n1. **`build-buy-partner-frame.md`** — capability framing (core \u002F commodity, critical-path \u002F not), three concrete options named, integration-cost table per option.\n2. **`failure-modes.md`** — 18-month inversion per option; named failure paths.\n3. **`optionality-map.md`** — preserved \u002F foreclosed options per choice; recommended option with reasoning.\n4. **ADR** *(via `adr-create`)* — the durable decision record; this skill produces the cognition, `adr-create` produces the file.\n\n## Gotcha\n\n- \"Build\" defaults are the most common silent choice. Engineers' bias is to build; the absence of a buy \u002F partner option in the inventory is the bug, not a feature.\n- Integration cost is under-counted by 2–4× in buy decisions. Always budget the high-end of the band.\n- \"We'd lose strategic capability\" is sometimes true and sometimes a rationalisation. Test against Step 0's differentiator question.\n- Acquisitions that look cheap on price are expensive on integration. The integration cost is rarely less than the acquisition cost over 18 months.\n\n## Do NOT\n\n- Do NOT compare abstractions; each option must be concrete (named team \u002F vendor \u002F partner).\n- Do NOT skip the inversion step — un-stressed options always look attractive.\n- Do NOT collapse the three options into \"build vs buy\" — partner is a distinct option with distinct optionality.\n\n## Runnable example\n\nSeries-A SaaS, capability gap: real-time data pipeline.\n\n- Step 0 — differentiator (no, every SaaS has one), critical-path (yes). Matrix says buy.\n- Step 1 — Build: 3 eng × 6 mo + 1 FTE ongoing ≈ $1.2M \u002F yr. Buy: Confluent at $180k ARR + 4-week integration. Partner: customer's existing pipeline with 90-day exit — but no incentive alignment with our segment.\n- Step 1.5 — would customers leave if competitor's pipeline was better? Probably not (commodity layer). Vendor-replicable in one quarter? Yes. Confirms buy-bias.\n- Step 2 — Build integration: 6 mo to first value + 3 mo to scale. Buy: 4 weeks to first value, 12 weeks for enterprise-segment readiness ≈ 4 months total. Partner: 2 weeks, but divergence cost unknown.\n- Step 3 — Build fails: team-knowledge walks. Buy fails: Confluent re-prices on usage (mitigation: 2-year contract). Partner fails: partner's roadmap diverges (mitigation: thin exit clause).\n- Step 4 — Build preserves deep integration optionality (foreclosed by buy). Buy preserves capital optionality (foreclosed by build). Partner preserves nothing of consequence.\n- Step 5 — Decide buy. Emit ADR via `adr-create` citing the matrix verdict + integration-cost band + Confluent-specific lock-in mitigation.\n","# build-buy-partner\n\n## When to use\n\n- A capability gap exists and the question is whether to build internally, buy a vendor \u002F acquisition, or partner.\n- An \"obviously build\" choice has crept in by default; the question is whether it survives a deliberate compare.\n- A vendor \u002F partner relationship is up for renewal; the question is whether to keep buying, switch, or insource.\n- An acquisition has been floated; the question is whether the integration cost justifies the speed-to-capability.\n\nDo NOT use for vendor selection within a \"buy\" decision (different skill), market-entry beachhead choice (route to `market-entry-analysis` (P2)), or scenario-shape comparison (route to `scenario-modeling` (O4); P1 consumes O4's bundle).\n\n## Cognition cluster\n\n- **Mental model 28 — Inversion.** *\"What would force us to undo this choice in 18 months?\"* Inversion surfaces the dependency-risk and integration-cost that the forward case understates. See [`mental-models.md`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Fmental-models.md) § 28.\n- **Mental model 21 — Second-order thinking.** Each option chains: build → ongoing maintenance + opportunity cost; buy → integration + lock-in; partner → dependency + boundary management. Single-order *\"build is cheaper\"* fails on the second-order. See `mental-models.md` § 21.\n- **Mental model 26 — Optionality.** Read each option by which choices it preserves (switch costs, re-build optionality, re-negotiation power) vs forecloses. The option with bounded foreclosure usually wins. See `mental-models.md` § 26.\n- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for capacity (pre-seed should buy almost everything non-core; growth-stage can build deeper). Read **product** for whether the capability is core-differentiation (build) or commodity (buy). Read **customer-segment** for whether enterprise-segment buyers require a build-it-yourself story.\n\n## Procedure\n\n### Step 0: Frame the capability as core vs commodity\n\nTwo questions:\n\n1. *Is this capability a differentiator for our customers?* If yes → build-bias. If no → buy-bias.\n2. *Does it sit on the critical path of our product?* If yes + differentiator → build. If yes + commodity → buy. If no → partner.\n\nThe matrix is the starting frame, not the answer. Override is allowed but requires writing the override reason.\n\n### Step 1: Inventory the three options concretely\n\nDo not compare abstractions. Each option = a concrete plan:\n\n1. **Build** — named team, named timeline, named ongoing-maintenance cost. *\"Squad of 3 engineers for 6 months + 1 FTE ongoing\"* not *\"we'd build it\"*.\n2. **Buy** — named vendor (or vendor shortlist), named pricing band, named integration scope. *\"Vendor X at $80k ARR + 4-week integration\"* not *\"we'd find a vendor\"*.\n3. **Partner** — named partner, named scope of dependency, named exit clause. *\"Partner Y owns the X interface with 90-day exit\"* not *\"we'd partner\"*.\n\nUn-named options compare to nothing.\n\n### Step 1.5: Inspect the differentiator claim\n\nBefore locking the matrix from Step 0, inspect the claim that this is\nor isn't a differentiator. Two questions: *\"would a customer leave us\nif a competitor had a better version of this capability?\"* and *\"is\nthe current build advantage replicable by a vendor with one quarter of\nfocused work?\"* Both `yes` answers → the capability is less of a\ndifferentiator than the frame suggested; bias back to buy.\n\n### Step 2: Compute integration cost honestly\n\nIntegration cost is the most under-counted number. For each option:\n\n1. **Build** — engineering time + management overhead + opportunity cost (what's the team *not* building?).\n2. **Buy** — vendor integration (weeks to first value) + ongoing change-management cost + lock-in (cost to switch off).\n3. **Partner** — boundary management + divergence cost (what happens when partner changes their roadmap?).\n\nA buy decision with 2-week integration is rare; industry-typical ranges (public integration benchmarks — not a prediction of your timeline, per `direct-answers` § no duration estimates) run 4–8 weeks for non-trivial integrations and 3–6 months for enterprise-grade ones.\n\n### Step 3: Inversion — name the failure mode for each option\n\nFor each option, write the 18-month failure mode:\n\n1. **Build fails** — *\"team built the wrong thing because requirements shifted under them\"* \u002F *\"team left and knowledge walked\"*.\n2. **Buy fails** — *\"vendor changed pricing 3×\"* \u002F *\"vendor acquired and roadmap diverged\"* \u002F *\"vendor sunset the product line\"*.\n3. **Partner fails** — *\"partner's incentive misaligned\"* \u002F *\"partner's customer became our competitor\"*.\n\nIf one option's failure mode is *\"can't think of one\"*, the analysis is incomplete; sit with it longer.\n\n### Step 4: Read optionality\n\nFor each option:\n\n1. **Preserved options** — what future choices remain (switch vendor, re-build, deepen the build, expand the partnership).\n2. **Foreclosed options** — what future choices are off the table (re-build after 2 years of vendor lock-in; re-vendor after a build commitment; competing against a former partner).\n\nThe decision is rarely about today's cost; it's about which option preserves the choices we'll need in 18 months.\n\n### Step 5: Decide and emit the ADR\n\nPick one. Emit a build-buy-partner ADR via the `adr-create` skill, citing this skill's output. The ADR is the durable record; the artifacts here are the cognition that justify it.\n\n## Related Skills\n\n**WHEN to use this**\n\n- Insource-vs-outsource-vs-acquire decisions on a capability gap.\n- Vendor renewal \u002F re-evaluation where re-building or switching is on the table.\n\n**WHEN NOT to use this**\n\n- Vendor selection within a locked buy decision — different skill (not in this roadmap).\n- Market-entry beachhead choice — route to [`market-entry-analysis`](..\u002Fmarket-entry-analysis\u002FSKILL.md) (P2).\n- Scenario shape comparison — route to [`scenario-modeling`](..\u002Fscenario-modeling\u002FSKILL.md) (O4); P1 consumes O4's `scenario-bundle.md`.\n- Org-shape changes (reorg, team-split) — route to [`org-design`](..\u002Forg-design\u002FSKILL.md) (Q1); P1 composes Q1 for the \"build\" option's team shape.\n- Decision-record authoring mechanics — route to [`adr-create`](..\u002Fadr-create\u002FSKILL.md); P1 emits an ADR via that skill.\n- A generic multi-option choice on custom user-weighted criteria (not build\u002Fbuy\u002Fpartner-shaped) — route to [`decision-record`](..\u002Fdecision-record\u002FSKILL.md) § Weighted-matrix mode; this skill stays the domain-specific instance.\n\n## When the agent should load this\n\n- \"Should we build this or buy a vendor?\"\n- \"Make-vs-buy on capability X.\"\n- \"Should we partner with Y or build in-house?\"\n- \"Renew vendor Z or insource?\"\n- \"Bauen wir das selber oder kaufen?\"\n\n## Output\n\n1. **`build-buy-partner-frame.md`** — capability framing (core \u002F commodity, critical-path \u002F not), three concrete options named, integration-cost table per option.\n2. **`failure-modes.md`** — 18-month inversion per option; named failure paths.\n3. **`optionality-map.md`** — preserved \u002F foreclosed options per choice; recommended option with reasoning.\n4. **ADR** *(via `adr-create`)* — the durable decision record; this skill produces the cognition, `adr-create` produces the file.\n\n## Gotcha\n\n- \"Build\" defaults are the most common silent choice. Engineers' bias is to build; the absence of a buy \u002F partner option in the inventory is the bug, not a feature.\n- Integration cost is under-counted by 2–4× in buy decisions. Always budget the high-end of the band.\n- \"We'd lose strategic capability\" is sometimes true and sometimes a rationalisation. Test against Step 0's differentiator question.\n- Acquisitions that look cheap on price are expensive on integration. The integration cost is rarely less than the acquisition cost over 18 months.\n\n## Do NOT\n\n- Do NOT compare abstractions; each option must be concrete (named team \u002F vendor \u002F partner).\n- Do NOT skip the inversion step — un-stressed options always look attractive.\n- Do NOT collapse the three options into \"build vs buy\" — partner is a distinct option with distinct optionality.\n\n## Runnable example\n\nSeries-A SaaS, capability gap: real-time data pipeline.\n\n- Step 0 — differentiator (no, every SaaS has one), critical-path (yes). Matrix says buy.\n- Step 1 — Build: 3 eng × 6 mo + 1 FTE ongoing ≈ $1.2M \u002F yr. Buy: Confluent at $180k ARR + 4-week integration. Partner: customer's existing pipeline with 90-day exit — but no incentive alignment with our segment.\n- Step 1.5 — would customers leave if competitor's pipeline was better? Probably not (commodity layer). Vendor-replicable in one quarter? Yes. Confirms buy-bias.\n- Step 2 — Build integration: 6 mo to first value + 3 mo to scale. Buy: 4 weeks to first value, 12 weeks for enterprise-segment readiness ≈ 4 months total. Partner: 2 weeks, but divergence cost unknown.\n- Step 3 — Build fails: team-knowledge walks. Buy fails: Confluent re-prices on usage (mitigation: 2-year contract). Partner fails: partner's roadmap diverges (mitigation: thin exit clause).\n- Step 4 — Build preserves deep integration optionality (foreclosed by buy). Buy preserves capital optionality (foreclosed by build). Partner preserves nothing of consequence.\n- Step 5 — Decide buy. Emit ADR via `adr-create` citing the matrix verdict + integration-cost band + Confluent-specific lock-in mitigation.\n",{"name":5,"tier":29,"packs":50,"domain":52,"status":28,"install":53,"model_tier":55,"workspaces":56,"description":7,"context_spine":58},[51],"founder-strategy","process",{"removable":54},true,"inherit",[57],"founder",[59,43,60],"org-stage","customer-segment","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Fbuild-buy-partner",1,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config","https:\u002F\u002Fevent4u.app","https:\u002F\u002Fgithub.com\u002Fevent4u-app","Your events in your hand","2026-11-11 22:25:41",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":54},[72,75,78],{"tool":73,"command":74},"npx","npx skills add event4u-app\u002Fagent-config --skill build-buy-partner",{"tool":76,"command":77},"bunx","bunx skills add event4u-app\u002Fagent-config --skill build-buy-partner",{"tool":79,"command":80},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill build-buy-partner","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fbuild-buy-partner\u002FSKILL.md",[],[84,98,111,123,135,145],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":91,"publishedAt":45},"01M6X84PK96XBPENXH66JCTSD1","unknown-key-fixture","Declares a key the schema does not know.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Funknown-key\u002FSKILL.md",[90],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[92,93,94,95,96,97],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":105,"publishedAt":45},"01M6X84HW7NAHZ7GZMQ9RXK1XJ","portable-fixture","Declares only semantics the MCP-lite carrier transports whole.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fportable\u002FSKILL.md",[104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[94,106,107,108,109,97,110],"portable","portable fixture","engineer","only","MCP",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":45},"01M6X84F29FE0RGGZ1ZTFGZTX2","non-portable-fixture","Declares a runtime semantic the carrier drops.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fnon-portable\u002FSKILL.md",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[107,119,106,94,120,121,122,97],"non portable fixture","semantic","high","runtime",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":45},"01M6X848F706PT9MDCX75JKJ6B","candidate-zero-width","A candidate whose prose carries an invisible joiner.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fzero-width-injection\u002FSKILL.md",[129],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[131,132,133,134],"candidate zero width","candidate","ZeRO","prose",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":45},"01M6X841SSC2T31VDF41SA6DG1","candidate-disclosure-suppression","A candidate whose prose tells the agent to withhold from the user.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdisclosure-suppression\u002FSKILL.md",[141],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[143,132,134,144],"candidate disclosure suppression","user",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":45},"01M6X83TFS5AGPBPVTQNWP0BB3","candidate-dangerous-frontmatter","A candidate claiming an unscoped tool grant and a permission bypass.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdangerous-frontmatter\u002FSKILL.md",[151],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[153,132,154,155,156,157],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]