[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69APS2RQFC34SYZED5K2MHD":3,"skill-same:01M69APS2RQFC34SYZED5K2MHD":61},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":42,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M69APS2RQFC34SYZED5K2MHD","docs-sync",null,"Keep user-facing docs current and DESIGN aligned with architectural changes.","microsoft\u002Fwebui","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69APCAY31B400ERZA9BVA20",102,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fdocs-sync\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31],"docs","sync","docs sync","design","user","keep","with","changes","2026-11-10 10:12:30",false,"---\nname: docs-sync\ndescription: Keep user-facing docs current and DESIGN aligned with architectural changes.\n---\n\n# Docs Synchronization Workflow\n\nUse this skill whenever a change touches user-visible behavior, APIs, or contracts.\n\n## When to update docs\n\n| What changed | Update |\n|-------------|--------|\n| CLI flags or commands | `docs\u002Freference\u002Fcli\u002Findex.md` + `docs\u002Fai.md` (Build and run section) |\n| Template syntax or directives | `docs\u002Flearn\u002Fdirectives\u002F` + `docs\u002Fai.md` |\n| Component authoring model | `docs\u002Flearn\u002Finteractivity.md` + `docs\u002Fai.md` |\n| Hydration markers or mechanism | `specs\u002Fhydration.md` + producer\u002Fconsumer tests; update `docs\u002Fbuild\u002Fhydration.md` if user-visible, `DESIGN.md` only if hydration architecture changes |\n| Routing behavior | `docs\u002Fbuild\u002Frouting.md` + `docs\u002Fai.md` |\n| State management or path resolution | `docs\u002Flearn\u002Fstate-management\u002Findex.md` |\n| Handler API (Rust, Node, FFI) | `docs\u002Fbuild\u002Fintegrations\u002F` |\n| Protocol fields or fragment types | `crates\u002Fwebui-protocol\u002Fproto\u002Fwebui.proto` + consumers\u002Ftests; `DESIGN.md` only if the graph or ownership model changes |\n| Internal subsystem or cross-language contract | Relevant `specs\u002F` reference + producer\u002Fconsumer tests; `DESIGN.md` only if the architecture changes |\n| Plugin system (parser or handler) | `docs\u002Freference\u002Fplugins\u002Findex.md`; `DESIGN.md` if plugin responsibilities change |\n| Performance characteristics | `docs\u002Fbuild\u002Fperformance.md` |\n| Public API (Rust crate, npm package) | Relevant handler\u002Fintegration docs; `DESIGN.md` only if an architectural boundary changes |\n| Error variants or error messages | Defining source\u002Ftests and relevant public troubleshooting docs; `DESIGN.md` only if error-handling architecture changes |\n| `@microsoft\u002Fwebui-framework` decorators or API | `docs\u002Flearn\u002Finteractivity.md` + `docs\u002Fai.md` + `packages\u002Fwebui-framework\u002FREADME.md` |\n| `@microsoft\u002Fwebui-delivery` behavior | `docs\u002Fbuild\u002Frouting.md` + `packages\u002Fwebui-delivery\u002FREADME.md` |\n\n## DESIGN.md rules\n\n`DESIGN.md` is the living, technology-independent architecture for rebuilding\nWebUI. Update it in the same change only when modifying:\n\n- Subsystem responsibilities and data flow\n- Build-time versus request-time ownership\n- Cross-layer design invariants and compatibility boundaries\n- Technology choices essential to reproducing the system\n\nRevise existing explanations instead of appending incident histories. Exact\nschemas, signatures, error codes, SSR marker layouts, metadata tuples, and\nregression details belong in the defining source and tests; preserve focused\nsubsystem and cross-language contracts in internal `specs\u002F` references. A\nfield or API change alone is not an architectural change. If an architectural\nclaim and the code disagree, reconcile them.\n\n## docs\u002F rules\n\nUpdate `docs\u002F` in the same commit when the change is user-visible:\n\n- CLI usage or flags changed\n- Template syntax or rendering output changed\n- Integration behavior that external developers depend on\n- New features or removed features\n\n### Public API boundary\n\nDeveloper documentation (`docs\u002F`, crate\u002Fpackage READMEs, and\n`docs\u002Fai.md`) documents only supported public APIs and externally\nobservable contracts. Every addition must map to at least one public entry\npoint:\n\n- an exported Rust, Node, WASM, FFI, or package API;\n- a CLI command, flag, configuration field, or supported identifier;\n- supported template\u002Fcomponent authoring syntax;\n- a documented protocol or integration contract.\n\nDo not document private or `pub(crate)` items, internal callbacks, intermediate\nrepresentations, cache algorithms, implementation sequencing, regression-test\ndetails, or dependency-specific workarounds in developer docs. Put system-level\narchitecture in `DESIGN.md`, subsystem technical contracts in `specs\u002F`,\nand implementation invariants and local rationale near code and tests.\n\nRust `\u002F\u002F\u002F` documentation comments are for exported public APIs only. Use `\u002F\u002F`\nsparingly for non-public implementation rationale. Before finishing, audit the\ndocumentation diff against the public exports and remove text that has no public\nentry point.\n\nDo not update user-facing docs for internal implementation details, regression\ntests, refactors, or bug fixes that only restore already-documented behavior.\nEvery addition must help developers author, configure, debug, or integrate a\nWebUI application. Do not add release-note-style implementation observations\nto reference docs.\n\nKeep protocol internals out of general user docs. The `docs\u002Fai.md` file is the single-page AI reference and should be kept in sync with all other docs.\n\n`docs\u002Fai.md` is authoring-first by design. Keep deep reference material (full CLI flag tables, error-code lists, per-language integration snippets) in its canonical page and link to it from `docs\u002Fai.md` rather than duplicating it there.\n\n`ai\u002FSKILL.md` is only the stable loader. Update `docs\u002Fai.md` for authoring changes,\nnot the loader or the generated `packages\u002Fwebui\u002Fai.md`. The package prepack step\nrefreshes the generated reference; ordinary builds do not write it.\n\n## Validation\n\n```bash\ncd docs && pnpm build\n```\n\nThis catches broken links, VitePress syntax errors (unescaped `{{` outside code blocks), and missing pages. Run it when docs are changed.\n\n## Style rules for docs\n\n- No emdashes (` - `). Use hyphens (` - `).\n- Escape `{{` outside fenced code blocks with `\u003Ccode v-pre>{{expr}}\u003C\u002Fcode>`.\n- Use correct CLI flag names (check `crates\u002Fwebui-cli\u002Fsrc\u002Fcommands\u002F`).\n- Verify SSR markers match source code (`crates\u002Fwebui-handler\u002Fsrc\u002Fplugin\u002Fwebui.rs`).\n","# Docs Synchronization Workflow\n\nUse this skill whenever a change touches user-visible behavior, APIs, or contracts.\n\n## When to update docs\n\n| What changed | Update |\n|-------------|--------|\n| CLI flags or commands | `docs\u002Freference\u002Fcli\u002Findex.md` + `docs\u002Fai.md` (Build and run section) |\n| Template syntax or directives | `docs\u002Flearn\u002Fdirectives\u002F` + `docs\u002Fai.md` |\n| Component authoring model | `docs\u002Flearn\u002Finteractivity.md` + `docs\u002Fai.md` |\n| Hydration markers or mechanism | `specs\u002Fhydration.md` + producer\u002Fconsumer tests; update `docs\u002Fbuild\u002Fhydration.md` if user-visible, `DESIGN.md` only if hydration architecture changes |\n| Routing behavior | `docs\u002Fbuild\u002Frouting.md` + `docs\u002Fai.md` |\n| State management or path resolution | `docs\u002Flearn\u002Fstate-management\u002Findex.md` |\n| Handler API (Rust, Node, FFI) | `docs\u002Fbuild\u002Fintegrations\u002F` |\n| Protocol fields or fragment types | `crates\u002Fwebui-protocol\u002Fproto\u002Fwebui.proto` + consumers\u002Ftests; `DESIGN.md` only if the graph or ownership model changes |\n| Internal subsystem or cross-language contract | Relevant `specs\u002F` reference + producer\u002Fconsumer tests; `DESIGN.md` only if the architecture changes |\n| Plugin system (parser or handler) | `docs\u002Freference\u002Fplugins\u002Findex.md`; `DESIGN.md` if plugin responsibilities change |\n| Performance characteristics | `docs\u002Fbuild\u002Fperformance.md` |\n| Public API (Rust crate, npm package) | Relevant handler\u002Fintegration docs; `DESIGN.md` only if an architectural boundary changes |\n| Error variants or error messages | Defining source\u002Ftests and relevant public troubleshooting docs; `DESIGN.md` only if error-handling architecture changes |\n| `@microsoft\u002Fwebui-framework` decorators or API | `docs\u002Flearn\u002Finteractivity.md` + `docs\u002Fai.md` + `packages\u002Fwebui-framework\u002FREADME.md` |\n| `@microsoft\u002Fwebui-delivery` behavior | `docs\u002Fbuild\u002Frouting.md` + `packages\u002Fwebui-delivery\u002FREADME.md` |\n\n## DESIGN.md rules\n\n`DESIGN.md` is the living, technology-independent architecture for rebuilding\nWebUI. Update it in the same change only when modifying:\n\n- Subsystem responsibilities and data flow\n- Build-time versus request-time ownership\n- Cross-layer design invariants and compatibility boundaries\n- Technology choices essential to reproducing the system\n\nRevise existing explanations instead of appending incident histories. Exact\nschemas, signatures, error codes, SSR marker layouts, metadata tuples, and\nregression details belong in the defining source and tests; preserve focused\nsubsystem and cross-language contracts in internal `specs\u002F` references. A\nfield or API change alone is not an architectural change. If an architectural\nclaim and the code disagree, reconcile them.\n\n## docs\u002F rules\n\nUpdate `docs\u002F` in the same commit when the change is user-visible:\n\n- CLI usage or flags changed\n- Template syntax or rendering output changed\n- Integration behavior that external developers depend on\n- New features or removed features\n\n### Public API boundary\n\nDeveloper documentation (`docs\u002F`, crate\u002Fpackage READMEs, and\n`docs\u002Fai.md`) documents only supported public APIs and externally\nobservable contracts. Every addition must map to at least one public entry\npoint:\n\n- an exported Rust, Node, WASM, FFI, or package API;\n- a CLI command, flag, configuration field, or supported identifier;\n- supported template\u002Fcomponent authoring syntax;\n- a documented protocol or integration contract.\n\nDo not document private or `pub(crate)` items, internal callbacks, intermediate\nrepresentations, cache algorithms, implementation sequencing, regression-test\ndetails, or dependency-specific workarounds in developer docs. Put system-level\narchitecture in `DESIGN.md`, subsystem technical contracts in `specs\u002F`,\nand implementation invariants and local rationale near code and tests.\n\nRust `\u002F\u002F\u002F` documentation comments are for exported public APIs only. Use `\u002F\u002F`\nsparingly for non-public implementation rationale. Before finishing, audit the\ndocumentation diff against the public exports and remove text that has no public\nentry point.\n\nDo not update user-facing docs for internal implementation details, regression\ntests, refactors, or bug fixes that only restore already-documented behavior.\nEvery addition must help developers author, configure, debug, or integrate a\nWebUI application. Do not add release-note-style implementation observations\nto reference docs.\n\nKeep protocol internals out of general user docs. The `docs\u002Fai.md` file is the single-page AI reference and should be kept in sync with all other docs.\n\n`docs\u002Fai.md` is authoring-first by design. Keep deep reference material (full CLI flag tables, error-code lists, per-language integration snippets) in its canonical page and link to it from `docs\u002Fai.md` rather than duplicating it there.\n\n`ai\u002FSKILL.md` is only the stable loader. Update `docs\u002Fai.md` for authoring changes,\nnot the loader or the generated `packages\u002Fwebui\u002Fai.md`. The package prepack step\nrefreshes the generated reference; ordinary builds do not write it.\n\n## Validation\n\n```bash\ncd docs && pnpm build\n```\n\nThis catches broken links, VitePress syntax errors (unescaped `{{` outside code blocks), and missing pages. Run it when docs are changed.\n\n## Style rules for docs\n\n- No emdashes (` - `). Use hyphens (` - `).\n- Escape `{{` outside fenced code blocks with `\u003Ccode v-pre>{{expr}}\u003C\u002Fcode>`.\n- Use correct CLI flag names (check `crates\u002Fwebui-cli\u002Fsrc\u002Fcommands\u002F`).\n- Verify SSR markers match source code (`crates\u002Fwebui-handler\u002Fsrc\u002Fplugin\u002Fwebui.rs`).\n",{"name":5,"description":7},"main","ce33e738b770d63c0e4144feb5072212d38ce1b9",".github\u002Fskills\u002Fdocs-sync",25,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui","https:\u002F\u002Fmicrosoft.github.io\u002Fwebui\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 12:45:48",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add microsoft\u002Fwebui --skill docs-sync",{"tool":53,"command":54},"bunx","bunx skills add microsoft\u002Fwebui --skill docs-sync",{"tool":56,"command":57},"pnpm","pnpm dlx skills add microsoft\u002Fwebui --skill docs-sync","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fdocs-sync\u002FSKILL.md",true,[],[62,82,100,119,135,148],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":32},"01M69AQ6PSR5AXD1W7K822EJEJ","webui-reference","Use when writing or reviewing WebUI application or framework code. Load the application's installed reference or the WebUI source checkout's canonical reference.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002Fai\u002FSKILL.md",[],[69,70,71,72,73,74,75,76,77,78,79,80,81],"webui reference","webui","reference","writing","checkout","canonical","use","load","source","code","application","framework","when",{"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":88,"publishedAt":32},"01M69AQ4B9AXF52SB3A0NVW4QT","webui-dev","Build interactive WebUI apps with compiled-template hydration, template syntax, component patterns, and CLI usage.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwebui-dev\u002FSKILL.md",[],[89,70,90,91,92,93,94,95,30,96,97,98,99],"dev","webui dev","component","cli","usage","apps","interactive","build","template","syntax","patterns",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"publishedAt":32},"01M69AQ21S81FTXJF5716X3JPB","testing","Test patterns, fixture structure, and when to use E2E vs unit tests.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftesting\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[102,110,81,99,111,112,113,75,114,115,116,117,118],"structure","when to use","test patterns","fixture","test","unit tests","unit","tests","e2e",{"skillNo":120,"name":121,"nameZh":6,"description":122,"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":32},"01M69APZVHA8B3AM0S1WJ1T5BC","quality-gate","Run before every commit or push: formatting, linting, tests, dependency audits, builds, and docs.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fquality-gate\u002FSKILL.md",[],[126,127,128,24,129,130,131,132,133,117,134],"quality","gate","quality gate","commit","push","linting","dependency","run","formatting",{"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":141,"publishedAt":32},"01M69APXXGESWZ75E8B5PKWC8H","pr","Guidance for branch naming, commit messages, and PR titles.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr\u002FSKILL.md",[],[137,142,129,143,144,145,146,147],"guidance","branch","for","messages","naming","commit messages",{"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":154,"publishedAt":32},"01M69APVKEAZD650TFNCT9WMN1","perf","Speed and memory performance rules for Rust crates, the Node addon, webui-framework, and webui-delivery.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwebui\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fperf\u002FSKILL.md",[],[150,155,156,157,144,70,158,159,160,161,80],"memory","performance","rust","delivery","node","speed","Rules"]