Un dépôt peut interdire à un agent de déployer en production tout en lui laissant le moyen de le faire, commande et identifiants compris. La phrase communique une intention ; elle ne retire aucune capacité. L’intérêt du cadre en quatre parties de Tessl est de séparer ce rôle consultatif des procédures et contrôles dont le chargement et l’application diffèrent.
Il organise les fichiers de l’équipe en contexte permanent, règles par chemin, skills réutilisables et hooks du cycle de vie. Les exemples concrets utilisent Claude Code, pas un format universel. La question architecturale est de savoir quelles connaissances doivent rester présentes, quelle procédure charger seulement au besoin et quelle opération dangereuse bloquer hors du jugement du modèle.
Quatre couches sont des contrats différents, pas quatre copies d’une politique
CLAUDE.md fournit le contexte commun : commandes de compilation, conventions de répertoires, limites architecturales et attentes de tests. Le gestionnaire de paquets d’un service ou la règle de migrations uniquement ajoutées peuvent y figurer. Le fichier racine fonctionne mieux comme vue d’ensemble ou index que comme manuel de toutes les exceptions.
Les règles ciblées sous .claude/rules/ chargent des consignes selon des motifs de chemins. Une validation d’API n’a pas à monopoliser l’attention lors d’une modification documentaire. Une règle transversale peut couvrir gestionnaires ou migrations de plusieurs paquets sans copier le même paragraphe dans chaque répertoire.
Les capacités réutilisables regroupent une procédure longue dans un dossier avec SKILL.md, métadonnées, instructions et scripts ou références. La vue d’ensemble peut renvoyer au processus de publication, tandis que la skill correspondante contient ses vérifications ordonnées. Claude Code charge d’abord nom et description ; les instructions complètes entrent dans le contexte lorsqu’elles sont pertinentes ou explicitement invoquées.
Les hooks associent un comportement aux événements du cycle de vie via les paramètres ou une configuration apparentée. Avant un outil, ils inspectent une opération ; après modification, ils formatent ou valident ; avant la fin, ils peuvent exiger des preuves. Ces fonctions diffèrent d’une consigne supplémentaire que le modèle doit se rappeler.
Pour Tessl, la propriété signifie que ces connaissances deviennent un actif versionné du dépôt. Les ingénieurs examinent les différences, désignent des responsables, révisent, annulent une mauvaise règle et donnent le même contexte à une nouvelle session. Le fournisseur conserve la maîtrise du modèle hébergé et du runtime. Posséder les fichiers ne revient pas à posséder tous les mécanismes d’application.
Le contexte coûte lorsqu’il devient une base de politiques
Une équipe commence souvent par un fichier parce qu’il améliore immédiatement noms et choix de commandes. Puis sécurité, publication, conventions frontend et exceptions personnelles s’accumulent jusqu’à être chargées partout. Le matériau permanent concurrence détails de tâche, code, résultats d’outils et historique. Davantage de texte n’assure pas une meilleure conformité.
Les recommandations Anthropic citées préconisent moins de 200 lignes pour CLAUDE.md, un responsable et une revue comme du code. L’enjeu est l’attention et l’entretien, pas une garantie liée au nombre de lignes. Une consigne courte peut être mal comprise ; placer une restriction plus haut ne la rend pas obligatoire.
Les fichiers imbriqués peuvent se charger lorsque l’agent accède à la partie concernée de l’arbre. Les règles par chemin traitent un autre cas : un même sujet traverse plusieurs répertoires. Les deux réduisent le contexte inutile, mais exigent de comprendre le chargement, la correspondance et la priorité du runtime utilisé.
La classification est fonctionnelle. Faits du projet et conventions demandant du jugement relèvent du contexte ; opération répétable à plusieurs étapes, d’une skill ; action interdite, de permissions, d’une vérification bloquante ou d’une isolation renforcée. Sessions longues, contradictions et texte hostile influencent l’adhésion. Une phrase prouve l’existence d’une politique, pas son taux d’application.
Un hook peut toujours démarrer sans décider de façon déterministe
Le modèle interprète les consignes permanentes, règles ciblées et procédures. Un hook diffère parce que le runtime le lance à l’événement configuré, sans attendre le souvenir d’une liste. PreToolUse peut inspecter l’appel proposé avant exécution et renvoyer un blocage si la commande viole la politique.
Le mode de décision dépend toutefois du gestionnaire. Les gestionnaires de commande exécutent des scripts ; ceux de prompt ou d’agent peuvent employer le jugement d’un modèle. Un démarrage fiable peut donc conduire à une conclusion probabiliste. Une condition directement vérifiable par logiciel convient mieux à un contrôle de commande qu’à l’opinion d’un autre modèle.
Pour les fichiers générés, la consigne explique pourquoi éviter une modification, tandis qu’un contrôle préalable conscient de la cible refuse l’écriture interdite. Pour le déploiement, une skill décrit la voie approuvée et des permissions ou hooks empêchent le raccourci direct. Explication et barrière se renforcent car elles résolvent des problèmes distincts.
Les permissions autorisent ou refusent outils et commandes ; dans les contrôles Claude Code cités, un refus correspondant prime sur une autorisation. Les hooks examinent des conditions plus riches. Mais un outil permis ou un contrôle réussi ne signifie pas un accès sans limite au système d’exploitation. Identifiants restreints, conteneurs, branches protégées et montages en lecture seule restent nécessaires pour les conséquences sérieuses.
L’automatisation après modification doit rester proportionnée. Formateur ou validation ciblée peuvent être assez légers à chaque changement ; lancer toute la suite peut gêner. Les gros contrôles conviennent au commit ou à la fin. Un hook d’arrêt ne doit pas exiger indéfiniment une continuation sans voie utile, sinon la barrière devient une boucle coûteuse.
Le plan de contrôle est aussi du code capable de nuire
Les hooks sont une infrastructure exécutable. Un script défectueux peut divulguer des données, bloquer un travail légitime ou ajouter de la latence à chaque événement. La propriété du dépôt donne une responsabilité d’entretien, pas une confiance automatique dans une configuration inconnue. Confiance du workspace, revue et exécution isolée restent importantes.
La modification possible crée une autre frontière. Si l’agent édite les fichiers qui le contraignent, une correction courante peut affaiblir une règle voisine ou désactiver un contrôle. Les paramètres critiques demandent responsabilités et revues renforcées, branches protégées ou exécution en lecture seule, plutôt que la bonne volonté de l’agent à préserver ses propres limites.
Un blocage par motif de commande peut manquer une tâche de paquet équivalente, un script indirect ou un autre outil produisant le même effet. Les tests doivent tenter l’interdit par d’autres voies, pas seulement rejouer l’exemple prévu. Le travail légitime doit aussi être testé : des refus trop larges poussent aux exceptions, contournements ou désactivations complètes.
Issues, documentation, dépendances et artefacts générés non fiables peuvent contenir des injections de prompt. Le modèle peut les interpréter avec les consignes du dépôt. Permissions déterministes et isolation limitent les capacités qui en résultent. La prose seule ne crée pas cette frontière de sécurité.
Les skills conservent les procédures si elles sont entretenues et activées
Les skills rendent les savoirs de publication, migration, mise à jour et incident inspectables au-delà du chat d’un ingénieur. Un validateur du dépôt accomplit une sous-tâche déterministe, l’agent exerce son jugement. Une base technique interrogeable conserve décisions et documents ; la skill définit la transformation des connaissances choisies en procédure.
Présence ne signifie pas activation. Les descriptions doivent préciser quand appliquer une skill et les évaluations vérifier que la bonne procédure charge réellement. L’invocation explicite réduit l’ambiguïté pour une opération sensible. Commandes et architecture évoluent : responsables, exemples et cycles de révision sont des exigences d’entretien, pas des finitions.
Dupliquer une règle à la racine, dans plusieurs fichiers ciblés et dans plusieurs skills crée des autorités concurrentes. Un emplacement principal par fait, avec liens ou courts index ailleurs, facilite les changements. Paramètres personnels et paramètres gérés par l’organisation peuvent encore contredire le dépôt. Il faut voir les fichiers chargés et les règles ou droits ayant pesé sur une action.
Portabilité et gouvernance se démontrent par le comportement
D’autres agents proposent des concepts proches de consigne, workflow et contrôle événementiel, mais répertoires et sémantique diffèrent. L’intérêt commercial de Tessl pour le contexte réutilisable ne fait pas des chemins Claude Code un standard portable. Même un Markdown commun doit préserver déclenchement, portée, priorité et blocage pour une portabilité réelle.
Des évaluations répétables partent d’environnements propres, présentent les mêmes tâches plusieurs fois et consignent configuration, décisions d’outils et résultats. Elles vérifient adhésion, bonne activation des skills, opérations bloquées et réussite ordinaire. La répétition indépendante compte plus qu’une démonstration convaincante.
Trois progrès renforceraient le cadre : évaluations pratiques des consignes, formats de capacités à sémantique précise entre runtimes et interfaces distinguant conseil, déclenchement garanti et refus réel. Les journaux doivent expliquer une permission ou un rejet. Nombre de fichiers et volume documentaire ne remplacent pas ces résultats.
Le livrable utile est une carte de contrôle explicable. Un autre ingénieur doit identifier le contexte guidant une décision, la procédure apparaissant au besoin et la frontière externe arrêtant une erreur grave. Les fichiers de l’équipe rendent cette carte révisable et récupérable. L’autonomie sûre dépend toujours d’une application testée et de l’infrastructure environnante.
Sources et lectures associées
Cadre en quatre parties de Tessl · Recommandations Anthropic · Mémoire du projet et chargement · Gestionnaires de hooks · Permissions des outils · Paquets et invocation des skills · Lecture associée : bases techniques interrogeables