Starten eines React-Webprojekts
Lies zuerst web-craft; dessen Regeln gelten auch hier. Die bestehenden Entscheidungen des Projekts haben Vorrang vor allen untenstehenden Standardwerten.
1. Aufnahme
Lies, was bereits gegeben ist: Produktbeschreibung, vorhandenes Repository, Seiten, Designsystem, STACK.md, DESIGN.md, API-Verträge. Fülle dann die Lücken mit references/intake.md: Oberflächentyp (Landing, Redaktion, Katalog, Consumer-App, Admin, Kundenportal oder Mischung), primärer Benutzer und Aktion, Inhalts- oder Betriebsdichte, Geräte, SEO-Anforderungen, Sprachen jetzt und später, RTL, Authentifizierung, Backend (Node.js, Drittanbieter-API, CMS, Mock oder statisch).
Frage nur nach, was eine Produkt- oder Architekturentscheidung ändert. Gib den Rest als Annahmen an.
2. Festlegen des technischen Profils
Schreibe jede Entscheidung mit einer einzeiligen Begründung. Erzeuge nicht jeden Bildschirm, bevor die Richtung gewählt ist.
| Entscheidung | Standard und wo die Begründung liegt |
|---|---|
| Framework und Rendering | Öffentlich, SEO- oder CMS-lastig, mehrsprachig → Next.js App Router. Hinter einem Login und hoch interaktiv → React + Vite oder das bestehende Next.js. Einfache statische Oberfläche → das Einfachste, was funktioniert. references/framework-choice.md |
| UI-Kit | Markenstarkes Produkt → shadcn/ui. Tabellen-/formularlastiges Admin → Ant Design. Material-artiges Produkt oder MUI bereits im Einsatz → Material UI. Bestehendes System → beibehalten. Ein Haupt-Kit pro App-Oberfläche. references/kit-choice.md |
| Styling | Folgt dem Kit: shadcn → Tailwind (von shadcn benötigt); Ant Design oder MUI → das Theme des Kits, plus CSS Modules für kundenspezifische Teile; benutzerdefiniert oder redaktionell → CSS Modules. Mische niemals Tailwind und CSS Modules als gleichberechtigte Systeme auf einer Oberfläche. references/styling-choice.md |
| i18n | Next.js → next-intl; Vite → i18next + react-i18next. Locale-Registry, Fallback, URL-Richtlinie und Katalog-Laden werden am ersten Tag festgelegt. references/i18n-setup.md |
| Animationen | CSS-Übergänge für einfache Zustände; Motion für React, wenn Mount/Unmount, Layout oder Orchestrierung benötigt wird. Dauer- und Easing-Tokens; reduzierte Bewegung an einer Stelle behandelt. references/motion-setup.md |
| Formulare und Daten | react-hook-form + Zod; TanStack Query oder das Datenmodell des Frameworks; behalten, was existiert. |
| Theme | Hell/Dunkel/System für interaktive Produkte; ein einzelnes Theme kann eine Produktentscheidung für eine markengeprägte Marketingseite sein. |
| Tests | Typecheck, Lint (mit eslint-plugin-web-craft und eslint-plugin-jsx-a11y), Unit-/Komponententests, wo Verhalten existiert, Playwright für kritische Abläufe. |
| Sprache und Tools | Strenges TypeScript, Yarn pro Projekt festgelegt, eine Lock-Datei. |
Überprüfe die aktuellen stabilen Versionen jedes gewählten Pakets von offiziellen Quellen am aktuellen Tag, pinne Versionen, die zusammenarbeiten, und notiere sie in STACK.md. Kopiere niemals Versionsnummern aus dem Gedächtnis oder aus diesem Skill.
3. Schreibe die Projektdokumente
STACK.md: Framework, Rendering, Kit, Styling, i18n-Engine, Daten- und Formularwerkzeuge, Versionen, Umgebungen, Skripte. Vorlage:references/stack-template.md.DESIGN.md: Produktcharakter, die aus Referenzen übernommenen Prinzipien, Layout, Tokens (Farbe, Schriftart, Abstand, Radius, Höhe, Bewegung), Kopierregeln, Bewegungsmatrix, i18n-Notizen. Vorlage:references/design-template.md.- Die Locale-Liste und -Typen stammen aus der Code-Konfiguration. Dokumente beschreiben sie; sie sind keine zweite Quelle der Wahrheit.
- Erstelle nicht vier neue Dokumente für jede kleine Änderung.
4. Lege das Projekt aus
Feature-basierte Struktur, klare Server-/Client-Grenzen, eine API-Schicht, ein Ort für Tokens und Provider: references/structure.md.
5. Beweise das Grundgerüst
Bevor weitere Bildschirme gebaut werden, muss ein kleiner Ablauf Ende-zu-Ende funktionieren:
- Das Locale wird beim ersten Rendern korrekt aufgelöst (kein Sprach-Flash), das Wechseln hält die Route.
- Das Theme folgt der Wahl des Benutzers und dem System, ohne einen Flash beim Laden.
- Ein Formular validiert bei Verlassen eines Feldes (on blur), scrollt beim Absenden zum ersten Fehler, ordnet einen Serverfehler seinem Feld zu.
- Ein Dialog animiert ein und aus, fängt den Fokus ein und gibt ihn zurück; reduzierte Bewegung entfernt die große Bewegung.
- Eine Liste oder ein Diagramm zeigt ein Skelett, einen leeren Zustand und einen Fehler mit Wiederholungsoption.
- Nur-Tastatur-Nutzung funktioniert; keine Konsolen- oder Hydrierungsfehler.
Baue dann einen repräsentativen vertikalen Ausschnitt (echt aussehender Inhalt, zweite Sprache, Lade- und Fehlerzustände) und überprüfe ihn in einem Browser bei Mobil- und Desktop-Breiten, bevor du auf andere Bildschirme erweiterst.
6. Skripte
dev, build, start (Next.js), typecheck, lint, test, test:e2e. Füge analyze hinzu, wenn Bundle-Budgets wichtig sind.
Quellen
Offizielle Links, die für diese Standardwerte verwendet wurden, mit dem Datum ihrer Überprüfung: references/sources.md. Überprüfe sie erneut für die Version, die du installierst.