template-rebrand

Rebrander un projet Next.js (et NestJS)

Suivez les étapes dans l'ordre. Chaque étape se termine par une vérification : exécutez-la, corrigez ce qu'elle trouve, et ne passez à la suite qu'après. VÉRIFICATION signifie cette commande, depuis la racine du projet :

node ${CLAUDE_SKILL_DIR}/scripts/rebrand-check.mjs check \
  --old "Ancien Nom" --old "Ancien nom dans chaque autre script" \
  --new "Nouveau Nom" --new "Nouveau nom dans chaque autre script"

Ajoutez --case quand l'ancien nom est un mot courant (MAGASIN), et --allow <chemin> pour un fichier qui conserve intentionnellement l'ancien nom. N'effectuez jamais un rechercher-remplacer aveugle.

0. Brief, cartographie et base de référence

1. Notez l'ancien nom sous toutes ses formes utilisées par le projet (chaque langue, slug, domaine email) et le nouveau nom dans chaque langue, la couleur de la marque, les fichiers logo et le ton. Si la demande omet un élément, choisissez une valeur raisonnable, continuez, et listez ce choix dans le rapport.
2. Exécutez node ${CLAUDE_SKILL_DIR}/scripts/rebrand-check.mjs map.
3. Exécutez une fois la commande de compilation de chaque application depuis la cartographie, avant toute modification.

Vérification : vous avez la cartographie, un nombre de résultats VÉRIFICATION à réduire, et un résultat pour chaque compilation. Une compilation qui échouait déjà est notée comme non causée par le rebranding.

1. Noms et mot-symbole

Fichiers de configuration de la marque, le composant logo, le manifeste de l'application web, et toute ligne de paramètres qu'une seed écrit (le nom d'expéditeur d'email y figure souvent). Laissez les noms de package, les noms de variables d'environnement, les noms de base de données, les volumes Docker et les préfixes de stockage inchangés sauf demande explicite : les renommer casse les installations et les données existantes.

Vérification : VÉRIFICATION affiche 0 résultats sous "brand config". Les résultats d'infrastructure que vous avez conservés sont listés dans le rapport.

2. Couleurs

Jetons de couleur dans les fichiers de thème listés par la cartographie, clair et sombre, plus la couleur du thème du navigateur dans le manifeste ou la fenêtre d'affichage. Aucune couleur n'est écrite dans un composant.

Vérification : VÉRIFICATION avec --old "#ancienhex" pour chaque ancienne couleur de marque affiche 0 résultats, et le texte sur la nouvelle couleur maintient un contraste de 4,5:1 dans les deux thèmes.

3. Logo et fichiers d'icônes

Remplacez le mot-symbole, le sigle, le favicon, les icônes d'application et l'image de partage listés par la cartographie. Conservez les noms et tailles de fichiers, ou mettez à jour chaque référence. Ouvrez chaque nouveau fichier et examinez-le.

Vérification : VÉRIFICATION signale 0 chemins d'image manquants dans public/, et aucun nom de fichier ou dossier avec l'ancien nom sauf ceux que vous avez intentionnellement conservés.

4. Contenu dans chaque langue

Réécrivez, ne vous contentez pas de renommer : héros, à propos, pied de page, mentions légales, support, SEO, et toute phrase qui décrit l'ancienne entreprise. Mêmes clés dans chaque langue, chaque langue rédigée de manière native.

Vérification : VÉRIFICATION affiche 0 résultats sous "messages", et aucun fichier de locale ou de message n'a le nouveau nom dans une langue mais pas dans une autre.

5. Métadonnées et SEO

Layouts racine et de page, generateMetadata, modèles de titre, champs Open Graph et Twitter, JSON-LD, sitemap, robots, name et short_name du manifeste.

Vérification : VÉRIFICATION affiche 0 résultats sous "metadata and SEO".

6. Emails

Nom d'expéditeur, sujets, en-tête et pied de page, liens, dans chaque langue que l'API envoie. L'adresse d'expéditeur et le domaine proviennent des variables d'environnement : listez-les dans le rapport.

Vérification : VÉRIFICATION affiche 0 résultats sous "emails".

7. Données de seed et de simulation

Seeders, fixtures et catalogues de simulation : produits, catégories, lignes de paramètres, domaines email des comptes de démonstration, chemins d'images. La seed de l'API et les données de simulation du frontend concordent.

Vérification : VÉRIFICATION affiche 0 résultats sous "seed data".

8. Compilation et vérification finale

Exécutez à nouveau la commande de compilation de chaque application. Corrigez les erreurs jusqu'à ce que chacune réussisse. Ne démarrez pas de serveur de développement ou de production sauf demande explicite.

Vérification : chaque compilation se termine avec le code 0, puis VÉRIFICATION affiche Result: PASS.

Rapport

Fichiers modifiés par étape, les choix faits pour tout élément omis dans le brief, chaque résultat autorisé et sa raison, les résultats des compilations, et ce qui reste à faire par une personne : domaine, DNS, expéditeur d'email, textes juridiques.