vue-best-practices

Vue d’ensemble de la skill vue-best-practices

À quoi sert vue-best-practices

vue-best-practices est une skill d’instructions centrée sur Vue, pensée pour la génération de code, la revue et le refactoring dans des projets Vue 3. Son rôle ne se limite pas à « écrire du code Vue » : il s’agit surtout de produire du code Vue selon des choix d’architecture actuels, capables de rester maintenables sous de vraies contraintes projet. En pratique, elle oriente l’agent vers la Composition API, <script setup lang="ts">, un flux de données explicite et des décisions propres à l’écosystème Vue que des prompts frontend génériques ratent souvent.

Qui devrait installer vue-best-practices

Cette skill convient particulièrement aux équipes et aux développeurs solo qui travaillent sur Vue 3, des composants monofichier .vue, Vue Router, des patterns d’état de type Pinia, des applications basées sur Vite et des apps Vue compatibles SSR. Elle est particulièrement utile si vous voulez qu’un assistant IA cesse de dériver vers des patterns JavaScript génériques et suive à la place des conventions vraiment natives à Vue.

Le vrai besoin métier couvert

La vraie valeur de vue-best-practices, c’est de réduire les erreurs de conception évitables avant même de commencer à coder. La skill demande explicitement à l’agent de valider l’architecture d’abord, puis de garder quelques références clés dans son contexte actif : réactivité, structure SFC, flux de données des composants et composables. Elle devient ainsi bien plus utile pour prendre de bonnes décisions d’implémentation qu’un simple prompt du type « construis ce composant ».

Ce qui distingue cette skill

Son point fort, c’est sa logique de décision. La skill ne se contente pas de dire « utilisez Vue 3 ». Elle pose des valeurs par défaut et des limites claires :

• partir par défaut sur Composition API avec <script setup lang="ts">
• basculer vers une autre skill si le projet est explicitement en Options API ou en JSX
• traiter props, emits, v-model, provide/inject, composants asynchrones, transitions et performance comme de vrais sujets de conception
• s’appuyer sur une documentation de référence ciblée pour les cas limites au lieu de se fier à la mémoire

Quand vue-best-practices est particulièrement adapté

Utilisez vue-best-practices for Frontend Development lorsque vous avez besoin d’aide pour :

• créer ou refactorer des composants Vue
• choisir entre props/emits, v-model, provide/inject ou un store
• concevoir des composables
• faire des choix de composants asynchrones compatibles SSR
• définir des API de slots, gérer les fallthrough attrs, les transitions, KeepAlive et la performance des listes
• vérifier si une implémentation Vue est idiomatique, et pas seulement fonctionnelle

Quand ce n’est pas la bonne skill

Ne faites pas de vue-best-practices votre guide principal si la base de code repose volontairement surtout sur l’Options API ou sur JSX. La skill indique elle-même qu’il vaut mieux charger une autre skill dans ces cas-là si elle existe. Elle ne remplace pas non plus la documentation spécifique à un framework pour le routing Nuxt, la configuration des tests ou les sujets de déploiement qui ne sont pas couverts par les références.

Comment utiliser la skill vue-best-practices

Contexte d’installation de vue-best-practices

Installez d’abord le dépôt parent de skills, puis invoquez la skill vue-best-practices depuis cette collection :

npx skills add vuejs-ai/skills --skill vue-best-practices

Le chemin dans le dépôt est :
skills/vue-best-practices

Source GitHub :
https://github.com/vuejs-ai/skills/tree/main/skills/vue-best-practices

Les fichiers à lire en premier

Pour aller vite avec un maximum de signal, commencez par :

• skills/vue-best-practices/SKILL.md
• skills/vue-best-practices/references/reactivity.md
• skills/vue-best-practices/references/sfc.md
• skills/vue-best-practices/references/component-data-flow.md
• skills/vue-best-practices/references/composables.md

La skill elle-même présente ces quatre références comme le socle de contexte indispensable. Si vous les sautez, vous perdez l’essentiel de sa valeur pratique.

Les informations dont la skill a besoin

L’usage de vue-best-practices s’améliore nettement lorsque vous fournissez un contexte d’architecture, pas seulement une demande de fonctionnalité. Le minimum utile à donner est :

• la version de Vue et si le projet est bien en Vue 3
• si le projet utilise déjà TypeScript
• si la base de code impose Composition API, Options API ou JSX
• le contexte router/store
• un contexte SSR ou client-only
• les responsabilités du composant
• le flux de données parent/enfant existant
• les contraintes de performance, d’accessibilité ou de taille de bundle

Un prompt faible demande un composant. Un bon prompt explique où ce composant s’insère dans l’application et comment les données doivent circuler.

Transformer un objectif vague en prompt solide

Faible :

• « Build a Vue modal. »

Plus solide :

• « Using vue-best-practices, create a Vue 3 modal component with <script setup lang="ts">. The modal is controlled by the parent via props and emits, must support v-model:open, trap focus, Teleport to body, and avoid mutating props internally. Show the component API, parent usage, and explain why props/emits are better here than provide/inject.”

Cette version donne à la skill assez de contexte pour appliquer correctement ses recommandations sur le flux de données et l’API du composant.

Le meilleur workflow pour une première utilisation

Un guide pratique d’utilisation de vue-best-practices ressemble à ceci :

1. Valider l’architecture du projet avant de demander du code.
2. Indiquer si la Composition API est le choix par défaut.
3. Demander à l’agent de consulter d’abord les références de base.
4. Exiger un plan d’implémentation avant le code si la frontière du composant n’est pas claire.
5. Générer le composant.
6. Faire une seconde passe de revue centrée sur Vue : réactivité, attrs, slots, performance et comportement SSR.

Ce workflow est directement aligné avec l’accent mis par la skill sur le principe « confirmer l’architecture avant de coder ».

Comment demander la bonne décision d’architecture

Cette skill est la plus utile quand la demande est formulée comme une décision à prendre, et non comme un simple dump de code. Bons exemples :

• « Should this state live in the parent, a composable, or Pinia? »
• « Is v-model appropriate here or should this be explicit props/emits? »
• « Should this large list use virtualization? »
• « Is <Transition> correct here, or would class-based animation be simpler? »
• « Should this component be async-loaded in SSR? »

Ces questions correspondent directement aux références du dépôt.

Les fichiers de référence à mobiliser selon la tâche

Utilisez ces références de façon ciblée selon le sujet :

• references/component-async.md pour le lazy loading et le timing d’hydratation en SSR
• references/component-slots.md pour la conception d’API de slots et defineSlots
• references/component-fallthrough-attrs.md pour $attrs et useAttrs()
• references/component-keep-alive.md pour le comportement du cache et le risque d’état périmé
• references/component-transition.md et references/component-transition-group.md pour les cas d’entrée/sortie
• references/animation-class-based-technique.md pour les effets qui ne reposent pas sur mount/unmount
• references/state-management.md pour les décisions de propriété de l’état
• references/perf-virtualize-large-lists.md pour le rendu de grandes listes
• references/perf-v-once-v-memo-directives.md pour l’optimisation sélective du rendu

Des patterns de prompt pratiques qui donnent de meilleurs résultats

Utilisez des prompts qui demandent à la fois du code et le raisonnement. Par exemple :

• « Apply vue-best-practices and explain the chosen data-flow model.”
• « Refactor this component to Composition API with <script setup lang="ts">, and call out any reactivity pitfalls.”
• « Review this .vue file against vue-best-practices and classify issues as architecture, data flow, performance, or API design.”
• « Implement this feature and list which Vue references were used.”

Cela oblige l’assistant à expliciter ses hypothèses au lieu d’inventer silencieusement des patterns.

Les freins d’adoption les plus fréquents

Le principal frein, c’est le décalage avec la réalité de la base de code. Si votre projet est sur un Vue plus ancien, orienté d’abord Options API, ou s’appuie fortement sur JSX/render functions, les choix par défaut de la skill peuvent créer de la friction. Autre blocage fréquent : une propriété de l’état insuffisamment précisée. Beaucoup d’erreurs Vue viennent du fait qu’on demande un comportement d’UI sans dire qui possède l’état, ce qui mène à de mauvaises mutations de props ou à un binding bidirectionnel confus.

Ce qu’il faut vérifier après génération

Après avoir utilisé la skill vue-best-practices, vérifiez que :

• les props ne sont pas mutées dans les composants enfants
• les emits sont explicites et typés lorsque TypeScript est utilisé
• watch n’est pas employé là où computed serait plus simple
• les composables contiennent de la logique réutilisable, pas un état partagé accidentel
• les composants asynchrones ne créent pas une mauvaise UX de chargement
• attrs, slots et transitions respectent les conventions Vue
• les tactiques de performance sont justifiées et ne relèvent pas du cargo cult

FAQ sur la skill vue-best-practices

vue-best-practices est-il adapté aux débutants

Oui, mais vue-best-practices est souvent plus utile aux débutants en mode relecture qu’en génération de code à l’aveugle. Les références expliquent pourquoi certains patterns Vue sont préférables, ce qui aide les nouveaux utilisateurs à ne pas apprendre trop tôt de mauvais réflexes.

vue-best-practices prend-il uniquement en charge Vue 3

Dans les faits, oui pour son parcours par défaut. La skill est fortement centrée sur Vue 3, la Composition API, <script setup>, TypeScript, les patterns compatibles SSR, Volar et vue-tsc. Si votre application est en Vue 2 ou surtout en phase de migration, ce n’est pas le meilleur choix.

En quoi vue-best-practices diffère-t-il d’un prompt classique

Un prompt classique peut produire un code d’apparence Vue qui fonctionne. vue-best-practices, lui, apporte à l’assistant un biais architectural précis et un ordre de lecture. C’est important avec Vue, car les erreurs liées à la réactivité, à la communication entre composants, aux attrs, au cache et aux slots ont souvent l’air correctes au départ, mais vieillissent mal.

vue-best-practices est-il pertinent pour une base de code existante

Oui, surtout pour le refactoring et la revue. Il est souvent plus précieux sur des composants existants que sur du greenfield, car il aide à repérer une propriété d’état floue, des composants devenus trop gros et des problèmes de justesse spécifiques à Vue qu’on manque facilement dans des applications matures.

Faut-il l’utiliser pour des tâches Pinia, Router et SSR

Oui, tant que la tâche reste fondamentalement liée à l’architecture Vue ou au comportement des composants. La description de la skill couvre explicitement Vue Router, Pinia, Vite avec Vue et les sujets liés au SSR. Indiquez simplement ces contraintes dans votre prompt pour éviter que l’agent ne parte sur un cas client-only plus simple.

Quand ne faut-il pas utiliser vue-best-practices

Évitez cette skill si :

• le projet impose explicitement des conventions Options API
• le projet utilise JSX comme style principal d’écriture
• vous avez besoin de conseils spécifiques à un framework hors du périmètre des références du dépôt
• vous voulez seulement un prototype jetable rapide sans vous soucier des idiomes Vue

Comment améliorer la skill vue-best-practices

Donnez à vue-best-practices des entrées d’architecture plus solides

Le moyen le plus rapide d’améliorer la qualité des sorties est de préciser :

• le propriétaire de l’état
• les frontières entre composants
• les attentes sur l’API parent/enfant
• l’exigence TypeScript
• le rendu SSR vs client-only
• l’échelle attendue, par exemple de grandes listes ou des vues mises en cache

Sans cela, la skill doit deviner des arbitrages de conception qu’elle est justement censée traiter explicitement.

Demandez un plan avant l’implémentation

Pour tout travail un peu substantiel, commencez par demander :

• où l’état doit vivre
• si la fonctionnalité relève d’un composant, d’un composable ou du store
• si la communication doit passer par props/emits, v-model, provide/inject ou l’état du router/store

Cela suit la règle « architecture d’abord » du dépôt et améliore en général davantage le premier jet de code qu’une simple demande de « clean code ».

Utilisez la bibliothèque de références de façon délibérée

La skill vue-best-practices a une vraie profondeur dans son dossier references/. Vous obtiendrez de meilleurs résultats en citant le fichier pertinent dans votre prompt :

• « Use component-data-flow.md logic »
• « Check component-async.md because this is SSR »
• « Apply component-fallthrough-attrs.md because this wrapper forwards attrs »
• « Use perf-virtualize-large-lists.md because this table can exceed 5,000 rows »

C’est un avantage concret par rapport à un prompting générique.

Surveillez les modes d’échec les plus courants

Les sorties faibles apparaissent typiquement lorsque l’assistant :

• mute des props au lieu d’émettre des mises à jour
• utilise des watchers alors qu’un état calculé suffit
• choisit provide/inject trop tôt
• encapsule la logique dans un composant alors qu’elle devrait vivre dans un composable
• ajoute des transitions là où une animation basée sur des classes serait plus simple
• met des vues en cache avec <KeepAlive> sans stratégie de fraîcheur
• suggère des micro-optimisations prématurées sans preuves

C’est précisément le type de problèmes que cette skill est censée réduire.

Améliorez les prompts de revue après le premier jet

Après la génération du code, demandez une seconde passe du type :

• « Review this against vue-best-practices and list the top 5 risks.”
• « Find any reactivity edge cases or data-flow violations.”
• « Check whether this slot API and fallthrough attrs behavior are robust.”
• « Audit this SSR component for async loading and hydration concerns.”

Le premier passage produit du code. Le second fait ressortir la vraie valeur de la skill.

Rendez la sortie plus exploitable avec des livrables explicites

Si vous voulez un meilleur usage de vue-best-practices, demandez :

• le code final
• une courte justification d’architecture
• une liste des alternatives écartées
• des notes de migration en cas de refactoring de code existant
• une checklist de vérification pour vue-tsc, Volar et le comportement à l’exécution

Ce format limite les réponses superficielles et rend le résultat plus facile à adopter dans un vrai dépôt.