Frontend Project Bootstrap
Transforme un prototype UI/UX livré en « projet frontend standard de l'équipe + documentation complète + fiches de tâches prêtes à démarrer », afin que le code écrit par différentes personnes ou agents de codage semble sortir de la même main.
Version : voir la première entrée de CHANGELOG.md.
Principes fondamentaux
- Le prototype est une source d'exigences, pas du code à copier dans le projet. On en extrait les écrans, les données, les couleurs et les interactions, mais on ne reproduit pas son implémentation ; le fichier original et les captures d'écran sont conservés dans le dépôt comme critères de validation.
- Les règles d'équipe sont copiées à l'identique, le contenu du projet est rempli à partir du prototype. Les deux types de fichiers sont traités différemment (voir « Index des fichiers » ci-dessous).
- En cas de doute, on demande – on ne devine jamais. Les questions sont posées par série de points d'arrêt, chaque question étant accompagnée d'une réponse suggérée ; un « oui » signifie qu'on adopte la suggestion.
- Aucune implémentation de fonctionnalité métier. Ce skill crée uniquement le squelette, les pages vides et la documentation ; les fonctionnalités métier seront développées ultérieurement via
/implementà partir des fiches de tâches. - La validation est obligatoire pour terminer. Lint, typecheck, tests et build doivent être entièrement verts, aucun placeholder résiduel, et chaque écran doit avoir sa capture.
Entrées requises
- Le prototype (un seul HTML, plusieurs pages HTML, un lien vers un fichier de conception ou des captures d'écran) avec sa version et sa date de livraison
- Le nom du projet et une phrase de description
- L'emplacement du dossier du nouveau projet (doit être un dossier vide ou un nouveau dépôt ; s'arrêter et confirmer s'il contient déjà du contenu)
Les informations restantes (environnement de déploiement, état du backend, langue, mode sombre) sont demandées à l'étape 1 ; voir les détails dans references/workflow-detail.md.
Préparation (une fois par machine)
cd <skill> && npm ci && npx playwright install chromium # Playwright et Prettier pour scripts/ ; pas dans le squelette du projet
# Si Chromium est déjà installé sur la machine, on peut ignorer le téléchargement et utiliser CHROMIUM_EXECUTABLE=<chemin> pour les scripts de capture
Processus
Créer une liste de tâches pour suivre les cinq étapes ci-dessous ; cocher chaque étape une fois terminée.
Étape 1 : Réception
Vérifier d'abord que le dossier du projet n'existe pas ou est vide (s'il contient du contenu, s'arrêter et demander). Ensuite, confirmer le fichier prototype, sa version et l'emplacement de stockage partagé par l'équipe,
demander les éléments non encore fournis dans les informations du tableau de l'étape 1 de references/workflow-detail.md.
Étape 2 : Analyse du prototype et captures d'écran
Lire references/prototype-analysis.md, suivre sa méthode, produire docs/_bootstrap/prototype-analysis.md
(format : templates/prototype-analysis.md). Si le prototype est au format HTML, placer le fichier original dans docs/prototype/,
remplir docs/prototype/screens.json (format : templates/prototype-screens.json), puis exécuter le script de capture pour produire un PNG de chaque écran.
⏸ Point d'arrêt : Poser les questions par série selon le « point d'arrêt » de references/prototype-analysis.md : points à confirmer, comportement par défaut pour les états manquants,
mode de routage (history / hash), état actuel du backend. Après avoir reçu les réponses, les inscrire dans les sections 11 et 12 du fichier d'analyse, puis continuer.
Étape 3 : Création du squelette
Copier assets/skeleton/ (en excluant node_modules), exécuter npm ci, puis suivre l'étape 3 de references/workflow-detail.md
pour modifier le nom, les couleurs, le mode de routage, les routes et le menu, les pages vides, et les codes de permission. Conserver la fonctionnalité d'exemple « Item » jusqu'à ce que la première fonctionnalité réelle soit terminée.
Étape 4 : Production de la documentation
Suivre le tableau de correspondance de l'étape 4 de references/workflow-detail.md pour copier et remplir. Tous les <!-- FILL: --> doivent être complétés selon leurs instructions et les commentaires supprimés,
tous les {{PLACEHOLDER}} doivent être remplacés. Si on ne sait pas, écrire « À confirmer », sans inventer.
Étape 5 : Validation, commit et rapport
npm run lint && npm run typecheck && npm test && npm run build
node <skill>/scripts/check-placeholders.mjs <project>
Les quatre vérifications doivent être entièrement vertes (lint sans warning) et le script de contrôle doit donner 0 ERREUR pour terminer ; ensuite, effectuer le premier commit.
Format du rapport voir étape 5 de references/workflow-detail.md.
Lorsque l'utilisateur n'est pas présent : adopter les réponses suggérées en les marquant « Adopté (provisoire) », et pour celles sans suggestion, écrire « À confirmer » et continuer normalement ; les deux cas sont listés dans le rapport. Le seul cas où il faut s'arrêter est lorsque le dossier du projet contient déjà du contenu.
Index des fichiers
Copiés à l'identique (seul le nom peut être changé, le contenu ne doit pas être modifié)
| Chemin | Copié vers | Contenu |
|---|---|---|
assets/skeleton/ | Racine du projet | Squelette exécutable : fichiers de configuration, couche API, hooks de données, DataBoundary, permissions, i18n, theme, MSW, tests, CI (Azure DevOps), modèle de PR, fonctionnalité d'exemple Item |
references/standards/ | docs/conventions/ | 18 documents de normes de développement d'équipe + index |
references/adr-baseline/ | docs/adr/ | ADR 0001–0016 + index |
templates/agents/ | docs/agents/ | Configuration tracker et domain docs pour les skills de mattpocock (local markdown, single-context) |
Remplis à partir du prototype
| Modèle | Produit |
|---|---|
templates/prototype-analysis.md | docs/_bootstrap/prototype-analysis.md |
templates/prototype-screens.json | docs/prototype/screens.json (entrée pour le script de capture) |
templates/README.md, AGENTS.md, ARCHITECTURE.md, GLOSSARY.md | Racine du projet |
templates/CLAUDE.md | Racine du projet (fichier relais pour Claude Code : une ligne de commentaire puis @AGENTS.md, copié à l'identique) |
templates/prototype-README.md | docs/prototype/README.md |
templates/adr-router-mode.md | docs/adr/0017-router-mode.md |
templates/api-interface-auth.md, api-interface.md, api-checklist.md | docs/api/ |
templates/feature-spec.md | docs/specs/<feature>.md |
templates/task.md, tasks-README.md, task-remove-example.md | docs/tasks/ |
templates/adr.md, bug-report.md, etc. | Copier une copie dans docs/templates/ pour usage ultérieur |
Documentation et outils
| Chemin | Quand le lire |
|---|---|
references/workflow-detail.md | Instructions détaillées, commandes et correspondance des fichiers pour chaque étape |
references/prototype-analysis.md | Étape 2 |
scripts/screenshot-prototype.mjs | Étape 2 (à relancer si le prototype est mis à jour) |
scripts/check-placeholders.mjs | Étape 5 |
Intégration avec les skills de mattpocock
La sortie de ce skill est l'entrée des mattpocock/skills ; le projet n'a pas besoin d'exécuter /setup-matt-pocock-skills
(si exécuté, il ne ferait que mettre à jour ## Agent skills dans AGENTS.md et docs/agents/, ne pas le laisser écrire dans CLAUDE.md).
| Son skill | Correspond ici |
|---|---|
/grill-with-docs, grilling | Le point d'arrêt de l'étape 2 est le même type d'entretien ; pour modifier le design plus tard, l'utiliser directement ; les termes vont dans GLOSSARY.md, les décisions dans docs/adr/0018+ |
domain-modeling | Lit et écrit GLOSSARY.md (même format) et docs/adr/ (format d'équipe, voir docs/agents/domain.md) |
/to-spec, /to-tickets | Ne pas utiliser. Les spécifications sont déjà dans docs/specs/ (numérotation Gherkin), les tâches dans docs/tasks/ (avec chemins de fichiers par couche et composants réutilisables) |
/implement | Mode d'implémentation de la première version : une fiche de tâche docs/tasks/<ID>-*.md à la fois, depuis main vers une branche écrite dans la fiche ; il appelle tdd et code-review |
tdd | Les seams sont déjà écrits dans « Seams de test » de AGENTS.md, pas besoin d'en discuter |
/implement-spec | Utilisable mais pas encore testé : chaque worktree nécessite npm ci (husky prepare), Azure DevOps n'a pas d'intégration de PR brouillonne |
Compatibilité des outils Agent
AGENTS.md est la seule source de règles. OpenCode et Kimi Code CLI lisent directement AGENTS.md à la racine du projet ;
Claude Code lit CLAUDE.md, donc le squelette fournit un fichier relais contenant uniquement @AGENTS.md. N'écrivez pas d'autres règles dans ce fichier relais.
Mise à jour de ce skill
Pour modifier les normes d'équipe, mettez à jour ce skill (standards, adr-baseline, skeleton en même temps), enregistrez dans CHANGELOG.md et montez de version ;
ne modifiez pas uniquement dans un projet individuel. Les écarts dans un projet particulier sont documentés dans son ADR (à partir de 0017).
Après avoir modifié le squelette, exécutez impérativement lint, typecheck, tests et build dans assets/skeleton/ ; après avoir modifié du Markdown, exécutez npm run format.