Formation Claude Code avec PHP

La base : CLAUDE.md

Le fichier que Claude lit à chaque session. L'essentiel du cours tient à ce qu'on n'y met pas.

• Les trois niveaux et leur portée : le vôtre pour tous vos projets, celui du dépôt pour l'équipe, le local pour vos réglages personnels non versionnés.
• Ce qui y a sa place : les conventions du projet, ses pièges, les règles de jugement.
• Ce qui n'y a pas sa place : une consigne qui doit s'appliquer à tous les coups — elle relève d'un hook — et la documentation de référence, qui se lit à la demande.
• Rédiger des consignes qui tiennent : courtes, impératives, vérifiables, et nées d'une erreur réelle plutôt que d'une intention.
• Le coût du fichier : il occupe le contexte à chaque session. Le mesurer avant d'y ajouter une ligne.
• Amorcer avec /init, puis corriger au fil des sessions.

les "memories"

Ce que Claude retient d'une session à l'autre, et pourquoi ce n'est pas la même chose qu'un CLAUDE.md.

• La distinction qui structure tout : la mémoire s'apprend au fil du travail, le CLAUDE.md se décide et passe en revue.
• Les quatre natures : qui vous êtes, les corrections que vous avez formulées, les contraintes du projet, les ressources externes.
• Ce qu'il ne faut pas y ranger : ce que le dépôt dit déjà, et ce qui n'est vrai que le temps d'une conversation.
• Comment une mémoire refait surface — et pourquoi la vérifier avant d'agir : elle date du jour où elle a été écrite.
• L'entretien : fusionner les doublons, supprimer ce qui est devenu faux.

Skills

Un mode d'emploi rangé à part, chargé seulement quand le sujet se présente.

• Le problème qu'ils résolvent : un CLAUDE.md qui gonfle coûte à chaque session, un skill ne coûte que le jour où il sert.
• L'anatomie : un dossier, un SKILL.md, un nom — et une description, qui est ce qui déclenche le chargement. C'est la ligne qu'on soigne le plus.
• Les portées : skill de projet versionné et partagé avec l'équipe, skill personnel, skill distribué par un plugin.
• Le déclencher à la main ou le laisser venir.
• Atelier : écrire le skill d'une procédure que vous répétez déjà.

Hooks

Un script exécuté par l'outil, et non une consigne confiée au modèle. Ce qui doit arriver à tous les coups vit ici.

• Les événements disponibles : ouverture de session, envoi d'un message, avant et après un appel d'outil, fin de tour.
• Le câblage dans settings.json, et le piège : les hooks sont figés au démarrage — il faut relancer la session après les avoir modifiés.
• Ce qu'un hook sait faire : injecter du contexte, avertir, et jusqu'à bloquer un appel d'outil.
• Quatre exemples de production : injecter la documentation technique à l'ouverture, injecter le runbook de déploiement dès qu'une intention de mise en production est détectée, avertir avant l'édition d'un fichier d'infrastructure, vider les caches en fin de tour.
• Écrire, tester et déboguer un hook.

Configuration cross-repositories

• Ce qui se partage entre tous vos dépôts, et ce qui doit rester propre à un projet.
• Les couches de réglages — utilisateur, projet, local : laquelle l'emporte, et où ranger une permission.
• Mutualiser skills et hooks entre plusieurs dépôts sans les dupliquer.
• Les plugins : distribuer à une équipe un jeu cohérent de skills, de hooks et de commandes.
• Les serveurs MCP partagés : base de données, navigateur, suivi de tickets.
• Cas concret : deux projets qui cohabitent sur une même machine, avec une infrastructure commune et des documentations qui se citent l'une l'autre.

Sécurité

• Les permissions : ce qu'on autorise une fois, ce qu'on autorise toujours, ce qu'on ne délègue jamais.
• Les secrets : ce qui ne doit entrer ni dans un dépôt, ni dans une session.
• Les gestes irréversibles — migrations, suppressions, production — et la règle d'accord préalable.
• L'injection de prompt : tout ce qui provient d'une page web, d'un ticket ou d'un fichier tiers est une donnée, jamais une instruction.
• Relire ce qui est produit : ce que l'outil ne peut pas garantir à votre place.
• Les hooks comme garde-fous, et la traçabilité des modifications.