Claude Code
Où vit chaque consigne, le moteur de skills, les permissions, les hooks et le contexte.
Version texte pour agents : /md/claude-code.md
Claude Code n'est pas une collection de commandes à mémoriser, c'est un jeu de contrôles. La seule question utile : quel problème est-ce que je cherche à résoudre ?
Où vit chaque consigne
| Ce que tu veux | Où ça vit |
|---|---|
| Que l'agent le sache toujours | AGENTS.md (et CLAUDE.md qui pointe vers lui) |
| Une façon répétée de travailler | un skill |
| Que ça arrive à coup sûr | un hook |
| Que ça n'arrive jamais | une permission deny, ou un hook qui refuse |
| Une demande ponctuelle | le prompt |
| Un système extérieur (GitHub, base, suivi d'erreurs) | un serveur MCP |
| Une enquête qui ne doit pas encombrer la session | un sous-agent |
| Deux chantiers en parallèle sans se marcher dessus | un worktree |
Mettre une règle au mauvais endroit est l'erreur la plus fréquente : une interdiction écrite dans AGENTS.md sera oubliée un jour, la même en deny ne le sera jamais (MF-015, principe 4 du manifeste).
Le moteur : les skills
Installés depuis JavaScript-Mastery-Pro/skills, plus /flow fourni par Maedow Flow.
| Skill | Ce qu'il fait | Ce qu'il écrit | Moment du cycle |
|---|---|---|---|
/scope | quoi construire, dans quel ordre, à quel palier | docs/scope/ | phase 0, puis après chaque lot |
/architect | les décisions structurantes, options pesées | docs/specs/ | phase 1, étape 2 de la boucle |
/develop | construit depuis la spec et AGENTS.md | le code | étape 3 |
/check verify | fait tourner l'application et constate | rien | étape 4 |
/test | les tests des fichiers modifiés | *.test.* | étape 5 |
/check review | relecture par un autre modèle | docs/reviews/ | étape 6 |
/document | description de PR, changelog, notes de version, postmortem | selon le type | étape 7, phases 3 et 4 |
/sync | remet le contexte à jour après un lot | AGENTS.md, scope | étape 9 |
/audit | écrit le contexte initial d'un projet | AGENTS.md | phase 1, projet existant |
/debug | trouve la cause racine, corrige au minimum | la correction | quand ça casse |
/flow | installe, contrôle et protège le kit Maedow Flow | les fichiers du kit | phase 1, contrôles |
Trois frottements connus, et ce qui l'emporte :
/developpropose des messages de commit en anglais au format Conventional Commits, avec un trailerCo-Authored-By. MF-017 l'emporte : phrase française au présent, aucun trailer. Le hookcommit-msgrefuse le trailer si la consigne est oubliée./developcrée ses branches depuis la branche courante. Pars toujours dedevelopà jour.- Les skills lisent des titres de section précis dans
AGENTS.md(## Stack,## Build approach,## Commands,## Git,## Context files). Ces titres restent en anglais dans le template, exprès : les traduire casserait la lecture.
AGENTS.md
Ce qui y entre : la stack décidée, les commandes, les conventions qui ne se lisent pas dans le code, les pièges, les règles du produit qui ne se négocient pas. Ce qui n'y entre pas : ce que l'agent découvre en lisant le dépôt, les généralités, l'historique des décisions (il est dans docs/specs/).
/audit l'écrit, /sync le tient à jour. Après un plan approuvé qui fixe une convention durable : « Mets à jour AGENTS.md avec les conventions du plan approuvé. Reste court. N'ajoute rien que le code dise déjà. »
Un AGENTS.md imbriqué (src/payments/AGENTS.md) se justifie pour une zone qui a ses propres conventions ou ses pièges, jamais par dossier.
Permissions
Le kit pose .claude/settings.json :
- allow : lecture git (
status,diff,log,branch),add,commit,switch, et les scripts du projet (verify,lint,typecheck,test,build,dev). - ask :
git push,gh pr create,gh pr merge, l'installation de dépendances. - deny : lecture et écriture des fichiers d'environnement réels (MF-006).
Shift+Tab fait tourner les modes. Mode Plan pour tout ce qui est structurel ; « accepter les modifications » pendant /develop, puisque la branche et les hooks bornent les dégâts ; mode manuel quand on touche à quelque chose de sensible.
Hooks
Le kit en installe un, .claude/hooks/garde.mjs, qui s'exécute avant chaque commande shell de l'agent :
| Commande | Décision | Règle |
|---|---|---|
git commit sur main ou develop | refus | MF-003 |
git push vers main ou develop | refus | MF-003 |
git push --force | refus | MF-016 |
--no-verify, core.hooksPath modifié | refus | MF-016 |
git push --force-with-lease, git reset --hard, git clean -f | demande | MF-016 |
rm -rf, Remove-Item -Recurse | demande | MF-016 |
DROP, TRUNCATE, suppression de branche distante | demande | MF-016 |
Un formatage automatique après chaque modification est un bon ajout par projet, à condition de ne formater que le fichier modifié : formater tout le dépôt à chaque édition noie le diff et ralentit tout.
Mode Plan
À utiliser pour : schéma de données et migrations, authentification, paiement, permissions, refonte large, code inconnu, tout ce qui touche plusieurs systèmes. À éviter pour : changer un texte, renommer une variable, corriger une marge.
Un plan se conteste avant de s'approuver. Trois questions suffisent souvent : « Qu'est-ce qui casse dans le code existant si on fait ça ? », « Quelle est la version la plus simple qui tient les critères ? », « Pourquoi cette brique, et quelle mesure la justifie ? ». Un plan trop ambitieux se ramène au besoin : voir Prompts.
Modèle et effort
Deux réglages indépendants : /model choisit le cerveau, /effort dit combien il réfléchit.
| Travail | Modèle | Effort |
|---|---|---|
| Renommer, formater, CRUD de routine, tests simples | rapide | bas |
| Construire une feature décidée | fort | moyen |
| Architecture, schéma, sécurité, revue approfondie | le plus fort | haut |
| Bug de concurrence, bug intermittent, fuite de données | le plus fort | maximal |
Contexte
| Situation | Geste |
|---|---|
| Sujet sans rapport avec le précédent | /clear |
| Même sujet, conversation trop longue | /compact garde les décisions de schéma et les problèmes ouverts |
| L'agent oublie, se répète, cite des décisions périmées | /context pour voir ce qui occupe l'attention |
| Essayer une autre voie sans perdre celle-ci | /branch <nom> |
| L'agent est parti dans la mauvaise direction | Esc Esc, ou /rewind |
| Une question à côté, sans polluer la session | /btw <question> |
| Reprendre le travail de la veille | claude -c, ou /resume |
Entre deux features : /sync, puis /clear. La mémoire est dans le dépôt (principe 6), la conversation peut repartir de zéro.
Sous-agents
Un sous-agent, c'est un contexte séparé, une tâche ciblée, et un résultat rendu à la session principale. Trois usages rentables :
- Enquêtes parallèles avant une décision : un sous-agent par question indépendante (le modèle de données, le parcours existant, la couverture de tests), chacun rendant comportement actuel, fichiers concernés, risques et recommandation.
- Relecture fraîche d'une feature finie (MF-011).
- Vérification d'un constat : un relecteur peut se tromper. Un sous-agent neuf reproduit le problème avant que quiconque le corrige.
Les formulations sont dans Prompts.
Worktrees, /batch et arrière-plan
claude -w <nom>ouvre une session dans un worktree isolé : deux lots avancent sans éditer les mêmes fichiers./batch <changement>découpe un changement mécanique et divisible (migrer des tests, remplacer une API dépréciée partout) en unités confiées à des agents en worktree, chacune avec sa pull request. Pas pour une feature dont les décisions sont liées, comme un tunnel de paiement./bg <consigne>détache la session pour qu'elle continue sans le terminal ;claude agentsmontre toutes les sessions en cours.
Skills de projet
Le signal : la troisième fois que tu tapes la même suite de consignes. Le skill vit dans .claude/skills/<nom>/SKILL.md, versionné avec le projet.
---
description: Construit ou modifie une page client en réutilisant le design system,
les composants existants et les conventions responsives du projet. À utiliser pour
toute page ou section visible par les clients.
---
Construis : $ARGUMENTS
1. Inspecte la page actuelle et les composants voisins.
2. Cherche un composant réutilisable avant d'en créer un.
3. Suis les jetons de typographie, d'espacement et de couleur.
4. Garde le changement centré sur la demande.
5. Lance l'application et vérifie le rendu, bureau et mobile.
6. Lance `verify`. Résume ce qui a changé.La description est ce qui décide quand l'agent déclenche le skill : elle dit quoi et quand, concrètement. Un skill s'emploie là où ses consignes s'appliquent, et pas ailleurs : un skill d'interface client n'a rien à faire sur un écran d'administration.
MCP
Aucun serveur MCP n'est imposé. La liste dépend de la stack que /architect a décidée pour le projet, pas de ce workflow. Un serveur se branche quand le projet s'en sert, et le signal est simple : tu te surprends à recopier régulièrement des informations d'un service dans la conversation.
| Besoin | Exemples, selon la stack du projet |
|---|---|
| La documentation à jour des bibliothèques (MF-013) | Context7, ou la documentation officielle consultée directement |
| Le dépôt, les pull requests, les revues | le serveur de ton hébergeur de code (GitHub, GitLab…) |
| La base de données | celui de ta base ou de ton BaaS (Supabase, Neon…) |
| Les déploiements et leurs journaux | celui de ton hébergeur (Vercel, Netlify…) |
| Les erreurs et l'analytique | celui de ton outil d'observabilité (PostHog, Sentry…) |
| Les maquettes | celui de ton outil de design (Figma…) |
| Les builds mobiles | celui de ta chaîne mobile (Expo…) |
Un serveur branché élargit ce que l'agent peut faire. N'en branche pas un « au cas où », et donne-lui les droits les plus étroits qui suffisent au besoin.
Au quotidien
/diff avant d'accepter, /review et /security-review avant de fusionner, @chemin/fichier pour désigner exactement ce qui compte, !commande pour lancer une commande toi-même dans la conversation, /doctor quand Claude Code lui-même se comporte mal.