vue

Présentation de la skill vue

À quoi sert la skill vue

La skill vue est un guide ciblé pour générer et relire du code Vue 3 selon les bonnes pratiques actuelles, en particulier autour de la Composition API, de <script setup lang="ts">, des compiler macros, des API de réactivité et des composants intégrés comme Transition, Teleport, Suspense et KeepAlive. Elle est particulièrement utile si vous voulez qu’un agent IA produise des Single File Components Vue déjà conformes à un style Vue moderne, au lieu de retomber sur d’anciens schémas basés sur l’Options API.

Qui devrait installer cette skill vue

Cette vue skill convient aux développeurs frontend, aux développeurs full-stack et aux utilisateurs d’IA qui demandent régulièrement des composants Vue, des composables ou des refactorings. Elle apporte une vraie valeur si vous attendez des sorties orientées TypeScript, compatibles avec les macros et alignées sur la documentation de l’ère Vue 3.5, plutôt que sur un mélange d’habitudes Vue 2 et de débuts de Vue 3.

Le vrai besoin métier couvert

La plupart des utilisateurs n’ont pas besoin d’un simple résumé générique du framework. Ils ont besoin que l’agent écrive du code Vue de manière fiable, avec des choix comme :

• utiliser la Composition API par défaut
• privilégier <script setup lang="ts">
• gérer correctement defineProps, defineEmits et defineModel
• choisir plus finement entre ref, shallowRef, computed et watch
• recourir aux built-ins avancés uniquement quand ils sont réellement pertinents

C’est la valeur concrète de vue for Frontend Development : réduire le nettoyage à faire après génération de code par IA.

Ce qui différencie vraiment cette skill vue

Son principal point fort est son approche prescriptive. La source privilégie explicitement TypeScript, <script setup lang="ts"> et la Composition API, et déconseille Reactive Props Destructure. Elle inclut aussi des références ciblées sur :

• les macros de script setup
• la réactivité et les API core plus récentes
• les composants intégrés avancés et les directives

Cela rend la skill plus utile pour de l’implémentation concrète qu’un prompt large du type « apprends-moi Vue ».

Ce que cette skill ne cherche pas à couvrir

Ce n’est pas une cartographie complète de l’écosystème Vue. Elle ne remplace pas une documentation approfondie sur le routing, les bibliothèques d’état, les frameworks SSR, les tests ou l’outillage de build. Si votre sujet principal concerne l’architecture Nuxt, la configuration de Vue Router, la conception Pinia ou les pipelines de déploiement, la skill vue aide sur le style de code au niveau composant, mais ne doit pas être votre seule source.

Comment utiliser la skill vue

Contexte d’installation de vue

Installez la skill dans votre environnement compatible skills avec :

npx skills add antfu/skills --skill vue

Les éléments visibles dans le repository montrent que la skill se trouve sous skills/vue dans antfu/skills. Il n’y a pas ici d’installation séparée du framework Vue lui-même ; il s’agit d’un cadre de guidance pour mieux générer du Vue avec assistance IA, pas du runtime du framework.

Commencez par lire ces fichiers

Si vous voulez le chemin le plus utile avant d’utiliser la vue skill, lisez ces fichiers dans cet ordre :

1. skills/vue/SKILL.md
2. skills/vue/references/script-setup-macros.md
3. skills/vue/references/core-new-apis.md
4. skills/vue/references/advanced-patterns.md
5. skills/vue/GENERATION.md

Pourquoi cet ordre :

• SKILL.md donne les préférences de fonctionnement et le périmètre.
• Les trois fichiers de référence contiennent les détails pratiques que l’agent va le plus probablement appliquer.
• GENERATION.md indique que le contenu est généré à partir de la doc Vue et suit un snapshot récent.

De quelles entrées la skill vue a besoin

La qualité de vue usage dépend fortement de la demande que vous envoyez. Donnez à l’agent :

• l’objectif du composant
• les props et les événements émis
• si vous avez besoin de v-model
• la forme attendue de l’état
• les besoins en données asynchrones
• si la sortie doit être un composant, un composable ou un exemple de pattern
• les contraintes de version Vue si vous n’êtes pas sur une version récente de Vue 3
• l’exigence TypeScript
• les éventuelles contraintes d’UI ou de performance

Entrée faible :

• « Crée un composant Vue pour la recherche. »

Entrée solide :

• « Crée un SFC Vue 3.5 avec <script setup lang="ts"> pour une liste de produits filtrable. Props : items, loading, modelValue. Émets update:modelValue et select. Utilise defineModel si pertinent, ajoute un debounce sur la saisie de recherche locale, et préfère shallowRef pour de grands tableaux d’éléments. »

Transformer des objectifs vagues en prompts vue efficaces

Pour bien invoquer la skill vue, demandez explicitement les choix d’implémentation. Une bonne structure de prompt :

1. préciser l’artefact
2. préciser les conventions Vue
3. définir les entrées et les sorties
4. ajouter les comportements et contraintes
5. demander un raisonnement lorsque des arbitrages comptent

Exemple :

« En suivant le style de la skill vue, écris un composant Vue 3 avec <script setup lang="ts">. Utilise uniquement la Composition API. Définis des props et emits typés, évite l’Options API, et explique si ref ou shallowRef est le meilleur choix pour l’état principal. Inclus le template et des styles minimaux. »

Cela fonctionne mieux qu’une demande générique comme « écris du Vue », parce que le prompt colle aux préférences natives de la skill.

Le style de code par défaut vers lequel la skill vue pousse

Le contenu source oriente fortement l’agent vers :

• Vue 3.5
• Composition API
• <script setup lang="ts">
• des définitions de composants basées sur les macros
• des props et emits typés
• un usage sélectif de shallowRef pour les données sensibles côté performance

Si vous voulez l’Options API, du JavaScript simple ou des patterns Vue legacy, dites-le explicitement, car la skill est biaisée dans l’autre sens.

Les meilleurs cas d’usage de vue

Ce vue guide est particulièrement pertinent pour :

• écrire de nouveaux Vue SFC
• refactorer d’anciens composants vers <script setup>
• définir des props, emits et models typés
• choisir entre ref, reactive, computed et les watchers
• utiliser Transition, Teleport, Suspense ou KeepAlive
• produire des exemples de composables conformes aux patterns Vue modernes

Il est moins utile pour un travail purement visuel de design ou pour des tâches frontend agnostiques au framework.

Workflow pratique pour une première sortie

Un workflow fiable consiste à :

1. demander un premier jet de Vue SFC avec props, emits et forme d’état explicites ;
2. vérifier si l’API générée correspond bien au contrat réel de votre composant ;
3. demander une seconde passe pour resserrer les choix de réactivité, le typage et les cas limites ;
4. n’ajouter qu’ensuite des fonctionnalités avancées comme les transitions ou les frontières Suspense.

Cette séquence compte, car les fonctionnalités avancées de Vue sont faciles à surutiliser tant que le flux d’état de base n’est pas clair.

Détails issus du repository qui influencent la qualité de sortie

Détails utiles remontés de la source de la skill :

• defineModel est considéré comme disponible à partir de Vue 3.4+
• withDefaults reste pertinent pour Vue 3.4 et antérieur
• reactive() perd sa réactivité lorsqu’on destructure
• shallowRef est préféré quand une réactivité profonde n’est pas nécessaire
• des built-ins comme Transition et Suspense sont couverts avec des patterns concrets

C’est exactement le type de détails qui améliore le code généré au-delà d’un simple survol superficiel du repository.

Exemples de demandes qui correspondent bien à la skill vue

Bonnes demandes vue usage :

• « Refactore ce composant Options API en <script setup lang="ts">. »
• « Génère defineProps et defineEmits typés pour ce composant de formulaire. »
• « Montre un exemple Vue 3 utilisant Teleport pour une modale. »
• « Explique s’il faut utiliser watch, watchEffect ou computed ici. »
• « Réécris ce composant pour utiliser defineModel sur Vue 3.4+. »

Cas de mauvais alignement fréquents avant installation

N’attendez pas de la seule vue skill qu’elle règle :

• le scaffolding de projet
• l’architecture du router
• la conception du store d’état à l’échelle d’une grosse application
• les décisions liées au SSR ou spécifiques à Nuxt
• la configuration du test runner
• les détails d’intégration d’un framework CSS

Si ce sont vos principaux points de blocage, installez-la pour améliorer la qualité de génération des composants, pas comme guide complet de votre stack Vue.

FAQ de la skill vue

Cette skill vue est-elle adaptée aux débutants ?

Oui, si vous travaillez déjà avec Vue 3 et souhaitez des sorties IA plus propres. Ce n’est pas un parcours d’apprentissage pour débuter, mais elle réduit la confusion en privilégiant un style clair : Composition API avec <script setup lang="ts">. Cette cohérence aide les utilisateurs moins expérimentés à éviter les mélanges de patterns.

La skill vue prend-elle en charge les anciens patterns Vue ?

Pas en premier choix. La source indique qu’il faut toujours préférer la Composition API à l’Options API. Si votre base de code est très legacy, vous pouvez malgré tout utiliser la skill, mais vous devez demander explicitement les contraintes de compatibilité et relire les migrations avec attention.

En quoi est-ce différent d’un prompt Vue classique ?

Un prompt classique produit souvent du code Vue incohérent : API mélangées, typage plus faible ou macros obsolètes. La vue skill donne à l’agent un cadre plus resserré, avec des préférences, un usage moderne des macros et des références ciblées. En pratique, cela se traduit généralement par moins de corrections manuelles.

L’installation de vue suffit-elle si je travaille avec Nuxt ou une stack plus large ?

Non. vue install aide pour les composants et la réactivité, mais les sujets de stack plus larges demandent toujours des connaissances sur Nuxt, le routing, l’état, la récupération de données et le déploiement. Utilisez-la comme une couche de génération de code Vue, pas comme une compétence d’architecture applicative complète.

Quand ne faut-il pas utiliser la skill vue ?

Évitez-la si votre tâche porte sur :

• du code UI neutre vis-à-vis du framework
• du travail React/Angular/Svelte
• une implémentation backend uniquement
• des conventions très spécifiques à Nuxt avec peu de vrai travail sur des composants Vue bruts
• la maintenance stricte d’une ancienne base Options API où les patterns modernes ne sont pas autorisés

Couvre-t-elle les fonctionnalités avancées de Vue ?

Oui, mais de façon sélective. Les références incluses couvrent Transition, Teleport, Suspense, KeepAlive, les directives, les API de réactivité, les hooks de cycle de vie et les macros. C’est suffisant pour beaucoup de tâches frontend réelles sans devenir une encyclopédie complète de Vue.

Comment améliorer la skill vue

Donnez à l’agent les bornes de version et de compatibilité

La skill s’appuie sur des recommandations de l’ère Vue 3.5. Si votre application utilise Vue 3.3, 3.4, ou a des limites de support sur les anciennes macros, dites-le dès le départ. C’est particulièrement important pour des fonctionnalités comme defineModel et pour la manière dont les valeurs par défaut des props sont gérées.

Spécifiez les contrats de composant, pas seulement des idées d’UI

Le moyen le plus rapide d’améliorer la sortie vue consiste à fournir :

• les noms et types des props
• les événements émis
• les bindings de modèle
• les états asynchrones
• les états vides et d’erreur
• les responsabilités parent-enfant

La skill est performante sur l’implémentation une fois le contrat clair. Elle l’est beaucoup moins quand elle doit déduire une API complète à partir d’une description d’interface vague.

Demandez explicitement les choix de réactivité

Beaucoup d’erreurs Vue viennent du modèle d’état, pas de la syntaxe du template. Formulez des demandes sur les arbitrages, par exemple :

• « Utilise shallowRef si un suivi profond n’est pas nécessaire. »
• « Explique si computed ou watch est le plus approprié. »
• « Évite de destructurer des objets réactifs sauf avec toRefs. »

Cela s’aligne sur le contenu le plus solide des références et améliore davantage la qualité du code qu’une demande abstraite de « bonnes pratiques ».

Repérez tôt les modes d’échec courants

Relisez les premières sorties en cherchant notamment :

• l’apparition d’Options API alors que vous vouliez la Composition API
• un <script> simple à la place de <script setup lang="ts">
• des defineProps ou defineEmits non typés
• une réactivité profonde inutile
• un mauvais usage des watchers là où computed serait plus simple
• des built-ins avancés ajoutés sans besoin réel

Ce sont les façons les plus probables dont une génération générique s’éloigne du niveau de qualité visé par la skill.

Itérez sur un seul sujet à la fois

Après la première réponse, ne demandez pas tout d’un coup. Améliorez par passes :

1. forme de l’API
2. typage et macros
3. justesse de la réactivité
4. états de rendu
5. patterns UX avancés

Cela facilite la vérification de chaque changement et garde l’agent bien ancré dans le vue guide au lieu de régénérer tout le composant de manière imprévisible.

Utilisez les fichiers de référence comme voie d’escalade

Quand le premier résultat est proche du bon niveau mais pas encore solide, orientez l’agent vers les références internes de la skill :

• references/script-setup-macros.md pour les props, emits, models, slots et la syntaxe des macros
• references/core-new-apis.md pour la réactivité, les watchers et les composables
• references/advanced-patterns.md pour les composants intégrés et les directives

C’est l’un des moyens les plus concrets d’améliorer les sorties de vue for Frontend Development sans réécrire votre prompt depuis zéro.

Demandez une version minimale puis une version production

Un schéma très efficace :

• première demande : un SFC minimal et fonctionnel
• deuxième demande : une passe production avec typage, états, accessibilité et choix de performance

Cela évite les premiers jets trop chargés et fait ressortir les points où les décisions spécifiques à Vue ont un vrai impact.

Gardez la skill alignée avec les règles de votre codebase

Si votre équipe a des conventions différentes des réglages par défaut de la skill, dites-le clairement. Par exemple :

• JavaScript only
• pas de defineModel
• éviter Suspense
• utiliser des objets de props explicites plutôt que des déclarations purement typées
• pas de built-ins avancés sauf demande explicite

La vue skill a une orientation marquée, ce qui est utile, mais vous obtiendrez les meilleurs résultats si ses réglages par défaut sont ajustés aux contraintes réelles de votre repository.