Frontend-Entwicklung-Skill

Senior-Level, pragmatische, produktionsreife Frontend-Entwicklung. Ziel ist stets funktionierender, wartbarer, performanter Code – nicht akademische Reinheit.

Stack-Erkennung

Identifiziere zuerst den Stack aus dem Kontext. Falls unklar, frage nach. Lade dann die entsprechende Referenzdatei.

Stack	Laden
React (ohne GraphQL)	`references/react.md`
React + GraphQL/Relay	`references/react-graphql.md`
Angular	`references/angular.md`
TypeScript (alle Stacks)	`references/typescript.md` (zusammen mit der Stack-Datei laden)

Lade immer references/typescript.md zusätzlich zur Stack-Datei, es sei denn, das Projekt ist explizit nur JavaScript.

Universelle Prinzipien

Diese gelten unabhängig vom Stack. Überspringe sie nicht.

Architektur

Belange strikt trennen: UI-Rendering, Geschäftslogik, Datenabruf und Seiteneffekte leben in verschiedenen Schichten. Komponenten sollten keine Fetch-Aufrufe, rohe API-Strings oder Geschäftsregeln enthalten.
Nach Feature ko-lokalisieren, nicht nach Typ: Bevorzuge features/user-profile/ mit Komponente + Hook + Test + Styles gegenüber globalen Ordnern wie components/, hooks/, tests/. Passe die Struktur der Komplexität der App an – über-ingenieure keine kleine App.
Komposition vor Vererbung: Baue UIs durch Komposition kleiner, fokussierter Komponenten. Vermeide tiefe Komponentenhierarchien.
Keine vorzeitige Abstraktion: Schreibe die Sache zweimal, dann abstrahiere. Eine Abstraktion, die auf einem einzigen Anwendungsfall basiert, ist meist falsch.

Komponenten-Design

Komponenten sollten eine Sache tun. Hat eine Komponente mehr als einen Grund zur Änderung, teile sie auf.
Trenne Präsentationskomponenten (reine UI, keine Seiteneffekte) von Container-/Smart-Komponenten (Daten, Logik, Orchestrierung).
Props-Interfaces sollten explizit und typisiert sein. Kein any, kein object, kein {} als Typ.
Verwende standardmäßig kontrollierte Komponenten für Formulare.

Performance (nicht verhandelbare Baselines)

Core-Web-Vitals-Ziele (gemessen am 75. Perzentil der echten Nutzer):

LCP ≤ 2,5s (Ladezeit)
INP ≤ 200ms (Interaktivität – ersetzte FID im März 2024)
CLS ≤ 0,1 (visuelle Stabilität)

Universelle Performance-Regeln:

Blockiere niemals den Haupt-Thread mit langen synchronen Aufgaben
Lade Routen und schwere Komponenten standardmäßig lazy
Setze explizite Abmessungen für alle Bilder und Medien (verhindert CLS)
Verwende fetchpriority="high" für LCP-Bilder
Schiebe nicht-kritische Third-Party-Skripte auf
Vermeide Layout-Thrashing (Bünde DOM-Lese- und Schreiboperationen)
Aktiviere bfcache-Eignung: vermeide unload-Listener, vermeide no-store wo unnötig

Designsysteme & Tokens

Definiere Design-Tokens (Farbe, Abstand, Typografie, Radius, Schatten) als grundlegende Wahrheit – hämmere niemals Werte in Komponenten
Verwende CSS-Custom-Properties (--color-primary) oder ein Token-System (Style Dictionary, Tailwind-Konfiguration), damit Theming zentralisiert ist
Atomic Design als mentales Modell: Atoms → Molecules → Organisms → Templates → Pages. Erzwinge die Namensgebung nicht, aber denke in dieser Hierarchie
Dokumentiere Komponenten in Storybook für Isolation, Auffindbarkeit und visuelles Regression-Testen
Barrierefreiheit ist nicht optional: WCAG 2.1 AA Minimum. Jedes interaktive Element benötigt Tastaturunterstützung, Fokus-Management und ARIA, wo semantisches HTML nicht ausreicht

API-Integration

Rufe APIs niemals direkt aus Komponenten auf. Verwende eine Datenschicht: eigene Hooks, Services oder eine Query-Bibliothek
Behandle alle drei Zustände explizit: Laden, Fehler, Erfolg – gehe niemals vom Happy Path aus
Verwende optimistische Updates für die vom Benutzer wahrgenommene Performance bei Mutationen
Validiere API-Antworten an der Grenze (Zod, io-ts oder Äquivalent) – vertraue nicht auf die externe Datenstruktur
Zentrale API-Basis-URLs und Auth-Token-Injektion – verteile sie niemals über Komponenten

Teststrategie

Dreischichtiger Ansatz:

Unit-Tests: Reine Funktionen, Hilfsfunktionen, eigene Hooks (Jest / Vitest)
Komponententests: Rendering-Verhalten, Benutzerinteraktionen, Zustandsänderungen (Testing Library – teste Verhalten, nicht Implementierung)
E2E-Tests: Nur kritische Benutzerpfade (Playwright oder Cypress)

Regeln:

Teste das Verhalten aus der Perspektive des Benutzers, nicht die interne Implementierung
Keine Snapshots für Logik – sie sind spröde. Verwende Snapshots nur für absichtliches visuelles Regression-Testing
Strebe hohe Abdeckung für Geschäftslogik an, nicht für Boilerplate
Ko-lokiere Testdateien mit dem getesteten Code: Button.test.tsx neben Button.tsx

Code-Navigation (tsserver)

Der allgemeine LSP-über-Textsuche-Workflow lebt im dev-standards-Skill („Code-Navigation“). TypeScript-spezifische Hinweise:

Das LSP-Tool leitet an tsserver für TS/TSX weiter. Single-File-Operationen sind zuverlässig kalt: documentSymbol, hover, goToDefinition.

Achtung – tsserver indexiert träge (anders als gopls). Eine dateiübergreifende Abfrage (findReferences/workspaceSymbol), die gegen einen kalten Server ausgeführt wird, kann leise unterzählen: Sie kennt nur die Dateien, die bereits in ihr Projekt geladen wurden, und gibt ein selbstbewusstes, aber unvollständiges Ergebnis zurück (z. B. nur die Deklaration). Schütze dich davor:

Behandle eine verdächtig niedrige Referenzanzahl als unbestätigt.
Frage findReferences von einer Verwendungsstelle aus (einer Datei, die das Symbol importiert), nicht nur von der Deklaration – dies zwingt den Projektgraphen zum Laden.
Für Entscheidungen wie „Wird das noch irgendwo verwendet?“ (Totcode-Entfernung, sichere Umbenennungen) bestätige mit grep – eine Unterzählung ist hier gefährlich.

Tooling-Standards (2025)

Bundler: Vite (Standard für neue Projekte); Webpack 5 für große Enterprise-Setups, die es bereits verwenden
Linting: ESLint + @typescript-eslint + Prettier (Formatierung getrennt von Linting)
Paketmanager: pnpm bevorzugt für Monorepos; npm oder yarn akzeptabel
Monorepo: Nx oder Turborepo für Multi-Package-Workspaces
CI: Führe Typ-Prüfung, Lint, Test und Build bei jedem PR aus. Führe niemals rote Pipelines zusammen.

Ausgabemodi

Befolge diese Richtlinien bei der Ausgabe:

Komponenten-Code: Enthält Typen, behandelt Randfälle, folgt den Mustern des Stacks aus der Referenzdatei. Gib die Komponente + ihren Test in derselben Antwort, es sei denn, die Größe verbietet es.

Architektur / Dateistruktur: Zeige zuerst den Verzeichnisbaum, erkläre dann die Begründung. Sei meinungsstark – gib eine gute Struktur, kein Menü mit Optionen.

Performance-Audit: Liste die Ergebnisse nach Schweregrad (Kritisch / Warnung / Info). Zu jedem Ergebnis: Was es ist, warum es wichtig ist, wie man es behebt.

Designsystem-Einrichtung: Token-Struktur zuerst, dann Komponenten-Primitive, dann Dokumentations-Setup.

API-Integration: Zeige das Datenebenenmuster für den spezifischen Stack, dann die verbrauchende Komponente.

Testen: Zeige Tests neben dem getesteten Code. Befolge AAA (Arrange / Act / Assert).

Begleitskill

Dieses Skill behandelt Engineering. Für visuelle Ästhetik – Typografie-Auswahl, Farbsysteme, Bewegungsdesign, räumliche Komposition und Vermeidung generischer KI-Ästhetik – verweise auf das frontend-design-Skill. Bei Aufgaben, die beides erfordern (z. B. „Erstelle ein Dashboard, das großartig aussieht“), verwende beide Skills zusammen: frontend-dev für Architektur und Code-Qualität, frontend-design für visuelle Ausrichtung.

Referenzdateien

Lies diese, bevor du stack-spezifische Ausgaben erstellst:

references/typescript.md – TypeScript Strict Mode, Patterns, häufige Fallstricke
references/react.md – React 19, Next.js, Hooks, State Management, Rendering-Strategien
references/react-graphql.md – Relay, kollokierte Fragmente, GraphQL-Muster in React
references/angular.md – Angular v22, Signals, Standalone Components, zoneless, NgRx

Frontend-Entwicklung

Was ist Frontend-Entwicklung?

In Ihrer bevorzugten KI fragen

Dokumentation