Sync Template

sync-template — récupérer les évolutions du template dans un repo client

Cette skill s'exécute dans un repo client (fork/dérivé du template, déjà personnalisé pour {{COMPANY_NAME}}). Objectif : récupérer les améliorations de mécanique du template public sans jamais écraser la personnalisation de marque.

Principe de séparation

Préflight

1. Vérifier qu'on est bien dans un repo client : .setup-completed existe. Si absent → ce repo EST probablement le template, sync inutile ; s'arrêter.
2. git status — l'arbre de travail doit être propre. Sinon, demander de committer ou stasher d'abord.
3. Vérifier le remote : git remote -v. Si upstream manque, proposer :

   bashCopy code
   git remote add upstream <URL du template public>
   

   (demander l'URL à l'utilisateur, ne pas la deviner).
4. Noter la branche courante et le SHA de départ (git rev-parse HEAD) pour pouvoir revenir en arrière.

Workflow

Étape 1 — Fetch et diff résumé (AVANT tout merge)

bashCopy code
git fetch upstream
git log --oneline HEAD..upstream/main        # commits à intégrer
git diff --stat HEAD...upstream/main         # fichiers touchés

Présenter à l'utilisateur un résumé lisible : nombre de commits, thèmes (nouvelles skills, fixes de scripts, docs...), liste des fichiers modifiés groupés par dossier.

Étape 2 — Alerte fichiers de marque

Contrôler le diff entrant :

bashCopy code
git diff --name-only HEAD...upstream/main | grep -E '^(01-brand/|profile/)' || true

Si des fichiers de 01-brand/ ou profile/ apparaissent : 🔴 ALERTE bloquante. Ces fichiers contiennent la marque du client et ne devraient jamais venir d'upstream (au pire, upstream modifie ses gabarits _templates/brand/, pas 01-brand/). Expliquer le risque, et proposer :

• exclure ces chemins du merge (les restaurer depuis HEAD juste après le merge), option par défaut ;
• ou, si l'utilisateur confirme que c'est un changement de structure voulu, l'intégrer en re-personnalisant manuellement.

Ne jamais merger silencieusement un changement upstream sur ces dossiers.

Étape 3 — Merge

Avec l'accord explicite de l'utilisateur :

bashCopy code
git merge upstream/main

• Merge propre → passer à l'étape 5.
• Conflits → étape 4.

Étape 4 — Résolution guidée des conflits

Pour chaque fichier en conflit (git diff --name-only --diff-filter=U), appliquer la grille :

Montrer chaque conflit à l'utilisateur avec la résolution proposée et sa justification ; appliquer après validation. Terminer par git merge --continue (jamais de --force, jamais de reset --hard sans confirmation explicite — cf. SECURITY.md).

Étape 5 — Vérification après merge

1. git diff --stat <SHA de départ>..HEAD — récapituler ce qui a réellement changé.
2. Confirmer que 01-brand/ et profile/ sont identiques à l'état de départ (git diff <SHA de départ> HEAD -- 01-brand/ profile/ doit être vide, sauf choix explicite contraire).
3. Chercher des placeholders réintroduits par upstream : grep -rn "{{" --include="*.md" .claude/ CLAUDE.md — si des {{...}} apparaissent dans des fichiers censés être personnalisés, les re-remplir avec les valeurs de .setup-completed / 01-brand/.
4. Si de nouvelles skills ou commandes sont arrivées, les lister à l'utilisateur avec une ligne de description.
5. Proposer un /health-check si le merge a touché _integrations/, hooks ou scripts.

En cas de problème

Retour arrière propre (avec confirmation) : git merge --abort pendant le merge ; après coup, créer une branche de secours puis git reset --keep <SHA de départ>.

Ce que cette skill ne fait PAS

• ❌ Remonter une amélioration client vers le template (→ backport-to-template, le sens inverse)
• ❌ git push automatique — l'utilisateur pousse lui-même après vérification