vue-best-practices

Überblick über den vue-best-practices-Skill

Wofür vue-best-practices gedacht ist

vue-best-practices ist ein auf Vue ausgerichteter Instruction-Skill für Codegenerierung, Reviews und Refactorings in Vue-3-Projekten. Seine Kernaufgabe ist nicht einfach nur „Vue-Code schreiben“, sondern „Vue-Code nach aktuellen Architektur-Standards schreiben, die auch unter realem Projektstress wartbar bleiben“. In der Praxis lenkt der Skill Agents in Richtung Composition API, <script setup lang="ts">, explizitem Datenfluss und Vue-spezifischen Entscheidungen, die generische Frontend-Prompts oft übersehen.

Wer vue-best-practices installieren sollte

Dieser Skill eignet sich besonders für Teams und Solo-Entwickler, die mit Vue 3, .vue Single-File Components, Vue Router, Pinia-artigen State-Patterns, Vite-basierten Apps und SSR-fähigen Vue-Anwendungen arbeiten. Besonders nützlich ist er, wenn du möchtest, dass ein KI-Assistent nicht in generische JavaScript-Muster abdriftet, sondern Vue-native Konventionen einhält.

Der eigentliche Job-to-be-done

Der eigentliche Wert von vue-best-practices liegt darin, vermeidbare Designfehler zu reduzieren, bevor die Implementierung überhaupt beginnt. Der Skill weist den Agenten ausdrücklich an, zuerst die Architektur zu bestätigen und dann einige Kernreferenzen aktiv im Kontext zu halten: Reaktivität, SFC-Struktur, Component Data Flow und Composables. Dadurch ist er für Implementierungsentscheidungen deutlich hilfreicher als ein einfacher „build this component“-Prompt.

Was diesen Skill besonders macht

Der Unterschied liegt im Entscheidungsweg. Der Skill sagt nicht nur „nutze Vue 3“, sondern setzt Defaults und klare Grenzen:

• standardmäßig Composition API mit <script setup lang="ts">
• Wechsel auf einen anderen Skill, wenn das Projekt explizit auf Options API oder JSX setzt
• Props, Emits, v-model, provide/inject, Async Components, Transitions und Performance werden als zentrale Designfragen behandelt
• für Edge Cases werden gezielt Referenzdokumente genutzt, statt sich auf Erinnerung zu verlassen

Wann vue-best-practices besonders gut passt

Nutze vue-best-practices for Frontend Development, wenn du Unterstützung brauchst bei:

• dem Erstellen oder Refaktorieren von Vue-Komponenten
• der Entscheidung zwischen props/emits, v-model, provide/inject oder einem Store
• dem Design von Composables
• SSR-sensiblen Entscheidungen zu Async Components
• Slot-APIs, fallthrough attrs, Transitions, KeepAlive und Listen-Performance
• der Überprüfung, ob eine Vue-Implementierung idiomatisch ist und nicht nur funktioniert

Wann es nicht der richtige Skill ist

Verlass dich nicht auf vue-best-practices als Hauptleitfaden, wenn die Codebasis bewusst stark auf Options API oder JSX ausgerichtet ist. Der Skill selbst empfiehlt in solchen Fällen, sofern verfügbar, einen anderen Skill zu laden. Er ersetzt außerdem keine framework-spezifische Dokumentation zu Nuxt-Routing, Test-Setups oder Deployment-Themen, die in den Referenzen nicht abgedeckt sind.

So verwendest du den vue-best-practices-Skill

vue-best-practices Installationskontext

Installiere das übergeordnete Skill-Repository und rufe dann den vue-best-practices-Skill aus dieser Sammlung auf:

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

Der Repository-Pfad lautet:
skills/vue-best-practices

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

Diese Dateien solltest du zuerst lesen

Für einen schnellen, signalstarken Einstieg beginne mit:

• 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

Diese vier Referenzen werden im Skill selbst als zwingend nötiger Kernkontext genannt. Wenn du sie auslässt, verlierst du den Großteil des praktischen Nutzens des Skills.

Welche Eingaben der Skill von dir braucht

vue-best-practices usage wird deutlich besser, wenn du Architekturkontext lieferst und nicht nur einen Feature-Wunsch. Das minimal sinnvolle Input-Set ist:

• Vue-Version und ob es sich um Vue 3 handelt
• ob das Projekt bereits TypeScript verwendet
• ob die Codebasis Composition API, Options API oder JSX voraussetzt
• Router-/Store-Kontext
• SSR- oder Client-only-Kontext
• die Verantwortlichkeiten der Komponente
• bestehender Datenfluss zwischen Parent und Child
• Anforderungen an Performance, Accessibility oder Bundle-Größe

Ein schwacher Prompt bittet einfach um eine Komponente. Ein starker Prompt erklärt, wo diese Komponente in der App sitzt und wie sich Daten bewegen sollen.

Ein grobes Ziel in einen starken Prompt verwandeln

Schwach:

• „Build a Vue modal.“

Stärker:

• „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.”

Diese Version gibt dem Skill genug Kontext, um seine Hinweise zu Datenfluss und Component API tatsächlich anzuwenden.

Bester Workflow für den ersten Einsatz von vue-best-practices

Ein praxistauglicher vue-best-practices guide sieht so aus:

1. Vor jeder Codeanfrage zuerst die Projektarchitektur klären.
2. Angeben, ob Composition API der Standard ist.
3. Den Agenten bitten, zuerst die Kernreferenzen zu konsultieren.
4. Bei unklaren Component Boundaries erst einen Implementierungsplan anfordern.
5. Danach die Komponente generieren.
6. Im zweiten Durchgang gezielt ein Vue-spezifisches Review machen: Reaktivität, attrs, Slots, Performance und SSR-Verhalten.

Dieser Ablauf entspricht dem Schwerpunkt des Skills: erst die Architektur bestätigen, dann coden.

So fragst du nach der richtigen Architekturentscheidung

Dieser Skill ist am nützlichsten, wenn die Frage als Entscheidung formuliert ist und nicht als reiner Code-Dump. Gute Beispiele:

• „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?”

Diese Fragen mappen direkt auf die Referenzen im Repository.

Referenzdateien, die sich je nach Aufgabe lohnen

Ziehe diese Referenzen gezielt je nach Aufgabe hinzu:

• references/component-async.md für Lazy Loading und SSR-Hydration-Timing
• references/component-slots.md für Slot-API-Design und defineSlots
• references/component-fallthrough-attrs.md für $attrs und useAttrs()
• references/component-keep-alive.md für Cache-Verhalten und das Risiko veralteter States
• references/component-transition.md und references/component-transition-group.md für Enter-/Leave-Szenarien
• references/animation-class-based-technique.md für Effekte außerhalb von Mount/Unmount
• references/state-management.md für Entscheidungen zur State Ownership
• references/perf-virtualize-large-lists.md für das Rendering großer Listen
• references/perf-v-once-v-memo-directives.md für selektive Render-Optimierung

Praktische Prompt-Muster, die bessere Ergebnisse liefern

Verwende Prompts, die sowohl Code als auch Begründung verlangen. Zum Beispiel:

• „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.”

So zwingst du den Assistenten, seine Annahmen offenzulegen, statt stillschweigend Patterns zu erfinden.

Häufige Hürden bei der Einführung

Der größte Blocker ist ein Missverhältnis zur tatsächlichen Codebasis. Wenn dein Projekt älteres Vue nutzt, Options API priorisiert oder stark auf JSX/Render Functions setzt, können die Defaults des Skills unnötige Reibung erzeugen. Ein weiterer Blocker ist unklar definierte State Ownership. Viele Vue-Fehler entstehen, weil UI-Verhalten angefragt wird, ohne festzulegen, wem der State gehört — das führt dann zu schlechter Prop-Mutation oder unsauberen Two-Way-Binding-Mustern.

Was du nach der Generierung prüfen solltest

Nach der Nutzung des vue-best-practices skill solltest du prüfen:

• Props werden in Child-Komponenten nicht mutiert
• Emits sind explizit und bei TypeScript-Nutzung typisiert
• watch wird nicht dort eingesetzt, wo computed einfacher wäre
• Composables enthalten wiederverwendbare Logik, keinen versehentlich geteilten State
• Async Components führen nicht zu einer schlechten Loading-UX
• attrs, Slots und Transitions folgen den Vue-Konventionen
• Performance-Maßnahmen sind begründet und nicht bloß Cargo Cult

FAQ zum vue-best-practices-Skill

Ist vue-best-practices anfängerfreundlich

Ja, aber für Einsteiger ist der Skill eher als Reviewer besonders hilfreich als als blinder Codegenerator. Die Referenzen erklären, warum bestimmte Vue-Patterns bevorzugt werden. So lernen neue Nutzer nicht zu früh Anti-Patterns.

Unterstützt vue-best-practices nur Vue 3

Im Standardpfad praktisch ja. Der Skill ist klar auf Vue 3, Composition API, <script setup>, TypeScript, SSR-bewusste Patterns, Volar und vue-tsc ausgerichtet. Wenn deine App noch auf Vue 2 basiert oder stark migrationsgetrieben ist, passt dieser Skill weniger gut.

Worin unterscheidet sich vue-best-practices von einem normalen Prompt

Ein normaler Prompt kann funktionierenden, Vue-ähnlichen Code liefern. vue-best-practices gibt dem Assistenten dagegen einen konkreten Architektur-Bias und eine feste Lesereihenfolge. Gerade bei Vue ist das wichtig, weil Fehler rund um Reaktivität, Komponentenkommunikation, attrs, Caching und Slots anfangs oft harmlos wirken, aber mit der Zeit schlecht altern.

Ist vue-best-practices gut für bestehende Codebasen

Ja, besonders für Refactorings und Reviews. Bei bestehenden Komponenten ist der Skill oft wertvoller als bei Greenfield-Arbeit, weil er unklare State Ownership, überladene Komponenten und Vue-spezifische Korrektheitsprobleme sichtbar macht, die in reifen Apps leicht übersehen werden.

Sollte ich ihn für Pinia-, Router- und SSR-Aufgaben verwenden

Ja, sofern die Aufgabe im Kern weiterhin Vue-Architektur oder Komponentenverhalten betrifft. Die Skill-Beschreibung deckt ausdrücklich Vue Router, Pinia, Vite mit Vue und SSR-bezogene Themen ab. Gib diese Rahmenbedingungen einfach im Prompt mit an, damit der Agent nicht fälschlich von einem einfacheren Client-only-Fall ausgeht.

Wann sollte ich vue-best-practices nicht verwenden

Lass den Skill aus, wenn:

• das Projekt ausdrücklich Konventionen der Options API verlangt
• das Projekt JSX als primären Authoring-Stil nutzt
• du framework-spezifische Anleitung außerhalb der Referenzen des Repos brauchst
• du nur einen schnellen Wegwerf-Prototyp willst und dir Vue-Idiome egal sind

So verbesserst du den vue-best-practices-Skill

Gib vue-best-practices stärkere Architektur-Inputs

Der schnellste Weg zu besserer Ausgabequalität ist, Folgendes konkret anzugeben:

• State Owner
• Component Boundaries
• erwartete Parent-/Child-API
• TypeScript-Anforderung
• SSR vs. Client-only-Rendering
• erwartete Skalierung, etwa große Listen oder gecachte Views

Ohne diese Angaben muss der Skill Design-Trade-offs erraten, die eigentlich explizit entschieden werden sollten.

Verlange vor der Implementierung zuerst einen Plan

Bei nicht trivialen Aufgaben solltest du zuerst fragen:

• welcher State wohin gehört
• ob das Feature eine Komponenten-, Composable- oder Store-Verantwortung sein sollte
• ob die Kommunikation über props/emits, v-model, provide/inject oder Router-/Store-State laufen sollte

Das folgt der Architecture-first-Regel des Repositorys und verbessert den ersten Code-Durchlauf meist stärker als die bloße Bitte um „clean code“.

Nutze die Referenzbibliothek gezielt

Der vue-best-practices skill hat in seinem Ordner references/ echte inhaltliche Tiefe. Bessere Ergebnisse bekommst du, wenn du die relevante Datei direkt im Prompt nennst:

• „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”

Das ist ein praktischer Vorteil gegenüber generischem Prompting.

Achte auf die häufigsten Fehlermuster

Typisch schwache Ergebnisse entstehen, wenn der Assistent:

• Props mutiert, statt Updates per Emit weiterzugeben
• Watcher einsetzt, obwohl computed ausreichen würde
• zu früh provide/inject wählt
• Logik in eine Komponente packt, die besser in ein Composable gehört
• Transitions ergänzt, obwohl klassenbasierte Animation einfacher wäre
• Views mit <KeepAlive> cached, ohne Strategie für frische Daten
• vorzeitig Mikro-Optimierungen ohne belastbare Hinweise vorschlägt

Genau solche Probleme soll dieser Skill reduzieren.

Verbessere Review-Prompts nach dem ersten Entwurf

Nach der Codegenerierung lohnt sich ein zweiter Durchgang mit Prompts wie:

• „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.”

Der erste Durchgang erzeugt Code. Der zweite holt den eigentlichen Wert des Skills heraus.

Mache die Ausgabe mit klaren Deliverables umsetzbarer

Wenn du hochwertigere vue-best-practices usage willst, fordere gezielt an:

• finalen Code
• eine kurze Architekturbegründung
• eine Liste verworfener Alternativen
• Migrationshinweise bei Refactorings bestehender Komponenten
• eine Checkliste zur Verifikation mit vue-tsc, Volar und Laufzeitverhalten

Dieses Format reduziert oberflächliche Antworten und macht das Ergebnis leichter in einem echten Repo nutzbar.