[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JRSVRZ2F9VRYPG550PH3B":3,"skill-same:01M71JRSVRZ2F9VRYPG550PH3B":165},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":5,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M71JRSVRZ2F9VRYPG550PH3B","vue-best-practices",null,"MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","caezium\u002Fskills","caezium","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113233555?v=4","01M71JB77ZPBAWEK009Y2W8BP7","Henry Zhang","01M71JB792NVXCWSYD27HQ0964",3,"MIT","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"vue","best practices","vue best practices","standard","load","use","vite","for","as","typescript","ssr","options","work","pinia","router","api","tasks","files","project","Composition","2026-11-10 10:12:30",false,"---\nname: vue-best-practices\ndescription: MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.\nlicense: MIT\nmetadata:\n  author: github.com\u002Fvuejs-ai\n  version: \"18.0.0\"\n---\n\n# Vue Best Practices Workflow\n\nUse this skill as an instruction set. Follow the workflow in order unless the user explicitly asks for a different order.\n\n## Core Principles\n- **Keep state predictable:** one source of truth, derive everything else.\n- **Make data flow explicit:** Props down, Events up for most cases.\n- **Favor small, focused components:** easier to test, reuse, and maintain.\n- **Avoid unnecessary re-renders:** use computed properties and watchers wisely.\n- **Readability counts:** write clear, self-documenting code.\n\n## 1) Confirm architecture before coding (required)\n\n- Default stack: Vue 3 + Composition API + `\u003Cscript setup lang=\"ts\">`.\n- If the project explicitly uses Options API, load `vue-options-api-best-practices` skill if available.\n- If the project explicitly uses JSX, load `vue-jsx-best-practices` skill if available.\n\n### 1.1 Must-read core references (required)\n\n- Before implementing any Vue task, make sure to read and apply these core references:\n  - `references\u002Freactivity.md`\n  - `references\u002Fsfc.md`\n  - `references\u002Fcomponent-data-flow.md`\n  - `references\u002Fcomposables.md`\n- Keep these references in active working context for the entire task, not only when a specific issue appears.\n\n### 1.2 Plan component boundaries before coding (required)\n\nCreate a brief component map before implementation for any non-trivial feature.\n\n- Define each component's single responsibility in one sentence.\n- Keep entry\u002Froot and route-level view components as composition surfaces by default.\n- Move feature UI and feature logic out of entry\u002Froot\u002Fview components unless the task is intentionally a tiny single-file demo.\n- Define props\u002Femits contracts for each child component in the map.\n- Prefer a feature folder layout (`components\u002F\u003Cfeature>\u002F...`, `composables\u002Fuse\u003CFeature>.ts`) when adding more than one component.\n\n## 2) Apply essential Vue foundations (required)\n\nThese are essential, must-know foundations. Apply all of them in every Vue task using the core references already loaded in section `1.1`.\n\n### Reactivity\n\n- Must-read reference from `1.1`: [reactivity](references\u002Freactivity.md)\n- Keep source state minimal (`ref`\u002F`reactive`), derive everything possible with `computed`.\n- Use watchers for side effects if needed.\n- Avoid recomputing expensive logic in templates.\n\n### SFC structure and template safety\n\n- Must-read reference from `1.1`: [sfc](references\u002Fsfc.md)\n- Keep SFC sections in this order: `\u003Cscript>` → `\u003Ctemplate>` → `\u003Cstyle>`.\n- Keep SFC responsibilities focused; split large components.\n- Keep templates declarative; move branching\u002Fderivation to script.\n- Apply Vue template safety rules (`v-html`, list rendering, conditional rendering choices).\n\n### Keep components focused\n\nSplit a component when it has **more than one clear responsibility** (e.g. data orchestration + UI, or multiple independent UI sections).\n\n- Prefer **smaller components + composables** over one “mega component”\n- Move **UI sections** into child components (props in, events out).\n- Move **state\u002Fside effects** into composables (`useXxx()`).\n\nApply objective split triggers. Split the component if **any** condition is true:\n\n- It owns both orchestration\u002Fstate and substantial presentational markup for multiple sections.\n- It has 3+ distinct UI sections (for example: form, filters, list, footer\u002Fstatus).\n- A template block is repeated or could become reusable (item rows, cards, list entries).\n\nEntry\u002Froot and route view rule:\n\n- Keep entry\u002Froot and route view components thin: app shell\u002Flayout, provider wiring, and feature composition.\n- Do not place full feature implementations in entry\u002Froot\u002Fview components when those features contain independent parts.\n- For CRUD\u002Flist features (todo, table, catalog, inbox), split at least into:\n  - feature container component\n  - input\u002Fform component\n  - list (and\u002For item) component\n  - footer\u002Factions or filter\u002Fstatus component\n- Allow a single-file implementation only for very small throwaway demos; if chosen, explicitly justify why splitting is unnecessary.\n\n### Component data flow\n\n- Must-read reference from `1.1`: [component-data-flow](references\u002Fcomponent-data-flow.md)\n- Use props down, events up as the primary model.\n- Use `v-model` only for true two-way component contracts.\n- Use provide\u002Finject only for deep-tree dependencies or shared context.\n- Keep contracts explicit and typed with `defineProps`, `defineEmits`, and `InjectionKey` as needed.\n\n### Composables\n\n- Must-read reference from `1.1`: [composables](references\u002Fcomposables.md)\n- Extract logic into composables when it is reused, stateful, or side-effect heavy.\n- Keep composable APIs small, typed, and predictable.\n- Separate feature logic from presentational components.\n\n## 3) Consider optional features only when requirements call for them\n\n### 3.1 Standard optional features\n\nDo not add these by default. Load the matching reference only when the requirement exists.\n\n- Slots: parent needs to control child content\u002Flayout -> [component-slots](references\u002Fcomponent-slots.md)\n- Fallthrough attributes: wrapper\u002Fbase components must forward attrs\u002Fevents safely -> [component-fallthrough-attrs](references\u002Fcomponent-fallthrough-attrs.md)\n- Built-in component `\u003CKeepAlive>` for stateful view caching -> [component-keep-alive](references\u002Fcomponent-keep-alive.md)\n- Built-in component `\u003CTeleport>` for overlays\u002Fportals -> [component-teleport](references\u002Fcomponent-teleport.md)\n- Built-in component `\u003CSuspense>` for async subtree fallback boundaries -> [component-suspense](references\u002Fcomponent-suspense.md)\n- Animation-related features: pick the simplest approach that matches the required motion behavior.\n  - Built-in component `\u003CTransition>` for enter\u002Fleave effects -> [transition](references\u002Fcomponent-transition.md)\n  - Built-in component `\u003CTransitionGroup>` for animated list mutations -> [transition-group](references\u002Fcomponent-transition-group.md)\n  - Class-based animation for non-enter\u002Fleave effects -> [animation-class-based-technique](references\u002Fanimation-class-based-technique.md)\n  - State-driven animation for user-input-driven animation -> [animation-state-driven-technique](references\u002Fanimation-state-driven-technique.md)\n\n### 3.2 Less-common optional features\n\nUse these only when there is explicit product or technical need.\n\n- Directives: behavior is DOM-specific and not a good composable\u002Fcomponent fit -> [directives](references\u002Fdirectives.md)\n- Async components: heavy\u002Frarely-used UI should be lazy loaded -> [component-async](references\u002Fcomponent-async.md)\n- Render functions only when templates cannot express the requirement -> [render-functions](references\u002Frender-functions.md)\n- Plugins when behavior must be installed app-wide -> [plugins](references\u002Fplugins.md)\n- State management patterns: app-wide shared state crosses feature boundaries -> [state-management](references\u002Fstate-management.md)\n\n## 4) Run performance optimization after behavior is correct\n\nPerformance work is a post-functionality pass. Do not optimize before core behavior is implemented and verified.\n\n- Large list rendering bottlenecks -> [perf-virtualize-large-lists](references\u002Fperf-virtualize-large-lists.md)\n- Static subtrees re-rendering unnecessarily -> [perf-v-once-v-memo-directives](references\u002Fperf-v-once-v-memo-directives.md)\n- Over-abstraction in hot list paths -> [perf-avoid-component-abstraction-in-lists](references\u002Fperf-avoid-component-abstraction-in-lists.md)\n- Expensive updates triggered too often -> [updated-hook-performance](references\u002Fupdated-hook-performance.md)\n\n## 5) Final self-check before finishing\n\n- Core behavior works and matches requirements.\n- All must-read references were read and applied.\n- Reactivity model is minimal and predictable.\n- SFC structure and template rules are followed.\n- Components are focused and well-factored, splitting when needed.\n- Entry\u002Froot and route view components remain composition surfaces unless there is an explicit small-demo exception.\n- Component split decisions are explicit and defensible (responsibility boundaries are clear).\n- Data flow contracts are explicit and typed.\n- Composables are used where reuse\u002Fcomplexity justifies them.\n- Moved state\u002Fside effects into composables if applicable\n- Optional features are used only when requirements demand them.\n- Performance changes were applied only after functionality was complete.\n","# Vue Best Practices Workflow\n\nUse this skill as an instruction set. Follow the workflow in order unless the user explicitly asks for a different order.\n\n## Core Principles\n- **Keep state predictable:** one source of truth, derive everything else.\n- **Make data flow explicit:** Props down, Events up for most cases.\n- **Favor small, focused components:** easier to test, reuse, and maintain.\n- **Avoid unnecessary re-renders:** use computed properties and watchers wisely.\n- **Readability counts:** write clear, self-documenting code.\n\n## 1) Confirm architecture before coding (required)\n\n- Default stack: Vue 3 + Composition API + `\u003Cscript setup lang=\"ts\">`.\n- If the project explicitly uses Options API, load `vue-options-api-best-practices` skill if available.\n- If the project explicitly uses JSX, load `vue-jsx-best-practices` skill if available.\n\n### 1.1 Must-read core references (required)\n\n- Before implementing any Vue task, make sure to read and apply these core references:\n  - `references\u002Freactivity.md`\n  - `references\u002Fsfc.md`\n  - `references\u002Fcomponent-data-flow.md`\n  - `references\u002Fcomposables.md`\n- Keep these references in active working context for the entire task, not only when a specific issue appears.\n\n### 1.2 Plan component boundaries before coding (required)\n\nCreate a brief component map before implementation for any non-trivial feature.\n\n- Define each component's single responsibility in one sentence.\n- Keep entry\u002Froot and route-level view components as composition surfaces by default.\n- Move feature UI and feature logic out of entry\u002Froot\u002Fview components unless the task is intentionally a tiny single-file demo.\n- Define props\u002Femits contracts for each child component in the map.\n- Prefer a feature folder layout (`components\u002F\u003Cfeature>\u002F...`, `composables\u002Fuse\u003CFeature>.ts`) when adding more than one component.\n\n## 2) Apply essential Vue foundations (required)\n\nThese are essential, must-know foundations. Apply all of them in every Vue task using the core references already loaded in section `1.1`.\n\n### Reactivity\n\n- Must-read reference from `1.1`: [reactivity](references\u002Freactivity.md)\n- Keep source state minimal (`ref`\u002F`reactive`), derive everything possible with `computed`.\n- Use watchers for side effects if needed.\n- Avoid recomputing expensive logic in templates.\n\n### SFC structure and template safety\n\n- Must-read reference from `1.1`: [sfc](references\u002Fsfc.md)\n- Keep SFC sections in this order: `\u003Cscript>` → `\u003Ctemplate>` → `\u003Cstyle>`.\n- Keep SFC responsibilities focused; split large components.\n- Keep templates declarative; move branching\u002Fderivation to script.\n- Apply Vue template safety rules (`v-html`, list rendering, conditional rendering choices).\n\n### Keep components focused\n\nSplit a component when it has **more than one clear responsibility** (e.g. data orchestration + UI, or multiple independent UI sections).\n\n- Prefer **smaller components + composables** over one “mega component”\n- Move **UI sections** into child components (props in, events out).\n- Move **state\u002Fside effects** into composables (`useXxx()`).\n\nApply objective split triggers. Split the component if **any** condition is true:\n\n- It owns both orchestration\u002Fstate and substantial presentational markup for multiple sections.\n- It has 3+ distinct UI sections (for example: form, filters, list, footer\u002Fstatus).\n- A template block is repeated or could become reusable (item rows, cards, list entries).\n\nEntry\u002Froot and route view rule:\n\n- Keep entry\u002Froot and route view components thin: app shell\u002Flayout, provider wiring, and feature composition.\n- Do not place full feature implementations in entry\u002Froot\u002Fview components when those features contain independent parts.\n- For CRUD\u002Flist features (todo, table, catalog, inbox), split at least into:\n  - feature container component\n  - input\u002Fform component\n  - list (and\u002For item) component\n  - footer\u002Factions or filter\u002Fstatus component\n- Allow a single-file implementation only for very small throwaway demos; if chosen, explicitly justify why splitting is unnecessary.\n\n### Component data flow\n\n- Must-read reference from `1.1`: [component-data-flow](references\u002Fcomponent-data-flow.md)\n- Use props down, events up as the primary model.\n- Use `v-model` only for true two-way component contracts.\n- Use provide\u002Finject only for deep-tree dependencies or shared context.\n- Keep contracts explicit and typed with `defineProps`, `defineEmits`, and `InjectionKey` as needed.\n\n### Composables\n\n- Must-read reference from `1.1`: [composables](references\u002Fcomposables.md)\n- Extract logic into composables when it is reused, stateful, or side-effect heavy.\n- Keep composable APIs small, typed, and predictable.\n- Separate feature logic from presentational components.\n\n## 3) Consider optional features only when requirements call for them\n\n### 3.1 Standard optional features\n\nDo not add these by default. Load the matching reference only when the requirement exists.\n\n- Slots: parent needs to control child content\u002Flayout -> [component-slots](references\u002Fcomponent-slots.md)\n- Fallthrough attributes: wrapper\u002Fbase components must forward attrs\u002Fevents safely -> [component-fallthrough-attrs](references\u002Fcomponent-fallthrough-attrs.md)\n- Built-in component `\u003CKeepAlive>` for stateful view caching -> [component-keep-alive](references\u002Fcomponent-keep-alive.md)\n- Built-in component `\u003CTeleport>` for overlays\u002Fportals -> [component-teleport](references\u002Fcomponent-teleport.md)\n- Built-in component `\u003CSuspense>` for async subtree fallback boundaries -> [component-suspense](references\u002Fcomponent-suspense.md)\n- Animation-related features: pick the simplest approach that matches the required motion behavior.\n  - Built-in component `\u003CTransition>` for enter\u002Fleave effects -> [transition](references\u002Fcomponent-transition.md)\n  - Built-in component `\u003CTransitionGroup>` for animated list mutations -> [transition-group](references\u002Fcomponent-transition-group.md)\n  - Class-based animation for non-enter\u002Fleave effects -> [animation-class-based-technique](references\u002Fanimation-class-based-technique.md)\n  - State-driven animation for user-input-driven animation -> [animation-state-driven-technique](references\u002Fanimation-state-driven-technique.md)\n\n### 3.2 Less-common optional features\n\nUse these only when there is explicit product or technical need.\n\n- Directives: behavior is DOM-specific and not a good composable\u002Fcomponent fit -> [directives](references\u002Fdirectives.md)\n- Async components: heavy\u002Frarely-used UI should be lazy loaded -> [component-async](references\u002Fcomponent-async.md)\n- Render functions only when templates cannot express the requirement -> [render-functions](references\u002Frender-functions.md)\n- Plugins when behavior must be installed app-wide -> [plugins](references\u002Fplugins.md)\n- State management patterns: app-wide shared state crosses feature boundaries -> [state-management](references\u002Fstate-management.md)\n\n## 4) Run performance optimization after behavior is correct\n\nPerformance work is a post-functionality pass. Do not optimize before core behavior is implemented and verified.\n\n- Large list rendering bottlenecks -> [perf-virtualize-large-lists](references\u002Fperf-virtualize-large-lists.md)\n- Static subtrees re-rendering unnecessarily -> [perf-v-once-v-memo-directives](references\u002Fperf-v-once-v-memo-directives.md)\n- Over-abstraction in hot list paths -> [perf-avoid-component-abstraction-in-lists](references\u002Fperf-avoid-component-abstraction-in-lists.md)\n- Expensive updates triggered too often -> [updated-hook-performance](references\u002Fupdated-hook-performance.md)\n\n## 5) Final self-check before finishing\n\n- Core behavior works and matches requirements.\n- All must-read references were read and applied.\n- Reactivity model is minimal and predictable.\n- SFC structure and template rules are followed.\n- Components are focused and well-factored, splitting when needed.\n- Entry\u002Froot and route view components remain composition surfaces unless there is an explicit small-demo exception.\n- Component split decisions are explicit and defensible (responsibility boundaries are clear).\n- Data flow contracts are explicit and typed.\n- Composables are used where reuse\u002Fcomplexity justifies them.\n- Moved state\u002Fside effects into composables if applicable\n- Optional features are used only when requirements demand them.\n- Performance changes were applied only after functionality was complete.\n",{"name":5,"license":15,"metadata":49,"description":7},{"author":50,"version":51},"github.com\u002Fvuejs-ai","18.0.0","main","6ef866230c1ba3459fd08fc65141dfd37fffd41a",0,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills","https:\u002F\u002Fskills.henryzh.dev","https:\u002F\u002Fgithub.com\u002Fcaezium","henryzh.dev","quant, data science, full-stack, robotics.\r\nbuilding cool stuff","2026-08-24 19:21:44",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add caezium\u002Fskills --skill vue-best-practices",{"tool":67,"command":68},"bunx","bunx skills add caezium\u002Fskills --skill vue-best-practices",{"tool":70,"command":71},"pnpm","pnpm dlx skills add caezium\u002Fskills --skill vue-best-practices","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002FSKILL.md",true,[75,81,85,89,93,97,101,105,109,113,117,121,125,129,133,137,141,145,149,153,157,161],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fanimation-class-based-technique.md","REFERENCE","参考文档",5026,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fanimation-class-based-technique.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fanimation-state-driven-technique.md",5829,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fanimation-state-driven-technique.md",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fcomponent-async.md",2532,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-async.md",{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fcomponent-data-flow.md",6956,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-data-flow.md",{"path":94,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fcomponent-fallthrough-attrs.md",4047,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-fallthrough-attrs.md",{"path":98,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fcomponent-keep-alive.md",3487,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-keep-alive.md",{"path":102,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fcomponent-slots.md",4469,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-slots.md",{"path":106,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fcomponent-suspense.md",5367,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-suspense.md",{"path":110,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fcomponent-teleport.md",2921,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-teleport.md",{"path":114,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fcomponent-transition-group.md",3004,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-transition-group.md",{"path":118,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Fcomponent-transition.md",2722,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomponent-transition.md",{"path":122,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fcomposables.md",7011,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fcomposables.md",{"path":126,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":127,"sourceHtmlUrl":128},"references\u002Fdirectives.md",3803,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fdirectives.md",{"path":130,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":131,"sourceHtmlUrl":132},"references\u002Fperf-avoid-component-abstraction-in-lists.md",4683,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fperf-avoid-component-abstraction-in-lists.md",{"path":134,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":135,"sourceHtmlUrl":136},"references\u002Fperf-v-once-v-memo-directives.md",4769,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fperf-v-once-v-memo-directives.md",{"path":138,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":139,"sourceHtmlUrl":140},"references\u002Fperf-virtualize-large-lists.md",5002,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fperf-virtualize-large-lists.md",{"path":142,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":143,"sourceHtmlUrl":144},"references\u002Fplugins.md",3882,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fplugins.md",{"path":146,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":147,"sourceHtmlUrl":148},"references\u002Freactivity.md",8452,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Freactivity.md",{"path":150,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":151,"sourceHtmlUrl":152},"references\u002Frender-functions.md",3866,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Frender-functions.md",{"path":154,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":155,"sourceHtmlUrl":156},"references\u002Fsfc.md",6216,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fsfc.md",{"path":158,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":159,"sourceHtmlUrl":160},"references\u002Fstate-management.md",3380,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fstate-management.md",{"path":162,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":163,"sourceHtmlUrl":164},"references\u002Fupdated-hook-performance.md",4618,"https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fvue-best-practices\u002Freferences\u002Fupdated-hook-performance.md",[166,186,212,230,251,272],{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":180,"publishedAt":44},"01M71JT4RYCAS18RF6003YYR1D","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwriting-for-agents\u002FSKILL.md",[172,175],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[181,31,182,183,29,184,185],"writing for agents","writing","editing","documents","when",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":195,"publishedAt":44},"01M71JT0GES4AZ5ADH8EADNN1Z","wrangler","Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwrangler\u002FSKILL.md",[192],{"categoryNo":193,"categoryName":194,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[188,196,197,198,199,200,201,202,203,204,205,206,207,31,208,209,28,210,25,211],"cloudflare","d1","knowledge","workflows","cli","secrets","commands","syntax","cloudflare workers","r2","queues","running","containers","correct","workers","store",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":218,"publishedAt":44},"01M71JSWX4R203M32K9A18AAW8","workers-best-practices","Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fworkers-best-practices\u002FSKILL.md",[],[219,210,25,220,221,222,31,196,223,198,224,188,182,28,185,225,226,227,228,229],"workers best practices","observability","reviews","promises","worker","new","code","common","streaming","state","anti-patterns",{"skillNo":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":236,"publishedAt":44},"01M71JST6P88MXGT2MWDTPJGEG","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwizard\u002FSKILL.md",[],[232,207,237,31,238,239,240,241,29,242,185,243,244,245,246,247,248,249,250,201],"setting","up","ci","provisioning infrastructure","only","invoke","Bash","one","interactive","can","credentials","dashboard","generate","human",{"skillNo":252,"name":253,"nameZh":6,"description":254,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":255,"sourceHtmlUrl":256,"categories":257,"keywords":258,"publishedAt":44},"01M71JSQ95S7BQ61DAPN95X2W4","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available evidence sources, searches each relevant category, and returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwhy\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fwhy\u002FSKILL.md",[],[253,259,260,261,262,31,263,264,29,265,36,266,267,268,269,270,271],"sources","thresholds","evidence","relevant","runtime","design","decisions","how","behavior","read","data","rationale","returns",{"skillNo":273,"name":274,"nameZh":6,"description":275,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":276,"categories":277,"keywords":281,"publishedAt":44},"01M71JSMHFVSH8HK8GXN6YAX6J","week-prep","Generate a briefing with calendar, tasks, and attention flags. Use for \"week prep\", \"briefing\", or \"what's on this week\".","https:\u002F\u002Fgithub.com\u002Fcaezium\u002Fskills\u002Fblob\u002Fmain\u002Fweek-prep\u002FSKILL.md",[278],{"categoryNo":279,"categoryName":280,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[282,283,284,285,286,31,287,288,289,290,29,243,40,291,292,249,293,268,294,295],"week prep","prep","deep","attention","get","search","messages","briefing","MCP","with","slack","calendar","flags","grep"]