[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6F4Q9QJSCCQJSP01053G34Y":3,"skill-same:01M6F4Q9QJSCCQJSP01053G34Y":73},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6F4Q9QJSCCQJSP01053G34Y","gtm-developer-ecosystem",null,"Build and scale developer-led adoption through ecosystem programs. Use when deciding open vs curated ecosystems, building developer programs, scaling platform adoption, or designing student program pipelines.","ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",66,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fgithub\u002Fawesome-copilot\u002Fgtm-developer-ecosystem\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"ecosystem","developer","gtm","gtm developer ecosystem","use","scale","platform","scaling","ecosystems","build","pipelines","github","technical","linkedin","open","adoption","https","product","2026-11-10 10:12:30",false,"---\nname: gtm-developer-ecosystem\ndescription: Build and scale developer-led adoption through ecosystem programs. Use when deciding open vs curated ecosystems, building developer programs, scaling platform adoption, or designing student program pipelines.\nlicense: MIT\nmetadata:\n  author: Smit Patel (https:\u002F\u002Flinkedin.com\u002Fin\u002Fsmitkpatel)\n  source: https:\u002F\u002Fgithub.com\u002Fbeingsmit\u002Ftechnical-product-gtm\n---\n\n# Developer Ecosystem\n\nBuild and scale developer-led adoption through ecosystem programs, community, and partnerships. Focus on what actually drives adoption, not vanity metrics.\n\n## When to Use\n\n**Triggers:**\n- \"How do we build a developer ecosystem?\"\n- \"Should we curate quality or go open?\"\n- \"Developer community isn't growing\"\n- \"Nobody's building on our API\"\n- \"How do we compete with larger platforms?\"\n\n**Context:**\n- API platforms and developer tools\n- Products with extensibility (plugins, integrations)\n- Developer-first GTM motion\n- Platform business models\n\n---\n\n## Core Frameworks\n\n### 1. Open vs Curated Ecosystem (The Marketplace Decision)\n\n**The Pattern:**\n\nRunning ecosystem at a developer platform. Leadership debate: Open the marketplace to anyone, or curate for quality?\n\n**Quality control camp:** \"We need gatekeeping. Otherwise we'll get SEO spam, low-quality integrations, brand damage.\"\n\n**Open camp:** \"Developers route around gatekeepers. Network effects matter more than quality control.\"\n\n**The decision:** Went open. Quality concerns were real, but we made a bet: control comes from discovery and trust layers, not submission gatekeeping.\n\n**What We Built Instead of Gatekeeping:**\n\n1. **Search and discovery** — Surface high-quality integrations through algorithms, not human curation\n2. **Trust signals** — Verified badges, usage stats, health scores\n3. **Community curation** — User ratings, collections, recommendations\n4. **Moderation** — Remove spam after publication, not block before\n\n**Result:** Network effects won. Thousands of integrations published. Quality surfaced through usage, not through us deciding upfront.\n\n**Decision Framework:**\n- **Curated** works when: Brand risk high, dozens of partners, can scale human review\n- **Open** works when: Hundreds\u002Fthousands of potential partners, network effects matter more than quality control\n\n**Common Mistake:**\n\nDefaulting to curated because \"we need quality control.\" This works when you have 10 partners. At 100+, you become the bottleneck. Build discovery and trust systems instead.\n\n---\n\n### 2. The Three-Year Student Program Arc\n\n**The Pattern:**\n\nMost developer programs optimize for quick wins. Better approach: Build long-term talent pipeline.\n\n**Year 1: University Partnerships**\n- Partner with CS departments\n- Curriculum integration (hackathons, coursework)\n- Student licenses (free or heavily discounted)\n- Metrics: # universities, # students activated\n\n**Year 2: Student Community & Certification**\n- Student expert certification program\n- Student-led workshops and events\n- Campus ambassadors\n- Metrics: # certified, # student-led events\n\n**Year 3: Career Bridge**\n- Job board connecting students → companies\n- Enterprise partnerships (hire certified students)\n- Alumni network\n- Metrics: # hired, company partnerships\n\n**Why This Works:**\n\nStudents become enterprise buyers 5-10 years later. You're building brand loyalty before they have purchasing power.\n\n**Common Mistake:**\n\nTreating students as immediate revenue. They're not. They're future enterprise decision-makers.\n\n---\n\n### 3. Developer Journey (Awareness → Integration → Advocacy)\n\n**Stage 1: Awareness**\n- How do they discover you?\n- Content, search, word-of-mouth, events\n\n**Stage 2: Onboarding**\n- First API call in \u003C10 minutes\n- Quick-start guides\n- Sample code in popular languages\n\n**Stage 3: Integration**\n- Building real use cases\n- Integration guides\n- Support when stuck\n\n**Stage 4: Production**\n- Deployed and generating value\n- Monitoring usage\n- Enterprise upgrade path\n\n**Stage 5: Advocacy**\n- Sharing publicly\n- Recommending to others\n- Contributing back (docs, code, community)\n\n**Metrics That Matter:**\n- Time to first API call (onboarding)\n- % reaching production (integration success)\n- Monthly active developers (engagement)\n- Developer NPS (advocacy)\n\n**Common Mistake:**\n\nMeasuring vanity metrics (sign-ups, downloads) instead of real engagement (API calls, production deployments).\n\n---\n\n### 4. Documentation Hierarchy\n\n**Tier 1: Quick Starts (Get to Value Fast)**\n- \"Hello World\" in 5 minutes\n- Common use case examples\n- Copy-paste code that works\n\n**Tier 2: Guides (Solve Real Problems)**\n- Use case-specific tutorials\n- Integration patterns\n- Best practices\n\n**Tier 3: Reference (Complete API Docs)**\n- Every endpoint documented\n- Request\u002Fresponse examples\n- Error codes and handling\n\n**Tier 4: Conceptual (Understand the System)**\n- Architecture overviews\n- Design philosophy\n- Advanced patterns\n\n**Most developers need:** Tier 1 first, then Tier 2. Very few read Tier 4.\n\n**Common Mistake:**\n\nStarting with Tier 3 (comprehensive API reference). Developers want quick wins first.\n\n---\n\n### 5. Community vs Support (When to Use Which)\n\n**Community (Async, Scalable):**\n- Slack\u002FDiscord for real-time help\n- Forum for searchable Q&A\n- GitHub discussions for feature requests\n- Best for: Common questions, peer-to-peer help\n\n**Support (Sync, Expensive):**\n- Email support for enterprise\n- Dedicated Slack channels for partners\n- Video calls for complex integrations\n- Best for: Paying customers, strategic partners\n\n**How to Route:**\n\n**Community first:**\n- Developer asks question\n- Community member answers\n- You validate and upvote\n- Searchable for future developers\n\n**Escalate to support when:**\n- No community answer in 24 hours\n- Enterprise\u002Fpaying customer\n- Security or compliance issue\n- Complex integration requiring custom work\n\n**Common Mistake:**\n\nProviding white-glove support to everyone. Doesn't scale. Build community that helps itself.\n\n---\n\n### 6. Partner Tiering for Developer Ecosystems\n\n**Tier 1: Integration Partners (Self-Serve)**\n- Build with public API\n- You provide: docs, Slack channel, office hours\n- They drive their own marketing\n- Best for: Ambitious partners with resources\n\n**Tier 2: Strategic Partners (Co-Development)**\n- Co-developed integration\n- You provide: dedicated channel, co-marketing\n- Joint case studies\n- Best for: High-impact integrations\n\n**Don't over-tier.** 2 tiers is enough. More creates confusion.\n\n---\n\n## Decision Trees\n\n### Open or Curated Ecosystem?\n\n```\nIs brand damage risk high if low-quality partners join?\n├─ Yes (regulated, security) → Curated\n└─ No → Continue...\n    │\n    Can you scale human review?\n    ├─ No (hundreds\u002Fthousands) → Open + discovery systems\n    └─ Yes (dozens) → Curated\n```\n\n### Community or Support?\n\n```\nIs this a common question?\n├─ Yes → Community (forum, Slack, docs)\n└─ No → Continue...\n    │\n    Is requester paying customer?\n    ├─ Yes → Support (email, dedicated)\n    └─ No → Community (with escalation path)\n```\n\n---\n\n## Common Mistakes\n\n**1. Building ecosystem before product-market fit**\n   - Fix core product first, then build ecosystem\n\n**2. No developer success team**\n   - Developers need help to succeed beyond docs\n\n**3. Poor documentation**\n   - Foundation of ecosystem, non-negotiable\n\n**4. Treating all developers equally**\n   - Tier support by strategic value (paying > free, partners > hobbyists)\n\n**5. No integration quality standards**\n   - Low-quality integrations hurt your brand\n\n**6. Measuring only vanity metrics**\n   - Track activation and production usage, not just sign-ups\n\n**7. Developer advocates with no technical depth**\n   - Hire developers who can code and teach\n\n---\n\n## Quick Reference\n\n**Open ecosystem checklist:**\n- [ ] Search and discovery (surface quality algorithmically)\n- [ ] Trust signals (verified badges, usage stats, ratings)\n- [ ] Community curation (user recommendations, collections)\n- [ ] Moderation (remove spam after publication)\n\n**Developer journey metrics:**\n- Awareness: Traffic, sign-ups\n- Onboarding: Time to first API call (\u003C10 min target)\n- Integration: % reaching production deployment\n- Advocacy: Developer NPS, public sharing\n\n**Documentation hierarchy:**\n1. Quick starts (5-min \"Hello World\")\n2. Use case guides (solve real problems)\n3. API reference (complete documentation)\n4. Conceptual (architecture, philosophy)\n\n**Partner tiers:**\n- Tier 1: Self-serve (public API, docs, community)\n- Tier 2: Strategic (co-development, co-marketing)\n\n**Student program timeline:**\n- Year 1: University partnerships, activation\n- Year 2: Certification, student community\n- Year 3: Job board, enterprise hiring bridge\n\n---\n\n## Related Skills\n\n- **partnership-architecture**: Partner deal structures and co-marketing\n- **product-led-growth**: Self-serve activation funnels for developer products\n- **0-to-1-launch**: Launching developer products\n\n---\n\n*Based on building developer ecosystems at multiple platform companies, including the open vs curated marketplace decision, student program development (3-year arc building talent pipeline), and partner ecosystem growth. Not theory — patterns from building developer ecosystems that actually drove platform adoption and multi-year brand loyalty.*\n\n","# Developer Ecosystem\n\nBuild and scale developer-led adoption through ecosystem programs, community, and partnerships. Focus on what actually drives adoption, not vanity metrics.\n\n## When to Use\n\n**Triggers:**\n- \"How do we build a developer ecosystem?\"\n- \"Should we curate quality or go open?\"\n- \"Developer community isn't growing\"\n- \"Nobody's building on our API\"\n- \"How do we compete with larger platforms?\"\n\n**Context:**\n- API platforms and developer tools\n- Products with extensibility (plugins, integrations)\n- Developer-first GTM motion\n- Platform business models\n\n---\n\n## Core Frameworks\n\n### 1. Open vs Curated Ecosystem (The Marketplace Decision)\n\n**The Pattern:**\n\nRunning ecosystem at a developer platform. Leadership debate: Open the marketplace to anyone, or curate for quality?\n\n**Quality control camp:** \"We need gatekeeping. Otherwise we'll get SEO spam, low-quality integrations, brand damage.\"\n\n**Open camp:** \"Developers route around gatekeepers. Network effects matter more than quality control.\"\n\n**The decision:** Went open. Quality concerns were real, but we made a bet: control comes from discovery and trust layers, not submission gatekeeping.\n\n**What We Built Instead of Gatekeeping:**\n\n1. **Search and discovery** — Surface high-quality integrations through algorithms, not human curation\n2. **Trust signals** — Verified badges, usage stats, health scores\n3. **Community curation** — User ratings, collections, recommendations\n4. **Moderation** — Remove spam after publication, not block before\n\n**Result:** Network effects won. Thousands of integrations published. Quality surfaced through usage, not through us deciding upfront.\n\n**Decision Framework:**\n- **Curated** works when: Brand risk high, dozens of partners, can scale human review\n- **Open** works when: Hundreds\u002Fthousands of potential partners, network effects matter more than quality control\n\n**Common Mistake:**\n\nDefaulting to curated because \"we need quality control.\" This works when you have 10 partners. At 100+, you become the bottleneck. Build discovery and trust systems instead.\n\n---\n\n### 2. The Three-Year Student Program Arc\n\n**The Pattern:**\n\nMost developer programs optimize for quick wins. Better approach: Build long-term talent pipeline.\n\n**Year 1: University Partnerships**\n- Partner with CS departments\n- Curriculum integration (hackathons, coursework)\n- Student licenses (free or heavily discounted)\n- Metrics: # universities, # students activated\n\n**Year 2: Student Community & Certification**\n- Student expert certification program\n- Student-led workshops and events\n- Campus ambassadors\n- Metrics: # certified, # student-led events\n\n**Year 3: Career Bridge**\n- Job board connecting students → companies\n- Enterprise partnerships (hire certified students)\n- Alumni network\n- Metrics: # hired, company partnerships\n\n**Why This Works:**\n\nStudents become enterprise buyers 5-10 years later. You're building brand loyalty before they have purchasing power.\n\n**Common Mistake:**\n\nTreating students as immediate revenue. They're not. They're future enterprise decision-makers.\n\n---\n\n### 3. Developer Journey (Awareness → Integration → Advocacy)\n\n**Stage 1: Awareness**\n- How do they discover you?\n- Content, search, word-of-mouth, events\n\n**Stage 2: Onboarding**\n- First API call in \u003C10 minutes\n- Quick-start guides\n- Sample code in popular languages\n\n**Stage 3: Integration**\n- Building real use cases\n- Integration guides\n- Support when stuck\n\n**Stage 4: Production**\n- Deployed and generating value\n- Monitoring usage\n- Enterprise upgrade path\n\n**Stage 5: Advocacy**\n- Sharing publicly\n- Recommending to others\n- Contributing back (docs, code, community)\n\n**Metrics That Matter:**\n- Time to first API call (onboarding)\n- % reaching production (integration success)\n- Monthly active developers (engagement)\n- Developer NPS (advocacy)\n\n**Common Mistake:**\n\nMeasuring vanity metrics (sign-ups, downloads) instead of real engagement (API calls, production deployments).\n\n---\n\n### 4. Documentation Hierarchy\n\n**Tier 1: Quick Starts (Get to Value Fast)**\n- \"Hello World\" in 5 minutes\n- Common use case examples\n- Copy-paste code that works\n\n**Tier 2: Guides (Solve Real Problems)**\n- Use case-specific tutorials\n- Integration patterns\n- Best practices\n\n**Tier 3: Reference (Complete API Docs)**\n- Every endpoint documented\n- Request\u002Fresponse examples\n- Error codes and handling\n\n**Tier 4: Conceptual (Understand the System)**\n- Architecture overviews\n- Design philosophy\n- Advanced patterns\n\n**Most developers need:** Tier 1 first, then Tier 2. Very few read Tier 4.\n\n**Common Mistake:**\n\nStarting with Tier 3 (comprehensive API reference). Developers want quick wins first.\n\n---\n\n### 5. Community vs Support (When to Use Which)\n\n**Community (Async, Scalable):**\n- Slack\u002FDiscord for real-time help\n- Forum for searchable Q&A\n- GitHub discussions for feature requests\n- Best for: Common questions, peer-to-peer help\n\n**Support (Sync, Expensive):**\n- Email support for enterprise\n- Dedicated Slack channels for partners\n- Video calls for complex integrations\n- Best for: Paying customers, strategic partners\n\n**How to Route:**\n\n**Community first:**\n- Developer asks question\n- Community member answers\n- You validate and upvote\n- Searchable for future developers\n\n**Escalate to support when:**\n- No community answer in 24 hours\n- Enterprise\u002Fpaying customer\n- Security or compliance issue\n- Complex integration requiring custom work\n\n**Common Mistake:**\n\nProviding white-glove support to everyone. Doesn't scale. Build community that helps itself.\n\n---\n\n### 6. Partner Tiering for Developer Ecosystems\n\n**Tier 1: Integration Partners (Self-Serve)**\n- Build with public API\n- You provide: docs, Slack channel, office hours\n- They drive their own marketing\n- Best for: Ambitious partners with resources\n\n**Tier 2: Strategic Partners (Co-Development)**\n- Co-developed integration\n- You provide: dedicated channel, co-marketing\n- Joint case studies\n- Best for: High-impact integrations\n\n**Don't over-tier.** 2 tiers is enough. More creates confusion.\n\n---\n\n## Decision Trees\n\n### Open or Curated Ecosystem?\n\n```\nIs brand damage risk high if low-quality partners join?\n├─ Yes (regulated, security) → Curated\n└─ No → Continue...\n    │\n    Can you scale human review?\n    ├─ No (hundreds\u002Fthousands) → Open + discovery systems\n    └─ Yes (dozens) → Curated\n```\n\n### Community or Support?\n\n```\nIs this a common question?\n├─ Yes → Community (forum, Slack, docs)\n└─ No → Continue...\n    │\n    Is requester paying customer?\n    ├─ Yes → Support (email, dedicated)\n    └─ No → Community (with escalation path)\n```\n\n---\n\n## Common Mistakes\n\n**1. Building ecosystem before product-market fit**\n   - Fix core product first, then build ecosystem\n\n**2. No developer success team**\n   - Developers need help to succeed beyond docs\n\n**3. Poor documentation**\n   - Foundation of ecosystem, non-negotiable\n\n**4. Treating all developers equally**\n   - Tier support by strategic value (paying > free, partners > hobbyists)\n\n**5. No integration quality standards**\n   - Low-quality integrations hurt your brand\n\n**6. Measuring only vanity metrics**\n   - Track activation and production usage, not just sign-ups\n\n**7. Developer advocates with no technical depth**\n   - Hire developers who can code and teach\n\n---\n\n## Quick Reference\n\n**Open ecosystem checklist:**\n- [ ] Search and discovery (surface quality algorithmically)\n- [ ] Trust signals (verified badges, usage stats, ratings)\n- [ ] Community curation (user recommendations, collections)\n- [ ] Moderation (remove spam after publication)\n\n**Developer journey metrics:**\n- Awareness: Traffic, sign-ups\n- Onboarding: Time to first API call (\u003C10 min target)\n- Integration: % reaching production deployment\n- Advocacy: Developer NPS, public sharing\n\n**Documentation hierarchy:**\n1. Quick starts (5-min \"Hello World\")\n2. Use case guides (solve real problems)\n3. API reference (complete documentation)\n4. Conceptual (architecture, philosophy)\n\n**Partner tiers:**\n- Tier 1: Self-serve (public API, docs, community)\n- Tier 2: Strategic (co-development, co-marketing)\n\n**Student program timeline:**\n- Year 1: University partnerships, activation\n- Year 2: Certification, student community\n- Year 3: Job board, enterprise hiring bridge\n\n---\n\n## Related Skills\n\n- **partnership-architecture**: Partner deal structures and co-marketing\n- **product-led-growth**: Self-serve activation funnels for developer products\n- **0-to-1-launch**: Launching developer products\n\n---\n\n*Based on building developer ecosystems at multiple platform companies, including the open vs curated marketplace decision, student program development (3-year arc building talent pipeline), and partner ecosystem growth. Not theory — patterns from building developer ecosystems that actually drove platform adoption and multi-year brand loyalty.*\n\n",{"name":5,"license":15,"metadata":47,"description":7},{"author":48,"source":49},"Smit Patel (https:\u002F\u002Flinkedin.com\u002Fin\u002Fsmitkpatel)","https:\u002F\u002Fgithub.com\u002Fbeingsmit\u002Ftechnical-product-gtm","main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Fgithub\u002Fawesome-copilot\u002Fgtm-developer-ecosystem",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill gtm-developer-ecosystem",{"tool":65,"command":66},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill gtm-developer-ecosystem",{"tool":68,"command":69},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill gtm-developer-ecosystem","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fgithub\u002Fawesome-copilot\u002Fgtm-developer-ecosystem\u002FSKILL.md",true,[],[74,88,98,107,113,120],{"skillNo":75,"name":76,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":42},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87],"model","model hierarchy","model hierarchy skill",{"skillNo":89,"name":90,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":94,"publishedAt":42},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[93],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[95,96,97],"MCP","zoom","zoom mcp",{"skillNo":99,"name":100,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":42},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[104,105,106,96],"sdk","zoom apps sdk","apps",{"skillNo":108,"name":109,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":42},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[109],{"skillNo":114,"name":115,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":42},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[118],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[115],{"skillNo":121,"name":122,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":42},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[122]]