vue-pinia-best-practices

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

Der Skill vue-pinia-best-practices ist ein gezielter Leitfaden für Vue-3-Teams mit Pinia, die weniger Fehler im State-Management und bessere Architekturentscheidungen als Standard möchten. Er ist kein allgemeines Vue-Tutorial. Stattdessen konzentriert er sich auf die Pinia-Fehler, die in echten Projekten besonders oft Zeit kosten: falsches Installations- bzw. Initialisierungs-Timing, kaputte Reaktivität durch Destructuring, SSR-/DevTools-Probleme bei Setup-Stores und die Frage, was in Stores gehört und was besser in der URL liegt.

Für wen dieser Skill am besten geeignet ist

Der Skill vue-pinia-best-practices passt besonders für:

• Vue-3-Entwickler, die Pinia bereits einsetzen oder gerade einführen
• Teams, die von Vuex oder selbstgebauten reactive()-Stores migrieren
• Entwickler, die auf konkrete Runtime-Probleme wie getActivePinia()-Fehler stoßen
• Frontend Engineers, die Konventionen suchen, die auch über kleine Demo-Apps hinaus skalieren

Besonders nützlich ist er, wenn eure App gemeinsamen State, Routing, SSR-Anforderungen, DevTools-Workflows oder mehrere Mitwirkende hat.

Welches Problem der Skill für dich löst

Nutze den Skill vue-pinia-best-practices, wenn du einen AI-Assistenten Pinia-Code prüfen oder erzeugen lassen willst – mit weniger versteckten Stolperfallen. Der eigentliche Job-to-be-done ist nicht „Pinia erklären“, sondern: „Hilf mir, Stores sauber zu strukturieren und bekannte Fehler zu vermeiden, bevor sie live gehen.“

Was ihn von einem generischen Vue-Prompt unterscheidet

Ein allgemeiner Prompt kann scheinbar plausiblen Pinia-Code erzeugen, der in der Praxis trotzdem scheitert. Dieser Skill ist stärker, weil er sich auf einen kleinen Satz wirkungsvoller, praxiserprobter Muster konzentriert:

• Pinia installieren, bevor irgendetwas Stores verwendet
• keinen Store-Zugriff auf Top-Level-Ebene vor der App-Initialisierung
• in Setup-Stores den gesamten reaktiven State zurückgeben
• bei Destructuring von State und Gettern storeToRefs() verwenden
• teilbare Filterzustände in der URL halten, nicht nur in Pinia
• in größeren Apps Pinia gegenüber ad-hoc Stores bevorzugen

Was dieser Skill bewusst nicht abdeckt

Der Skill ist bewusst eng zugeschnitten. Er ersetzt keine vollständige Dokumentation für:

• fortgeschrittenes Plugin-Authoring
• End-to-End-Details zur SSR-Integration in bestimmten Frameworks
• jeden denkbaren Stil zur Store-Organisation
• nicht verwandte Vue-Component-Patterns

Wenn du ein vollständiges, frameworkspezifisches Setup brauchst, dann nutze diesen Skill als Guardrail-Schicht – nicht als gesamten Implementierungsplan.

So nutzt du den Skill vue-pinia-best-practices

Installationskontext für vue-pinia-best-practices

Wenn dein Skill-Runner repositorybasierte Skill-Installation unterstützt, füge vue-pinia-best-practices aus vuejs-ai/skills genauso hinzu wie andere Skills aus dieser Sammlung. Nach der Installation ist dieses Arbeitsverzeichnis entscheidend:

• skills/vue-pinia-best-practices/

Starte mit:

• SKILL.md

Lies danach die Referenzdateien, die zu deinem aktuellen Problem passen.

Diese Dateien je nach Problemtyp zuerst lesen

Am schnellsten kommst du voran, wenn du direkt die Referenz öffnest, die zu deinem Symptom passt:

• reference/pinia-no-active-pinia-error.md für Abstürze beim Start oder falsche Install-Reihenfolge
• reference/pinia-setup-store-return-all-state.md für SSR- oder DevTools-Probleme in Setup-Stores
• reference/pinia-store-destructuring-breaks-reactivity.md für veraltete UI nach Destructuring
• reference/state-url-for-ephemeral-filters.md für Filter-, Such-, Sortier- und Paginierungszustand
• reference/state-use-pinia-for-large-apps.md für Architekturentscheidungen
• reference/store-method-binding-parentheses.md für Method-Binding-Probleme in nicht-Pinia-reactive()-Stores

Das Repo ist kompakt. Deshalb ist es wichtiger, früh die richtige Datei zu öffnen, als alles der Reihe nach zu lesen.

Welche Eingaben der Skill braucht, um gut zu helfen

Der Skill vue-pinia-best-practices funktioniert am besten, wenn du konkreten Implementierungskontext lieferst – nicht nur „Hilf mir mit Pinia“. Gib idealerweise an:

• deine Vue-Version und ob du Vue 3 mit Composition API nutzt
• ob es sich um einen Pinia-Store oder einen selbstgebauten reaktiven Store handelt
• ob das Problem beim Start, bei der Navigation, in Templates oder nach einem Refresh auftritt
• relevante Dateien wie main.ts, Router-Setup, eine Store-Datei und eine konsumierende Component
• ob SSR, DevTools-Sichtbarkeit oder URL-Persistenz wichtig sind

Ohne diesen Kontext kann der Assistent zwar korrekte, aber am Problem vorbeigehende Hinweise geben.

Aus einem groben Ziel einen starken Prompt machen

Schwacher Prompt:

• „Hilf mir, meinen Pinia-Store zu fixen.“

Besserer Prompt:

• „Use the vue-pinia-best-practices skill. I have a Vue 3 app with Pinia and Vue Router. I get getActivePinia() during startup when a router guard reads useAuthStore(). Review my main.ts and router file, explain the root cause, and rewrite the setup in the safest order.“

Noch ein gutes Beispiel:

• „Use vue-pinia-best-practices to review this setup store for SSR and DevTools compatibility. Tell me if any reactive state is not returned, what that breaks, and provide a corrected store.“

Praktischer Workflow für die Nutzung von vue-pinia-best-practices

Ein verlässlicher Workflow für diesen Skill:

1. Die Symptom-Kategorie bestimmen: Start, Reaktivität, Setup-Store-Struktur, URL-State oder Architektur.
2. Die kleinste Dateimenge anhängen, mit der sich das Problem reproduzieren lässt.
3. Den Assistenten bitten, die Diagnose anhand der passenden reference/*.md-Datei zu machen.
4. Eine korrigierte Code-Version plus eine kurze, wiederverwendbare Regel anfordern.
5. Nach dem ersten Fix um eine Checkliste bitten, um das Muster im gesamten Repo anzuwenden.

Damit erzielst du meist deutlich bessere Ergebnisse als mit einem einmaligen „Best Practices Review“ ohne Code.

Für Startup- und Plugin-Reihenfolge-Bugs einsetzen

Einer der wertvollsten Einsatzzwecke von vue-pinia-best-practices ist das Beheben von „no active Pinia“-Fehlern. Wenn Router-Guards oder Module Stores zu früh aufrufen, bitte den Assistenten, diese Dateien zu prüfen:

• main.js oder main.ts
• Router-Erstellung und Registrierung der Guards
• alle Top-Level-Imports, die useXxxStore() aufrufen

Das Kernproblem ist meist das Initialisierungs-Timing – nicht die Store-Implementierung selbst.

Für reaktivitätssicheres Destructuring nutzen

Wenn deine UI nicht mehr aktualisiert wird, nachdem du Werte aus einem Store herausgezogen hast, lass den Skill prüfen, ob du den Store direkt destructured hast. Die wahrscheinliche Korrektur ist:

• Actions bei Bedarf weiterhin direkt destructuren
• State und Getter über storeToRefs() beziehen

Das ist ein sinnvoller Review-Prompt für jede Component, die viele Store-Werte liest.

Für SSR- und DevTools-Prüfungen bei Setup-Stores nutzen

Wenn du defineStore('x', () => {}) verwendest, sollte der Assistent prüfen, ob der gesamte reaktive State zurückgegeben wird. Das ist wichtig, weil ausgelassener State stillschweigend Folgendes kaputtmachen kann:

• SSR-Serialisierung und Hydration
• Vue-DevTools-Inspektion
• Kompatibilität mit Pinia-Plugins

Genau deshalb lohnt sich der Skill vue-pinia-best-practices schon im Code-Review – nicht erst beim Debugging.

Für Entscheidungen zur Platzierung von State nutzen

Ein subtiler, aber sehr wertvoller Anwendungsfall des vue-pinia-best-practices guide ist die Entscheidung, ob Daten überhaupt in Pinia gehören. Bitte den Assistenten, State in diese Kategorien einzuordnen:

• geteilter State auf App-Ebene
• lokaler Component-State
• URL-gestützter View-State wie Filter, Suche, Pagination und Sortierung

Hier liefert der Skill mehr Mehrwert als generische Pinia-Snippets, weil er hilft, die falsche Architektur zu vermeiden, bevor der Code anwächst.

Bestes Prompt-Muster für Repo-Reviews

Für vue-pinia-best-practices for Frontend Development sieht ein starker Audit-Prompt so aus:

• „Use the vue-pinia-best-practices skill to audit these files for Pinia gotchas. For each issue, label it as install timing, reactivity, setup-store return shape, or state-placement mistake. Show exact fixes and explain production impact.“

Dieses Framing lenkt das Modell stärker auf umsetzbare Findings statt auf abstrakte Ratschläge.

FAQ zum Skill vue-pinia-best-practices

Ist vue-pinia-best-practices gut für Einsteiger?

Ja, wenn du bereits mit Vue 3 entwickelst und angefangen hast, Pinia zu nutzen. Der Skill ist kompakt und problemorientiert, dadurch lässt er sich leichter anwenden als breit angelegte Dokumentation. Absolute Einsteiger brauchen unter Umständen trotzdem die offiziellen Pinia-Grundlagen zu Konzepten wie Stores, Getters und Actions.

Welche Probleme deckt der Skill vue-pinia-best-practices am besten ab?

Am stärksten ist er bei einer kleinen Zahl häufiger, aber folgenreicher Probleme:

• getActivePinia()-Fehler durch falsches Setup-Timing
• kaputte Reaktivität durch direktes Destructuring
• Setup-Stores, die nicht den gesamten State zurückgeben
• die Entscheidung, wann URL-Query-State besser ist als Store-State
• die Entscheidung, wann sich Pinia gegenüber selbstgebautem State lohnt

Ist das besser, als einfach normal nach Pinia-Hilfe zu fragen?

Für diese konkreten Themen meistens ja. Gewöhnliche Prompts erzeugen oft Code, der gut aussieht, aber Runtime-Details wie Plugin-Reihenfolge, SSR-Serialisierung oder storeToRefs() übersieht. Der vue-pinia-best-practices skill fokussiert das Modell auf erprobte Stolperfallen und passende Korrekturen.

Wann sollte ich vue-pinia-best-practices nicht verwenden?

Lass ihn weg, wenn deine Aufgabe hauptsächlich darin besteht:

• Vue von Grund auf zu lernen
• frameworkspezifisches Deployment-Setup zu lösen, das nichts mit Pinia zu tun hat
• fortgeschrittenes State-Machine-Design außerhalb des Repo-Scopes umzusetzen
• mit einem Nicht-Vue-Frontend-Stack zu arbeiten

Es ist ein gezielter Pinia-Guardrail-Skill, kein universeller Skill für Frontend-Architektur.

Hilft er bei Entscheidungen zur Vuex-Migration?

Indirekt ja. Das Repo stützt ausdrücklich die Sicht, dass Pinia der richtige Standard für größere Vue-Apps ist und dass Vuex im Maintenance Mode läuft. Der Skill ist nützlich, wenn du alte Vuex-Gewohnheiten in aktuelle Pinia-Patterns überführen willst – besonders bei einfacherer Store-Ergonomie und Tooling.

Kann vue-pinia-best-practices auch bei selbstgebauten Stores helfen?

Teilweise. Eine Referenz behandelt Method-Binding-Fallen in reaktiven Stores, und der Skill hilft auch dabei zu entscheiden, wann selbstgebauter State noch vertretbar ist. Sein Schwerpunkt liegt aber klar auf Pinia, nicht auf Custom-Store-Libraries.

So verbesserst du den Skill vue-pinia-best-practices

Gib dem Skill exakte Fehlersymptome

Um die Ausgabequalität von vue-pinia-best-practices zu verbessern, gib den genauen Fehlertext an, wo er auftritt und seit wann. Zum Beispiel:

• „Der Fehler tritt nur während der Router-Navigation auf“
• „DevTools zeigt ein ref aus meinem Setup-Store nicht an“
• „Die UI aktualisiert sich nicht mehr, nachdem ich den Store in <script setup> destructured habe“

Diese Hinweise mappen direkt auf die stärksten Empfehlungen im Repo.

Nenne Lifecycle und Dateigrenzen

Viele Pinia-Bugs sind in Wirklichkeit Timing-Bugs. Sag dem Assistenten, ob der Code ausgeführt wird:

• zur Modul-Import-Zeit
• in setup()
• in einem Router-Guard
• während des App-Bootstraps
• während der SSR-Hydration

Dieser Kontext hilft dem Skill, Probleme in der Install-Reihenfolge von gewöhnlichen Component-Bugs zu unterscheiden.

Liefere minimale, aber vollständige Code-Ausschnitte

Bessere Inputs enthalten meist:

• main.ts
• eine Router-Datei, wenn Guards Stores verwenden
• eine Store-Datei
• eine Component, die den Store konsumiert

Schicke nicht zuerst dein komplettes Repo. Eine enge Reproduktion beschleunigt die Diagnose und reduziert generischen Fülltext.

Bitte um Klassifizierung, nicht nur um einen Fix

Ein besonders ergiebiger Prompt ist:

• „Classify each issue by category, explain why it happens, then patch the code.”

Für diesen Skill sind gute Kategorien:

• Install-Timing
• Reaktivität
• Setup-Store-Return-Shape
• URL- vs. Store-State
• Skalierungs-/Architektur-Fit

So wird die Ausgabe leichter auf zukünftige Dateien übertragbar.

Fordere Vorher-/Nachher-Code an

Der vue-pinia-best-practices install-Schritt ist simpel verglichen mit der eigentlichen Adoptionsfrage: Verbessert der Skill wirklich deinen generierten Code? Am besten beurteilst du das, wenn du Folgendes anforderst:

• ein korrigiertes Code-Beispiel
• eine kurze Erklärung, warum das Original fehlschlug
• eine Checkliste, die du an anderer Stelle wiederverwenden kannst

So wird der Skill zu einem wiederholbaren Review-Werkzeug statt zu einer einmaligen Antwort.

Häufige Schwachstellen in den Outputs, auf die du achten solltest

Schwache Ergebnisse entstehen am ehesten, wenn die Eingabe zu ungenau ist. Beispiele:

• nach „Best Practices“ fragen, ohne Code oder Symptom zu liefern
• nicht angeben, ob der Store option-style oder setup-style ist
• das Router-Setup weglassen, obwohl das Problem mit dem Start zusammenhängt
• Anforderungen an persistente Filter beschreiben, ohne teilbare URLs zu erwähnen

Dann kann es passieren, dass der Assistent zwar richtige Hinweise gibt, aber dein konkretes Problem nicht löst.

Nach der ersten Antwort weiter iterieren

Nach der ersten Antwort solltest du eine zweite Runde anschließen, zum Beispiel mit:

• „Now scan for the same pattern in the rest of my stores.”
• „Convert this fix into a team convention.”
• „Show how this changes if the state should be shareable by URL.”
• „Add SSR and DevTools checks to the review.”

Das ist der einfachste Weg, aus vue-pinia-best-practices usage mehr herauszuholen als nur eine einzelne Korrektur.

Die Referenzen als Review-Regeln verwenden

Die Referenzdateien sind kompakt genug, um sie in Team-Checks für Code-Reviews zu überführen. Beispiele:

• kein useXxxStore() auf Modul-Top-Level
• Pinia vor dem Router installieren, wenn Guards Stores lesen
• den gesamten reaktiven State aus Setup-Stores zurückgeben
• storeToRefs() für das Destructuring von State/Gettern verwenden
• View-Filter in der URL halten, wenn Refresh/Teilen relevant ist

Das ist langfristig der beste Weg, um Ergebnisse mit vue-pinia-best-practices for Frontend Development zu verbessern: den Skill nicht nur zum Bugfixing nutzen, sondern um bessere Standards durchzusetzen, bevor die Fehler überhaupt entstehen.