Démarrer un projet web React
Lisez d'abord web-craft ; ses règles s'appliquent ici. Les décisions existantes du projet prévalent sur toutes les valeurs par défaut ci-dessous.
1. Récolte
Lisez ce qui est déjà donné : description du produit, dépôt existant, pages, système de design, STACK.md, DESIGN.md, contrats API. Ensuite, remplissez les lacunes avec references/intake.md : type de surface (page d'accueil, éditoriale, catalogue, application grand public, admin, portail client ou un mélange), utilisateur et action principaux, densité de contenu ou d'opérations, appareils, besoins SEO, langues actuelles et futures, RTL, authentification, backend (Node.js, API tierce, CMS, mock ou statique).
Ne demandez que ce qui modifie une décision produit ou architecture. Énoncez le reste comme des hypothèses.
2. Décider du profil technique
Écrivez chaque décision avec une raison en une ligne. Ne générez pas chaque écran avant que la direction ne soit choisie.
| Décision | Valeur par défaut et où se trouve le raisonnement |
|---|---|
| Framework et rendu | Public, SEO ou CMS lourd, multilingue → Next.js App Router. Derrière une connexion et hautement interactif → React + Vite ou le Next.js existant. Surface statique simple → la solution la plus simple qui fonctionne. references/framework-choice.md |
| Bibliothèque d'interface (UI kit) | Produit de marque distinctif → shadcn/ui. Admin lourd en tableaux/formulaires → Ant Design. Produit de style Material ou MUI déjà utilisé → Material UI. Système existant → conservez-le. Une bibliothèque principale par surface d'application. references/kit-choice.md |
| Style | Suit la bibliothèque : shadcn → Tailwind (requis par shadcn) ; Ant Design ou MUI → le thème de la bibliothèque, plus des Modules CSS pour les pièces personnalisées ; personnalisé ou éditorial → Modules CSS. Ne mélangez jamais Tailwind et Modules CSS comme systèmes équivalents sur une même surface. references/styling-choice.md |
| i18n | Next.js → next-intl ; Vite → i18next + react-i18next. Le registre de locale, le repli, la politique d'URL et le chargement du catalogue sont décidés dès le premier jour. references/i18n-setup.md |
| Animation (Motion) | Transitions CSS pour les états simples ; Motion pour React lorsque le montage/démontage, la disposition ou l'orchestration est nécessaire. Jetons de durée et d'assouplissement ; la réduction de mouvement gérée en un seul endroit. references/motion-setup.md |
| Formulaires et données | react-hook-form + Zod ; TanStack Query ou le modèle de données du framework ; conservez ce qui existe. |
| Thème | Clair/Foncé/Système pour les produits interactifs ; un thème unique peut être une décision produit pour un site marketing de marque. |
| Tests | Vérification de types, lint (avec eslint-plugin-web-craft et eslint-plugin-jsx-a11y), tests unitaires/de composants là où se trouve le comportement, Playwright pour les flux critiques. |
| Langage et outils | TypeScript strict, Yarn épinglé par projet, un fichier de verrouillage. |
Vérifiez les versions stables actuelles de chaque package choisi à partir des sources officielles le jour même, épinglez les versions qui fonctionnent ensemble, et enregistrez-les dans STACK.md. Ne copiez jamais les numéros de version de mémoire ou à partir de ce skill.
3. Rédiger les documents du projet
STACK.md: framework, rendu, bibliothèque d'interface, style, moteur i18n, outils de données et formulaires, versions, environnements, scripts. Modèle :references/stack-template.md.DESIGN.md: caractère du produit, les principes tirés des références, mise en page, jetons (couleur, typographie, espacement, rayons, élévation, mouvement), règles de copie, matrice de mouvement, notes i18n. Modèle :references/design-template.md.- La liste des locales et les types proviennent de la configuration du code. Les documents les décrivent ; ils ne sont pas une seconde source de vérité.
- Ne créez pas quatre nouveaux documents pour chaque petite modification.
4. Organiser le projet
Structure basée sur les fonctionnalités, limites serveur/client claires, une couche API, un endroit pour les jetons et les fournisseurs : references/structure.md.
5. Valider le squelette
Avant de construire plus d'écrans, un petit flux doit fonctionner de bout en bout :
- La locale se résout correctement au premier rendu (pas de flash de langue), le changement conserve la route.
- Le thème suit le choix de l'utilisateur et le système, sans flash au chargement.
- Un formulaire valide au blur, défile vers la première erreur lors de la soumission, associe une erreur serveur à son champ.
- Une boîte de dialogue s'anime à l'ouverture et à la fermeture, piège le focus et le restitue ; la réduction de mouvement supprime le grand mouvement.
- Une liste ou un graphique affiche un squelette, un état vide et une erreur avec réessai.
- L'utilisation uniquement au clavier fonctionne ; aucune erreur console ou d'hydratation.
Construisez ensuite une tranche verticale représentative (contenu réaliste, deuxième langue, états de chargement et d'erreur) et vérifiez-la dans un navigateur aux largeurs mobile et desktop avant de l'étendre à d'autres écrans.
6. Scripts
dev, build, start (Next.js), typecheck, lint, test, test:e2e. Ajoutez analyze lorsque les budgets de bundle comptent.
Sources
Liens officiels utilisés pour ces valeurs par défaut, avec la date à laquelle ils ont été vérifiés : references/sources.md. Re-vérifiez-les pour la version que vous installez.