{"id":"969e5de5-8c7b-4c7c-8d9c-c27400312d95","shortId":"HazANQ","kind":"skill","title":"vue-best-practices","tagline":"MUST be used for Vue.js tasks. Strongly recommends Composition API with `<script 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 proje","description":"# 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 + `<script 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/reactivity.md`\n  - `references/sfc.md`\n  - `references/component-data-flow.md`\n  - `references/composables.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/root and route-level view components as composition surfaces by default.\n- Move feature UI and feature logic out of entry/root/view components unless the task is intentionally a tiny single-file demo.\n- Define props/emits contracts for each child component in the map.\n- Prefer a feature folder layout (`components/<feature>/...`, `composables/use<Feature>.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/reactivity.md)\n- Keep source state minimal (`ref`/`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/sfc.md)\n- Keep SFC sections in this order: `<script>` → `<template>` → `<style>`.\n- Keep SFC responsibilities focused; split large components.\n- Keep templates declarative; move branching/derivation 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/side effects** into composables (`useXxx()`).\n\nApply objective split triggers. Split the component if **any** condition is true:\n\n- It owns both orchestration/state and substantial presentational markup for multiple sections.\n- It has 3+ distinct UI sections (for example: form, filters, list, footer/status).\n- A template block is repeated or could become reusable (item rows, cards, list entries).\n\nEntry/root and route view rule:\n\n- Keep entry/root and route view components thin: app shell/layout, provider wiring, and feature composition.\n- Do not place full feature implementations in entry/root/view components when those features contain independent parts.\n- For CRUD/list features (todo, table, catalog, inbox), split at least into:\n  - feature container component\n  - input/form component\n  - list (and/or item) component\n  - footer/actions or filter/status 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/component-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/inject 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/composables.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/layout -> [component-slots](references/component-slots.md)\n- Fallthrough attributes: wrapper/base components must forward attrs/events safely -> [component-fallthrough-attrs](references/component-fallthrough-attrs.md)\n- Built-in component `<KeepAlive>` for stateful view caching -> [component-keep-alive](references/component-keep-alive.md)\n- Built-in component `<Teleport>` for overlays/portals -> [component-teleport](references/component-teleport.md)\n- Built-in component `<Suspense>` for async subtree fallback boundaries -> [component-suspense](references/component-suspense.md)\n- Animation-related features: pick the simplest approach that matches the required motion behavior.\n  - Built-in component `<Transition>` for enter/leave effects -> [transition](references/component-transition.md)\n  - Built-in component `<TransitionGroup>` for animated list mutations -> [transition-group](references/component-transition-group.md)\n  - Class-based animation for non-enter/leave effects -> [animation-class-based-technique](references/animation-class-based-technique.md)\n  - State-driven animation for user-input-driven animation -> [animation-state-driven-technique](references/animation-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/component fit -> [directives](references/directives.md)\n- Async components: heavy/rarely-used UI should be lazy loaded -> [component-async](references/component-async.md)\n- Render functions only when templates cannot express the requirement -> [render-functions](references/render-functions.md)\n- Plugins when behavior must be installed app-wide -> [plugins](references/plugins.md)\n- State management patterns: app-wide shared state crosses feature boundaries -> [state-management](references/state-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/perf-virtualize-large-lists.md)\n- Static subtrees re-rendering unnecessarily -> [perf-v-once-v-memo-directives](references/perf-v-once-v-memo-directives.md)\n- Over-abstraction in hot list paths -> [perf-avoid-component-abstraction-in-lists](references/perf-avoid-component-abstraction-in-lists.md)\n- Expensive updates triggered too often -> [updated-hook-performance](references/updated-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/root 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/complexity justifies them.\n- Moved state/side 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.","tags":["vue","best","practices","skills","antfu","agent-skills"],"capabilities":["skill","source-antfu","skill-vue-best-practices","topic-agent-skills","topic-skills"],"categories":["skills"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/antfu/skills/vue-best-practices","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add antfu/skills","source_repo":"https://github.com/antfu/skills","install_from":"skills.sh"}},"qualityScore":"0.700","qualityRationale":"deterministic score 0.70 from registry signals: · indexed on github topic:agent-skills · 4670 github stars · SKILL.md body (8,358 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-04-22T06:52:50.869Z","embedding":null,"createdAt":"2026-04-18T21:53:53.761Z","updatedAt":"2026-04-22T06:52:50.869Z","lastSeenAt":"2026-04-22T06:52:50.869Z","tsv":"'api':14 'best':3 'composit':13 'must':5 'practic':4 'recommend':12 'skill' 'skill-vue-best-practices' 'source-antfu' 'strong':11 'task':10 'topic-agent-skills' 'topic-skills' 'use':7 'vue':2 'vue-best-practic':1 'vue.js':9","prices":[{"id":"0e17cb0a-884e-48e8-93d4-9ac1204979f2","listingId":"969e5de5-8c7b-4c7c-8d9c-c27400312d95","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"antfu","category":"skills","install_from":"skills.sh"},"createdAt":"2026-04-18T21:53:53.761Z"}],"sources":[{"listingId":"969e5de5-8c7b-4c7c-8d9c-c27400312d95","source":"github","sourceId":"antfu/skills/vue-best-practices","sourceUrl":"https://github.com/antfu/skills/tree/main/skills/vue-best-practices","isPrimary":false,"firstSeenAt":"2026-04-18T21:53:53.761Z","lastSeenAt":"2026-04-22T06:52:50.869Z"}],"details":{"listingId":"969e5de5-8c7b-4c7c-8d9c-c27400312d95","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"antfu","slug":"vue-best-practices","github":{"repo":"antfu/skills","stars":4670,"topics":["agent-skills","skills"],"license":"mit","html_url":"https://github.com/antfu/skills","pushed_at":"2026-03-16T06:16:24Z","description":"Anthony Fu's curated collection of agent skills.","skill_md_sha":"feacd704fc48310744f8f8791e318343ea8ab1cb","skill_md_path":"skills/vue-best-practices/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/antfu/skills/tree/main/skills/vue-best-practices"},"layout":"multi","source":"github","category":"skills","frontmatter":{"name":"vue-best-practices","license":"MIT","description":"MUST be used for Vue.js tasks. Strongly recommends Composition API with `<script 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."},"skills_sh_url":"https://skills.sh/antfu/skills/vue-best-practices"},"updatedAt":"2026-04-22T06:52:50.869Z"}}