[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FEBDT1RPF2THAT133XW8C5":3,"skill-same:01M6FEBDT1RPF2THAT133XW8C5":53},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":28,"frontMatter":29,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":35,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M6FEBDT1RPF2THAT133XW8C5","harness-engineering",null,"ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",67,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fpproenca\u002Fdot-skills\u002Fharness-engineering\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25],"harness","engineering","harness engineering","2026-11-10 10:12:30",false,"# Harness: Agent-First Engineering Scaffolding\n\nThe harness is the scaffolding that makes coding agents effective in a repository.\nIt encodes the knowledge, boundaries, and rules that an agent needs to reason\nabout the full business domain directly from the repo itself.\n\nThe philosophy: **agents execute, humans steer**. The engineer's job is not to\nwrite code but to design environments, specify intent, and build feedback loops.\nThe harness is what makes this possible.\n\n## Why It Matters\n\nFrom the agent's point of view, anything it can't access in-context while running\neffectively doesn't exist. Slack discussions, Google Docs, tacit team knowledge —\nall invisible. The harness makes this knowledge legible by encoding it as\nrepository-local, versioned artifacts.\n\nA well-harnessed repo gives agents:\n- A **map** (AGENTS.md) — where to look, not what to memorize\n- **Boundaries** (domain specs) — what can depend on what\n- **Rules** (golden principles) — taste encoded as enforceable invariants\n- **Quality baselines** (scoring) — where the gaps are\n\nWithout this scaffolding, agents replicate whatever patterns they find — including\nbad ones. The harness is what prevents entropy from compounding.\n\n## Harness Maturity Model\n\nThe harness is built incrementally. Each level builds on the previous — don't\ntry to jump from Level 0 to Level 4 in one pass. Assess the current level and\nbuild toward the next.\n\n| Level | Name | What it enables | Key artifacts |\n|-------|------|----------------|---------------|\n| 0 | Unharnessed | Agents guess everything — no map, no rules | Nothing |\n| 1 | Map | Agents know where to look and what the codebase does | AGENTS.md, ARCHITECTURE.md, docs\u002F |\n| 2 | Rules | Agents know what's allowed and what isn't | .harness\u002Fprinciples.yml, enforcement.yml, domains.yml |\n| 3 | Feedback | Agents self-correct via quality signals and process patterns | .harness\u002Fquality.yml, doc-gardening, GC sweeps |\n| 4 | Autonomy | Agents operate independently with defined escalation boundaries | Worktree isolation, escalation rules, agent-to-agent review |\n\nEach level compounds. A repo at Level 2 without Level 1 has rules nobody can\nfind. A repo at Level 3 without Level 2 has quality grades but no way to\nenforce improvement. Build the foundation first.\n\nDuring assessment (Phase 1), determine the current maturity level. During\nplanning (Phase 2), target the next level — not all levels at once. Repeat\nthe harness workflow to climb.\n\n**Critical exception**: for repos where agents are actively writing code\n(agent-first or agent-assisted), architecture boundaries (domain definitions\nand the forward-only dependency rule) should be co-created alongside the\nknowledge layer, not deferred to a separate Level 2 pass. The article is\nexplicit: strict architecture is a day-one prerequisite for agent-driven\ndevelopment, not a scaling concern. Without boundaries, agents produce code\nfaster than entropy can be contained.\n\n## Multi-Turn Workflow\n\nBuilding a harness is interactive. Work through the phases below, presenting\nresults and waiting for user confirmation at each phase boundary. The user may\nwant to skip, reorder, or expand phases — follow their lead.\n\n```\nPhase 1: Assess    → Analyze the repo, report agent readiness\nPhase 2: Plan      → Propose a tailored harness, user confirms\nPhase 3: Knowledge → AGENTS.md, docs\u002F, ARCHITECTURE.md\nPhase 4: Domains   → Identify domains, map layers, generate .harness\u002Fdomains.yml\nPhase 5: Enforce   → Golden principles, rules → .harness\u002Fprinciples.yml, enforcement.yml\nPhase 6: Quality   → Grade domains → .harness\u002Fquality.yml\nPhase 7: Process   → Doc-gardening, GC, review patterns\nPhase 8: Verify    → Cross-check everything, report completeness\n```\n\n### Depth-First Bootstrap\n\nBuild the harness depth-first, not breadth-first. Early harness work is slower\nthan expected — not because the repo is broken, but because the environment is\nunderspecified. Each phase unlocks the next:\n\n- AGENTS.md unlocks docs\u002F (agents know where to put deeper content)\n- docs\u002F unlocks architecture awareness (agents can read domain context)\n- Architecture specs unlock correct domain identification\n- Domain specs unlock meaningful enforcement rules\n- Enforcement rules unlock quality scoring (you can't grade what you can't check)\n\nWhen something fails, the fix is almost never \"try harder.\" Ask: **what\ncapability or context is missing?** Then build that piece first.\n\nFor **updates** to an existing harness, the same phases apply but the assessment\ndiffs against current .harness\u002F specs and only what has drifted gets updated.\n\n## Phase 1: Assess\n\nExamine the repository across every harness layer. The goal is understanding\nwhat exists, what's missing, and what's misaligned — not immediately fixing things.\n\n**What to examine:**\n\n| Area | What to look for |\n|------|-----------------|\n| Structure | Directories, languages, package manifests, monorepo vs single-package |\n| Tech stack | Frameworks, build systems, deployment targets, dependency managers |\n| Agent config | AGENTS.md, CLAUDE.md, .cursor\u002F, .github\u002Fcopilot\u002F, any existing agent instructions |\n| Documentation | README, docs\u002F, architecture docs, ADRs, inline doc comments |\n| Code organization | Domain structure, module boundaries, import patterns, dependency graph |\n| Tests | Frameworks, coverage, CI gates, test organization |\n| Observability | Logging patterns (structured?), metrics, error handling, tracing |\n| Process | PR templates, review workflow, CI\u002FCD configuration |\n| Team config | Agent-first (agents write 90%+ code), agent-assisted (mixed), or agent-ready (preparing for future agent use) |\n| Dependencies | Are external libraries agent-legible? Stable APIs, good docs, training data representation? |\n\nRead `references\u002Fassessment.md` for the detailed checklist and scoring rubric.\n\n**Team configuration shapes the harness**: an agent-first repo needs strong\nenforcement and GC from day one. An agent-assisted repo needs clear boundaries\nbut can rely more on human review. An agent-ready repo mostly needs the\nknowledge layer.\n\n**Output:** An Agent Readiness Report — a structured summary of current state per\nlayer, key findings, and recommended harness components (prioritized).\n\nPresent the report and wait for the user to confirm or adjust before planning.\n\n## Phase 2: Plan\n\nPropose a harness plan tailored to this specific repo. Not every repo needs every\ncomponent — right-size based on the assessment.\n\n**Sizing by maturity level:**\n\n| Current level | Target | What to build |\n|--------------|--------|---------------|\n| 0 → 1 | Map | AGENTS.md, ARCHITECTURE.md, core docs\u002F structure |\n| 1 → 2 | Rules | .harness\u002Fdomains.yml, principles.yml, enforcement.yml |\n| 2 → 3 | Feedback | .harness\u002Fquality.yml, doc-gardening, GC patterns |\n| 3 → 4 | Autonomy | Worktree isolation, escalation boundaries, agent review |\n\nAlso consider repo size — a small repo (\u003C 5k LOC) may only need Level 1–2,\nwhile a large codebase (50k+ LOC) benefits from all four levels.\n\nThe plan should list every artifact to be created or updated, grouped by phase,\nwith a brief note on what each one does. Present it as a checklist the user can\napprove, modify, or trim.\n\nWait for confirmation before implementing.\n\n## Phase 3: Knowledge Layer\n\nBuild the artifacts that give agents a map of the codebase.\n\n### AGENTS.md (~100 lines)\n\nThe single most important file. It is a **routing table**, not an encyclopedia.\n\nIt should contain:\n- 3–5 non-negotiable rules (the ones that cause the most damage when violated)\n- Pointers to deeper docs: `ARCHITECTURE.md`, `docs\u002F`, active plans\n- How to verify work (build\u002Ftest commands)\n- What the repo is and how it's structured (2–3 sentences)\n\nEverything else belongs in `docs\u002F`. If AGENTS.md exceeds ~100 lines, it's too long\nand should be refactored into docs\u002F with pointers.\n\n### docs\u002F Directory\n\n```\ndocs\u002F\n├── design-docs\u002F\n│   ├── index.md              # Catalogue with verification status\n│   └── core-beliefs.md       # Agent-first operating principles\n├── exec-plans\u002F\n│   ├── active\u002F               # In-flight work\n│   ├── completed\u002F            # Done work (context for future agents)\n│   └── tech-debt-tracker.md  # Known debt with priority\n├── generated\u002F                # Auto-generated (DB schema, API specs)\n├── product-specs\u002F\n│   ├── index.md              # Feature catalogue\n│   └── \u003Cfeature>.md\n├── references\u002F               # External docs in agent-friendly format\n├── PRODUCT_SENSE.md          # Product principles, personas, domain sensitivity\n└── \u003CDOMAIN>.md               # Domain guides (only those relevant to the repo)\n```\n\nEvery file in docs\u002F should follow progressive disclosure structure:\n1. **Summary** (2–3 sentences) — enough for an agent to decide if this file is relevant\n2. **Key decisions** — the 3–5 most important things, up front\n3. **Details** — full content for agents that need to go deeper\n4. **Pointers** — links to related docs for further context\n\nThis prevents the \"one big AGENTS.md\" problem from recurring at the file level.\nAgents should be able to read just the summary of each doc and navigate to the\nright one, rather than loading every file into context.\n\nOnly create what the repo actually needs. Each file should contain real content\nderived from the assessment — not boilerplate.\n\n### ARCHITECTURE.md\n\nTop-level domain map answering: what are the domains, how do they relate,\nwhat are the dependency rules, where does new code go.\n\nRead `references\u002Fknowledge-layer.md` for templates and writing guidance.\nRead `references\u002Fcore-beliefs.md` for the core beliefs template and content guide.\n\n## Phase 4: Architecture Layer\n\nDefine domain boundaries and dependency rules as machine-readable specs.\n\n### Domain Identification\n\nA domain is a **vertical slice** — a tracer bullet that cuts through all\nintegration layers end-to-end, from data shapes to user-facing output. It is\nNOT a horizontal technical layer.\n\n**The litmus test**: can you trace a user action from UI through runtime,\nservice, repo, and types — and does that path stay within one coherent business\nconcept? If yes, that's a domain.\n\n```\nCORRECT (vertical slices):        WRONG (horizontal layers):\n┌─────────┐ ┌──────────┐         ┌──────────────────────────┐\n│ Billing  │ │ Onboard  │         │ controllers\u002F             │ ← NOT a domain\n│ ┌─────┐  │ │ ┌─────┐  │         │ models\u002F                  │ ← NOT a domain\n│ │Types│  │ │ │Types│  │         │ services\u002F                │ ← NOT a domain\n│ │Confg│  │ │ │Confg│  │         │ utils\u002F                   │ ← NOT a domain\n│ │Repo │  │ │ │Svc  │  │         └──────────────────────────┘\n│ │Svc  │  │ │ │UI   │  │\n│ │UI   │  │ │ └─────┘  │\n│ └─────┘  │ └──────────┘\n└─────────┘\n```\n\nLook for business concepts, not technical functions:\n- \"billing\", \"onboarding\", \"search\" = domains (vertical, own their full stack)\n- \"controllers\", \"utils\", \"testing\", \"tooling\" = layers or concerns (horizontal)\n\nRead `references\u002Farchitecture-layer.md` for detailed identification heuristics\nand the tracer-bullet test.\n\n### Layer Structure\n\nWithin each domain, code is organized into layers:\n\n```\nTypes → Config → Repo → Service → Runtime → UI\n```\n\n**The key rule: dependencies flow forward only.** A `types` module never imports\nfrom `service`. Cross-cutting concerns (auth, telemetry, feature flags) enter\nthrough a single explicit interface called Providers.\n\nNot every domain has every layer. A CLI tool might only have Types → Config →\nService → Runtime. A library might only have Types → Service. Map what exists.\n\n### Generate .harness\u002Fdomains.yml\n\nCreate the domain specification. Read `references\u002Fyml-schemas.md` for the schema\nand `references\u002Farchitecture-layer.md` for identification heuristics.\n\n## Phase 5: Enforcement Layer\n\nEncode architectural taste as machine-readable rules. The goal: enforce boundaries\ncentrally, allow autonomy locally.\n\n### Golden Principles (.harness\u002Fprinciples.yml)\n\nIdentify 5–10 opinionated rules specific to this repo. Each principle needs:\n- **What**: The rule itself\n- **Why**: Why it matters (what goes wrong without it)\n- **How to check**: lint, structural test, review, or manual inspection\n- **Examples**: Concrete good\u002Fbad code snippets from this codebase\n\nStart with principles from the assessment — patterns that are already causing\nproblems, or invariants that are currently maintained manually but should be\nenforced.\n\n### Mechanical Rules (.harness\u002Fenforcement.yml)\n\nConcrete rules that tooling can check:\n- Naming conventions for files, types, functions\n- File size limits\n- Structured logging requirements\n- Import boundary checks\n- Test coverage expectations\n\n### Agent-Legible Error Messages\n\nThis is one of the highest-leverage patterns in the entire harness. Every\nenforcement rule MUST include a `violation_message` template with four parts:\n1. **What's wrong** — the specific violation\n2. **Why it matters** — rationale linked to a principle\n3. **How to fix it** — concrete remediation steps\n4. **Where to look** — file paths or doc pointers\n\nLint error messages are a delivery mechanism for injecting remediation\ninstructions into an agent's context at the exact moment it needs them. Generic\nmessages (\"boundary violation in X\") are nearly useless. Rich messages\n(\"X imports from Y, violating forward-only rule. Fix: inject via Providers.\nSee: ARCHITECTURE.md#cross-cutting\") let agents self-correct immediately.\n\n### Generate Enforcement Code\n\nThe .harness\u002F*.yml specs describe rules. But specs that nothing checks are\ndocumentation that rots — the same problem the harness is designed to prevent.\n\nFor every enforcement rule, also generate at minimum one concrete artifact:\n- **Lint configuration**: ESLint\u002FRuff\u002FClippy config that enforces naming,\n  imports, or structural rules — with agent-legible error messages\n- **CI workflow**: GitHub Actions \u002F CI job that validates AGENTS.md links,\n  docs\u002F cross-references, or knowledge freshness\n- **Structural test**: A test file that validates architectural invariants\n  (e.g., import direction, domain boundary compliance)\n- **Script**: A validation script that checks file size limits, banned\n  patterns, or naming conventions\n\nEven stub implementations are better than nothing. A lint rule with a TODO\nbody is more valuable than a perfectly documented YAML spec that nothing reads.\n\nRead `references\u002Fenforcement-layer.md` for the principles catalog and patterns.\nRead `references\u002Fyml-schemas.md` for schemas.\n\n## Phase 6: Quality Scoring\n\nGrade each domain across standardized dimensions.\n\n**Dimensions:** code quality, test coverage, documentation, observability,\nreliability, security.\n\n**Scale:** A (exemplary) through F (missing\u002Fbroken).\n\nThe initial scoring is a baseline. Future harness updates compare current state\nagainst these grades to track improvement or detect drift.\n\nGenerate `.harness\u002Fquality.yml` with scores, gap notes, and review dates.\nRead `references\u002Fquality-scoring.md` for the rubric.\n\n## Phase 6.5: Operational Legibility (if applicable)\n\nFor repos with a running application (web app, API, service), assess whether\nagents can observe the app, not just the code. The article's team made the\nrunning application directly legible to agents — this is what enabled 6+ hour\nautonomous agent sessions.\n\n**Assess and recommend:**\n- **Worktree-bootable**: Can the app boot per git worktree so each agent run\n  gets an isolated instance? If not, flag this as a high-priority gap.\n- **Browser automation**: For UI apps — can agents drive the app via Chrome\n  DevTools Protocol (screenshots, DOM snapshots, navigation)?\n- **Observability**: Can agents query logs (LogQL), metrics (PromQL), and\n  traces (TraceQL) from their own instance?\n- **Ephemeral state**: Are logs, metrics, and app state torn down when the\n  agent's task completes?\n\nThis phase is only relevant for repos with runnable applications. Libraries,\nCLI tools, and infrastructure repos can skip it.\n\n## Phase 7: Process Patterns\n\nDocument the patterns that keep a harness-driven codebase healthy over time.\nThese go into the appropriate `docs\u002F` guide files.\n\n- **Doc-gardening**: Recurring scans for stale or incorrect documentation\n- **Garbage collection**: Identifying and cleaning up pattern drift, duplicated\n  helpers, or accumulated \"AI slop\" — this is urgent, not optional. Without\n  automated GC, agent-generated codebases degrade fast enough to consume 20%\n  of engineering time in manual cleanup\n- **Agent review**: At Level 3+ maturity, agent-to-agent review should be the\n  primary quality gate, not a supplement to human review. Humans review for\n  judgment calls only (business logic, product decisions, architectural direction).\n  The progression: L1-2 humans review everything → L3 agents pre-review,\n  humans spot-check → L4 agent-to-agent review, humans only for escalations.\n- **Merge philosophy**: Short-lived PRs, follow-up fixes over indefinite blocking.\n  **Prerequisite**: this is only appropriate when automated enforcement is in place\n  (Level 2+ maturity), test coverage catches regressions, and agents can generate\n  follow-up fixes. Without these, relaxed merge gates are reckless.\n- **Feedback encoding**: How review comments and bugs become doc updates or rules\n- **Escalation boundaries**: Define what decisions require human judgment vs.\n  what agents can resolve autonomously — prevents both over-asking (slow) and\n  under-asking (dangerous)\n\nRead `references\u002Fprocess-patterns.md` for templates.\n\n## Phase 8: Verify\n\nAfter implementation, verify the harness is coherent:\n\n- [ ] Every path referenced in AGENTS.md exists\n- [ ] All cross-links in docs\u002F resolve\n- [ ] .harness\u002F*.yml files have valid structure\n- [ ] domains.yml domains correspond to actual code directories\n- [ ] ARCHITECTURE.md reflects the real module structure\n- [ ] Quality scores have been populated for all identified domains\n- [ ] Knowledge base structure matches knowledge.yml config\n\nReport findings. Fix issues before marking the harness complete.\n\n## Update Flow\n\nWhen updating an existing harness:\n\n1. **Detect drift**: Compare .harness\u002F specs against the actual codebase\n   - New directories\u002Fmodules not in domains.yml\n   - Docs referencing deleted or moved files\n   - Quality scores older than the configured review cadence\n   - Principles being violated in recently added code\n2. **Propose targeted updates**: Don't rebuild — update only what drifted\n3. **Implement changes**: Same phase structure, but scoped to the drift\n4. **Re-verify**: Run the full verification checklist\n\n## .harness\u002F Directory\n\nAll machine-readable harness configuration lives in `.harness\u002F` at the repo root.\n\n```\n.harness\u002F\n├── config.yml         # Harness metadata, version, tech stack summary\n├── domains.yml        # Business domain definitions + layer rules\n├── principles.yml     # Golden principles with rationale + examples\n├── enforcement.yml    # Mechanical rules (naming, limits, logging, imports)\n├── quality.yml        # Per-domain quality grades + gap tracking\n└── knowledge.yml      # Knowledge base structure configuration\n```\n\nSee `references\u002Fyml-schemas.md` for complete schemas with examples.\n\n## Adaptation by Tech Stack\n\nThe harness is tech-agnostic but the implementation adapts:\n\n- **Naming conventions**: camelCase for JS\u002FTS, snake_case for Python\u002FRust\n- **Layer names**: May differ — \"repo\" might be \"repository\" or \"data-access\"\n- **Build commands**: Vary per stack — capture in AGENTS.md\n- **Dependency enforcement**: Import style differs between module systems\n- **Logging**: Different structured logging libraries per ecosystem\n\nIdentify the stack during assessment and adapt all templates accordingly.\nDon't force conventions from one ecosystem onto another.\n",{},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Fpproenca\u002Fdot-skills\u002Fharness-engineering",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":7,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill harness-engineering",{"tool":45,"command":46},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill harness-engineering",{"tool":48,"command":49},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill harness-engineering","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fpproenca\u002Fdot-skills\u002Fharness-engineering\u002FSKILL.md",true,[],[54,64,74,83,89,96],{"skillNo":55,"name":56,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":60,"publishedAt":26},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[59],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[61,62,63],"model","model hierarchy","model hierarchy skill",{"skillNo":65,"name":66,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":70,"publishedAt":26},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[69],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[71,72,73],"MCP","zoom","zoom mcp",{"skillNo":75,"name":76,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":26},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[80,81,82,72],"sdk","zoom apps sdk","apps",{"skillNo":84,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":26},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[85],{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":95,"publishedAt":26},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[94],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[91],{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":26},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[98]]