sync-project-docs
Audite et met à jour les fichiers de contexte du projet de Claude Code. Autonome pour CLAUDE.md, les compétences et la mémoire ; suggère des modifications pour les paramètres, car celles-ci nécessitent une autorisation explicite de l'utilisateur.
Phase 1 — Orientation
Si le projet utilise Git :
git log --oneline -20
git status --short
Ensuite git diff HEAD~5 -- <fichiers clés ci-dessous> pour voir les modifications récentes de l'infrastructure.
S'il n'y a pas de dépôt Git, lisez directement la structure du répertoire et les fichiers clés.
Trouvez lesquels de ces éléments existent :
| Rechercher | Exemples |
|---|---|
| Configuration des dépendances/paquets | package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml, requirements.txt, Gemfile |
| Commandes | Makefile, justfile, scripts/, scripts package.json, taskfile.yml |
| Infrastructure | docker-compose.yml, fly.toml, render.yaml, Procfile, vercel.json, k8s/ |
| Configuration de l'application | config.*, settings.*, config/, application.yml |
| Modèle .env | .env.example, .env.template, .env.sample |
Objectif : savoir quel travail a été effectué, ce qui est en cours et quels fichiers clés ont changé.
Phase 2 — Audit et mise à jour de CLAUDE.md
Vérifiez tous les fichiers d'instructions au niveau du projet :
ls CLAUDE.md .claude/CLAUDE.md CLAUDE.local.md .claude/rules/ 2>/dev/null
Si CLAUDE.md n'existe pas : invoquez la compétence init dans sub-skills/init/SKILL.md, puis continuez.
Si CLAUDE.md existe, lisez-le et vérifiez chaque section par rapport aux sources de la Phase 1 :
Commandes — comparez avec la source réelle des commandes. Corrigez les commandes modifiées, ajoutez les nouvelles utiles, supprimez les supprimées.
Architecture/structure — comparez les modules décrits et les fichiers clés avec ce qui existe sur le disque. Ajoutez les nouvelles entrées ; supprimez les éléments supprimés ou renommés.
Configuration/variables d'environnement — comparez avec les fichiers de configuration réels. Ajoutez les nouveaux paramètres pertinents au moment de l'exécution ; supprimez ou corrigez les éléments obsolètes.
Contraintes et pièges — vérifiez si des contraintes documentées ont été résolues par un travail récent.
Modèle .env : vérifiez qu'il liste toutes les variables requises par la configuration. Des variables manquantes ici rompent les configurations fraîches.
Références @import : parcourez les lignes @chemin/vers/fichier et vérifiez que chaque fichier importé existe encore. Une importation manquante interrompt silencieusement le chargement du contexte.
Taille : si le fichier dépasse 200 lignes, signalez-le — au-delà, la conformité diminue et le coût du contexte augmente. Suggérez de déplacer les détails dans des fichiers thématiques .claude/rules/.
.claude/rules/ : si ce répertoire existe, vérifiez si des fichiers de règles associés à des chemins référencent des commandes, des noms de modules ou des chemins de fichiers qui ne correspondent plus à la base de code actuelle. Corrigez ou signalez ceux qui sont obsolètes.
CLAUDE.local.md : s'il existe, appliquez-lui le même traitement qu'à CLAUDE.md — c'est un complément personnel ignoré par Git et il peut aussi devenir obsolète.
Soyez chirurgical : mettez à jour ce qui est obsolète, laissez le contenu exact intact. Il sera lu par une future session Claude.
Phase 3 — Audit des compétences du projet
ls .claude/skills/ 2>/dev/null
Lisez chaque compétence. Deux catégories :
Compétences couplées à l'infrastructure (exécution, déploiement, migration, CI, intégration) référencent des éléments concrets — commandes, services, ports, variables d'environnement, chemins de fichiers. Vérifiez chacune par rapport à la Phase 1 :
- Les commandes référencées existent-elles toujours ?
- Les noms de services, ports et URLs correspondent-ils toujours ?
- Les variables d'environnement existent-elles toujours dans la configuration ?
- Les chemins de fichiers et noms de modules sont-ils toujours valides ?
Corrigez les petites divergences directement. Pour une refonte substantielle d'une compétence d'exécution/démarrage (nouvelle séquence de démarrage, changements majeurs des services), demandez d'abord :
« La compétence d'exécution semble significativement obsolète. La régénérer à partir de zéro avec
/run-skill-generator(risque de perdre les pièges personnalisés) ou réécrire les sections obsolètes manuellement ? »
S'il n'existe pas de compétence d'exécution et que le démarrage est non trivial : suggérez /run-skill-generator si disponible, ou /run en solution de repli.
Compétences de processus/workflow (modèles de PR, style de commit) : vérifiez uniquement si le journal Git suggère que le processus décrit a changé ; sinon, laissez-les tranquilles.
Phase 4 — Mémoire
Le chemin de la mémoire est dérivé de la racine du dépôt Git (ou de pwd en dehors d'un dépôt) :
REPO=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
echo "$HOME/.claude/projects/$(echo "$REPO" | sed 's|/|-|g')/memory/"
Si la mémoire existe : invoquez consolidate-memory.
Si elle n'existe pas : demandez avant de créer quoi que ce soit —
« Aucune mémoire de projet n'existe encore. La mémoire automatique est déjà activée, donc Claude la construira avec le temps — mais voulez-vous que je l'alimente maintenant avec les faits clés de cette base de code pour que votre prochaine session démarre tout de suite orientée ? »
Si oui : alimentez avec des faits non évidents qu'une future session passerait du temps à redécouvrir :
- Contraintes surprenantes (modèles de concurrence, versions bloquées, valeurs par défaut inattendues)
- Travail en cours actuel et pourquoi
- Décisions non évientes intégrées dans le code
Créez MEMORY.md comme un index concis d'une ligne par entrée. Les notes détaillées vont dans des fichiers thématiques séparés (par exemple architecture.md, constraints.md) — MEMORY.md reste en dessous de 200 lignes pour tenir dans la fenêtre de contexte de la session.
Phase 5 — Paramètres
Vérifiez .claude/settings.json pour des hooks obsolètes référençant des scripts ou commandes qui n'existent plus.
Identifiez les commandes en lecture seule qui reviennent constamment (lanceurs de tests, linters, vérifications de santé, git log, git diff) et qui pourraient être autorisées sans invite.
N'écrivez pas dans settings.json — présentez-les comme des suggestions. Pointez vers :
update-config: pour ajouter des permissions, des variables d'environnement ou corriger des hooksfewer-permission-prompts: pour découvrir les permissions à partir de l'historique réel des transcriptions
Phase 6 — Compact
Tous les résultats sont maintenant sur le disque. Avant de terminer, rappelez à l'utilisateur de gérer le contexte en exécutant la commande /compact pour repartir d'un état frais.
Résumé
Affichez un résumé des changements :
## Synchronisation du projet terminée
**CLAUDE.md** : <ce qui a changé, ou « aucune modification nécessaire »>
**Compétences** : <ce qui a été mis à jour, ou « exact »>
**Mémoire** : <consolidée / alimentée / « aucune modification »>
**Suggestions de paramètres** : <autorisations suggérées, ou « rien à ajouter »>
**État Git** : <fichiers non commités + travail en cours, une phrase>
Exécutez `git diff` pour passer en revue les modifications de fichiers.