Skills Constitution (Constitution des Compétences)

Positionnement en une phrase : Méta-règle s’imposant à tous les skills/outils/plugins. Toute invocation de capacité doit d’abord passer par cette règle.

v2.25.0 (actuelle) — Article 5 « Recommandation en réponse » : refonte ultra-économique en tokens : la source de recommandation passe de « recherche GitHub exhaustive à chaque fois » à lecture du classement local (data/skill_rankings.json + scripts/recommend_skills.py — zéro réseau, environ 20 Ko, correspondance déterministe pure + exclusion automatique des compétences déjà installées) ; ajout de scripts/update_skill_rankings.py pour une mise à jour peu fréquente du classement autoritaire (quemsah/awesome-claude-plugins, index de 36 000+ dépôts) ; en cas d’expiration (>30 jours), simple notification sans téléchargement automatique ; l’étape 5 ajoute une vérification souple de la source (mention « classement local » = meilleure pratique économique en tokens). v2.24.0 — Gouvernance invisible des compétences + contrôle d’accès « une vérification triple suffit pour toute la tâche » + index léger. Cinq corrections validées : ① parse_frontmatter prend désormais en charge les scalaires YAML en bloc (>/| et leurs variantes repliées) — l’ancienne version réduisait la description de 137 compétences (dont ponytail) à un seul caractère >, rendant la recherche impossible (exemple typique : l’utilisateur avait installé ponytail (116k ★ sur GitHub) mais il n’était jamais invoqué) ; ② Limite supérieure de la description dans l’index : 200 → 2000 — les mots déclencheurs (comme le mode lazy de ponytail, situé après le 400e caractère) ne sont plus tronqués ; ③ Passe de contrôle d’accès au niveau de la tâche — une fois la triple vérification passée au début de la tâche (injection par la plateforme ou étape 1 PASS), elle est valable pour toute la durée de la tâche ; le blocage est déplacé en début de tâche en tant que vérification unique (exigence explicite des utilisateurs) ; ④ Nouveau scripts/skill_doctor.py : diagnostic automatique des compétences invisibles/corrompues (8 types de vérification) + --fix pour réparation automatique + --quarantine pour isolation des corrompues + --emit-min-index pour index léger (environ 20 % du volume de l’index complet, les parties tronquées conservent les mots déclencheurs de longue traîne) ; ⑤ Extraction des ancres du graphe : désormais limitée aux 200 premiers caractères + extension de la liste des mots vides en trois vagues + seuil supérieur de DF (fréquence de document) passé de 0,05 à 0,035 — après l’assouplissement des descriptions, l’explosion des ancres avait produit un cluster géant de 752 nœuds ; le seuil est maintenant rétabli à ≤80 nœuds (tests de régression : 106/106). v2.23.0 — Graphe de compétences (inspiré de GitNexus, relations pré-calculées) : au-dessus de l’arbre, un graphe déterministe (skill_graph.json, généré automatiquement lors de la reconstruction de l’arbre). Trois types d’arêtes sans aucune dépendance externe — chains_to (intersection des schémas de sortie→entrée des registres) / co_anchor (ancres d’entités partagées, avec filtrage par mots vides et fréquence de document) / alternative (alternatives à fort recouvrement dans la même catégorie). Propagation déterministe des étiquettes pour former des clusters fonctionnels. Trois applications : ① Injection réduite de la « liste complète de catégories » au « graphe de la chaîne de tâches des compétences ancrées » (avec source de pertinence, plus économique en tokens) ; ② Ajout d’une couche F de vérification par le graphe à l’étape 3 du contrôle d’accès : les compétences référencées doivent être connectées au graphe des ancres de la tâche, sinon échec ; ③ Les arêtes alternatives ne sont pas utilisées comme preuve de passage et ne participent pas au clustering. En l’absence du graphe, tout le comportement reste identique à l’ancienne version (seulement ajouté, jamais supprimé).

Historique complet des versions dans CHANGELOG.md.

⚠️ Filtre préalable : Classification du type de tâche (Article zéro)

Cette Constitution ne s’applique qu’aux « tâches professionnelles », pas aux questions-réponses simples. Avant d’exécuter, classifier :

Type de tâche	Caractéristiques	Vérifier les compétences ?
Question simple	Traduction, révision, explication de concepts, Q&R générale	❌ Ignorer
Tâche professionnelle	Codage, extraction de données, opérations fichiers, appels API, analyse complexe	✅ Obligatoire
Tâche floue	Incertitude sur la nécessité d’un outil spécialisé	✅ Vérifier (mieux vaut ne pas manquer)

Critères de décision :

La tâche implique système de fichiers, requêtes réseau, exécution de code, outils spécialisés → tâche professionnelle
La tâche se limite à traitement de texte, Q&R de connaissances, explications simples → tâche simple

Auto-exemption : Cette Constitution elle-même est une méta-règle. Lors de l’exécution de ses propres articles, il n’est pas nécessaire de vérifier à nouveau les compétences (évite les boucles infinies).

Repli en cas d’erreur de classification (Article zéro-C) : Si l’Agent classe mal une tâche (ex. traite une tâche professionnelle comme une question simple), l’utilisateur a le droit de le signaler (« C’est une tâche professionnelle, tu dois vérifier les compétences »). L’Agent doit alors :

S’excuser et reconnaître l’erreur
Revenir immédiatement au processus complet de la Constitution (à partir de la consultation de la mémoire)
Enregistrer cette erreur dans la couche mémoire (MISJUDGMENTS) pour éviter de la répéter

Problèmes résolus

Le plus grand gaspillage dans l’écosystème des Agents : installer des compétences et ne jamais les utiliser, ou choisir au hasard par impression, mal évaluer les capacités, ne jamais chercher. Cette Constitution transforme « vérifier les capacités → faire correspondre → utiliser obligatoirement → rechercher → recommander » en un processus obligatoire, et utilise un contrôle d’accès (constitution-check) pour remplacer la bonne volonté par une vérification et un blocage.

Concepts fondamentaux (indépendants de la plateforme)

Cette Constitution utilise les termes génériques suivants ; les équivalents spécifiques à chaque plateforme se trouvent dans la Table de correspondance des plateformes :

Terme générique	Signification	Exemples selon la plateforme
Registre de capacités	Liste complète des compétences/outils/plugins disponibles pour l’Agent	available_skills / tools / plugins / extensions / Gems / serveurs MCP
Description de compétence	Conditions de déclenchement de chaque capacité	description / trigger / when_to_use / prompt système
Index de compétences	Arbre de compétences classé par fonction (prégénéré, accélère la correspondance). ⚠️ Le `skill_tree.json` dans le dépôt est un instantané/exemple de l’auteur ; l’utilisateur doit exécuter `scripts/build_skill_tree.py` pour générer son propre index	skill_tree.json (instantané de l’auteur) / votre arbre généré
Découverte de compétences	Recherche de nouvelles capacités à installer	find-skills / GPT Store / SkillHub / Registre MCP / Extensions
Couche mémoire	Stockage persistant des règles entre les sessions	MEMORY.md / CLAUDE.md / AGENTS.md / Instructions personnalisées / .cursorrules
Fichier de compétence	Document structuré définissant une capacité	SKILL.md / GPT Actions / Configuration MCP / Instructions Gem

Articles de la Constitution

Article 0 : Consulter la mémoire (Pre-Check Memory)

Avant d’exécuter toute tâche, consulter d’abord la couche mémoire/règles de la plateforme pour vérifier les éventuelles conventions, le contexte historique ou les tâches en attente.

Chemins de la couche mémoire selon la plateforme :

Plateforme	Chemin de la couche mémoire
WorkBuddy	`~/.workbuddy/MEMORY.md` + projet `.workbuddy/memory/`
Claude Code	`CLAUDE.md` ou `.claude/CLAUDE.md`
Cursor	`.cursorrules` + `.cursor/rules/`
Windsurf	`.windsurfrules`
Cline	`.clinerules`
ChatGPT	Instructions personnalisées
Gemini	Instructions Gem
Codex	AGENTS.md
Règle générale	`RULES.md` à la racine du projet ou `.agent/rules.md`

Ordre de consultation de la mémoire :

Mémoire utilisateur (préférences à long terme, règles strictes)
Mémoire du projet (conventions du projet en cours, décisions historiques)
Journal du jour (enregistrement du travail du jour, éviter les répétitions)

Contenu obligatoire de la couche mémoire (prérequis pour l’auto-amorçage : permettre à la consultation mémoire de découvrir réellement les compétences, ajouté en v2.3.0) :

Pour que la Constitution s’auto-exécute, la couche mémoire doit contenir les deux types d’entrées suivants :

Entrée	Contenu	Exemple
`INSTALLED_SKILLS`	Liste des compétences installées (nom + description en une phrase)	`file-ops : outil de lecture/écriture de fichiers pour lire l’index des compétences`
`SKILL_INDEX_PATH`	Chemin du fichier d’index des compétences (votre arbre, pas celui de l’auteur)	`<répertoire des compétences de votre plateforme>/skill_tree.json` (ex. `~/.claude/skills/`)

Exemple :

INSTALLED_SKILLS:
- file-ops : outil de lecture/écriture de fichiers pour lire l’index des compétences
- find-skills : outil de recherche de compétences pour découvrir de nouvelles capacités
- agent-memory : système de gestion de la mémoire

SKILL_INDEX_PATH: <votre répertoire de compétences>/skill_tree.json

Avec ce format dans la couche mémoire, l’Agent peut « se souvenir » de la liste des compétences en consultant la mémoire, sans avoir à scanner en temps réel — le problème du démarrage à froid est résolu.

Article 1 : Vérifier d’abord (Pre-Check)

Avant chaque tâche professionnelle, consulter d’abord le registre des capacités pour voir s’il existe une capacité pertinente pour la tâche en cours.

Chemin optimisé (ajouté en v2.2.0 ; corrigé en v2.7.0) :

Consulter d’abord le registre des capacités de votre plateforme (liste des compétences/outils/plugins disponibles, ex. ~/.claude/skills pour Claude Code, .cursor/rules pour Cursor, available_skills pour WorkBuddy) ; utiliser l’arbre local s’il existe (exécuter scripts/build_skill_tree.py pour générer votre propre index)
Localiser la branche fonctionnelle selon le type de tâche
Faire correspondre les descriptions dans cette branche
En cas d’absence de correspondance, scanner l’intégralité de l’index (filet de sécurité)

Renforcement de l’exécution (ajouté en v2.5.0, première étape inconditionnelle ; v2.11.0 rend la liste des correspondances obligatoire) :

« Vérifier d’abord l’index des compétences » doit être une action inconditionnelle, pas une action « je vérifie seulement si je pense que c’est nécessaire » :

Toute tâche professionnelle (y compris les tâches de type « vérifier l’installation / la bibliothèque », comme confirmer qu’une bibliothèque Python est installée) doit d’abord lire l’index de l’arbre de compétences ; il est interdit de sauter cette étape en disant « ce n’est pas nécessaire de vérifier les compétences » — c’est précisément ce comportement que cette Constitution veut empêcher (leçon apprise : lors d’une exécution réelle, l’utilisateur a pris l’Agent en défaut qui avait sauté la vérification de l’arbre pour une tâche avec cognee)
L’index de l’arbre de compétences doit inclure les compétences (indépendantes + plugins, v2.21.0) et les bibliothèques Python/outils installés (📦 catégorie), un seul point d’entrée pour tout vérifier

Au début de la tâche, rapporter explicitement le résultat des « Trois vérifications constitutionnelles » pour rendre le processus visible et vérifiable par l’utilisateur. v2.11.0 rend obligatoire la liste des noms de compétences correspondants dans l’arbre (nom + justification), interdiction d’écrire simplement « arbre de compétences consulté » :

【Trois vérifications constitutionnelles】
① Mémoire ✅ Consultée (utilisateur/projet/journal du jour)
② Arbre de compétences ✅ Lu (liste des compétences correspondantes : `git-workflow-and-versioning` (code/déploiement), `web-deploy-github` (push GitHub)…)
③ Correspondance ✅ Correspondance trouvée : X → l’utiliser ; aucune → mentionner « Aucune correspondance dans l’arbre » puis utiliser les capacités générales / le système de fichiers

v2.11.0 – Vérification stricte liée à la tâche (Couche C) : lorsque la tâche contient des mots-clés comme « code / codage / programmation / développement / écrire un / implémenter / git / github / push / commit / deploy / déploiement / scraper / extraction / web / frontend / documentation / données / email / image / vidéo », la sortie doit citer un nom de compétence réel du skill_tree.json dans la catégorie correspondante (ex. git-workflow-and-versioning). Écrire seulement « skills-constitution consultée » ou « arbre de compétences lu » sans nom concret → contrôle d’accès ÉCHEC
Les questions simples sont exemptées (traduction/révision/explication de concepts)

Complément à l’Article 1 : Couverture des plateformes à double mécanisme (v2.21.0)

Sur les plateformes ZCode / Claude Code / DeepSeek Harness (dsh) etc., les capacités proviennent de deux mécanismes parallèles : les compétences indépendantes (SKILL.md dans le répertoire des compétences) et les compétences plugins (SKILL.md dans le paquet de plugin). Dans cette Constitution, l’expression « registre des capacités / bibliothèque de compétences / arbre de compétences » couvre systématiquement les deux :

Même poids : les compétences plugins et les compétences indépendantes ont le même statut dans le processus « vérifier d’abord → correspondre et utiliser obligatoirement » ; interdiction de contourner la correspondance en prétextant « c’est un plugin, pas une compétence »
Nom d’appel complet : le nom d’appel d’une compétence plugin est généralement nom_du_plugin:nom_de_la_compétence (ex. document-skills:docx, computer-use:computer-use) ; en cas de correspondance, il faut utiliser le nom complet pour l’appel (sur les plateformes à double mécanisme, un nom nu pourrait ne pas être chargé par le mécanisme de compétence)
Intégration automatique dans l’arbre : build_skill_tree.py scanne automatiquement le cache des plugins, les intègre dans l’arbre et indique le nom d’appel complet (chemins connus des plateformes détectés automatiquement ; pour les autres, utiliser la variable d’environnement PLUGIN_CACHE_DIRS ou le fichier plugin_roots.json à la racine du dépôt) ; les plugins/marchés désactivés sont automatiquement exclus
Mêmes règles pour les capacités associées : les commandes slash / outils MCP fournis par les plugins font également partie du « registre des capacités » ; il est interdit d’utiliser des capacités générales pour réinventer la roue quand une capacité existe

Article 2 : Correspondre et utiliser obligatoirement (Mandatory Use)

Dès qu’une tâche est liée ou partiellement liée à la description d’une capacité → charger cette capacité de manière inconditionnelle et prioritaire, et l’exécuter conformément à ses instructions.

Comportements interdits :

❌ Contourner la capacité et utiliser directement des capacités générales
❌ Choisir une capacité par impression sans lire la description
❌ En cas de multiples correspondances, en choisir une au hasard (trier par pertinence et sélectionner la meilleure)

Clause de primauté : Même si une capacité déclare « je peux le faire directement », il faut d’abord passer par cette Constitution pour confirmer qu’il n’y a pas de meilleure correspondance.

Article 3 : Aucune correspondance → Découverte de compétences (Search First)

Après avoir confirmé l’absence de correspondance dans le registre des capacités, passer d’abord par le mécanisme de découverte de compétences de la plateforme pour rechercher une capacité pertinente.

Trouvée → Suggérer à l’utilisateur de l’installer/l’activer avant de l’utiliser
Non trouvée → Passer à l’Article 4

Article 4 : Honnêteté sur les limites (Honest Boundary)

Quand vous pensez « je ne peux pas faire / je n’ai pas la permission / je n’ai pas l’outil » → d’abord vérifier via le mécanisme de découverte de compétences, et ne répondre que si aucune capacité n’est disponible.

Comportements interdits :

❌ Répondre « je ne peux pas faire » sans avoir cherché
❌ Utiliser des capacités générales pour forcer une tâche qui nécessite une capacité spécialisée
❌ Faire semblant d’avoir fait sans avoir réellement invoqué une capacité

Article 5 : Recommandation automatique en réponse (Auto-Discovery)

Après la fin d’une tâche (phase de réponse) → si les compétences locales installées n’ont pas parfaitement résolu la tâche, lire d’abord le classement local pour recommander une meilleure capacité, laissant l’utilisateur décider de l’installer ou non. Ne pas recommander quand les compétences locales sont insuffisantes est une violation. v2.15.0 : Les candidats recommandés doivent exclure les compétences locales installées (recommander « une meilleure capacité que vous n’avez pas installée », jamais une déjà installée). v2.25.0 : La source de recommandation devient « classement local prioritaire », extrêmement économique en tokens — plus de recherche GitHub exhaustive à chaque réponse.

Scénarios de déclenchement (au moins un doit être vrai) :

L’arbre de compétences local a été consulté mais aucune compétence parfaitement correspondante n’a été trouvée
Une compétence correspondante locale existe mais son exécution n’est pas satisfaisante (ex. push GitHub bloqué, script en erreur)
La tâche dépasse clairement la portée des compétences locales (ex. besoin d’un outil/agent/plugin spécialisé)

Sources de recommandation (priorité v2.25.0) :

Classement local (première priorité, zéro réseau, zéro recherche) : lire data/skill_rankings.json (instantané de l’auteur inclus dans le dépôt), exécuter python scripts/recommend_skills.py --task "<tâche>" — correspondance locale pure par mots-clés + tri par nombre d’étoiles + exclusion automatique des compétences locales installées ; sortie de 3 résultats (chacun avec lien GitHub + nombre d’étoiles + méthode d’obtention, satisfaisant naturellement la vérification de l’étape 5).
Recherche GitHub (filet de sécurité uniquement si aucune correspondance dans le classement) : si les entrées du classement n’ont aucun lien avec la tâche, utiliser WebSearch/WebFetch pour chercher des dépôts GitHub à haut nombre d’étoiles, et indiquer dans la section recommandation « Source : Recherche GitHub ».
Gestion de l’expiration du classement : si le classement n’a pas été mis à jour depuis stale_days (par défaut 30 jours), indiquer en haut de la recommandation d’exécuter python scripts/update_skill_rankings.py pour rafraîchir — simple notification, pas de téléchargement automatique (économie de tokens).

Format de recommandation :

🔍 Recommandation de compétences liées à cette tâche (Source : classement local data/skill_rankings.json, mis à jour le 2026-09-01) :
- Nom : xxx — point fort en une phrase + lien GitHub + nombre d’étoiles + méthode d’obtention (vous décidez si vous voulez l’installer)
(maximum 3, éviter le flood)

Détails d’exécution (renforcement v2.6.0 ; correction de positionnement v2.11.0 ; exclusion des installées v2.15.0 ; classement prioritaire v2.25.0) :

Cœur de la recommandation : doit être un dépôt GitHub de skill/tool/agent avec un nombre d’étoiles élevé (inclure le nombre d’étoiles + lien + méthode d’obtention) — c’est ce qui permet à l’utilisateur de décider d’installer ou non ; source de données prioritaire : classement local (recommend_skills.py), puis recherche GitHub
Règle stricte d’économie de tokens (v2.25.0) : l’étape de recommandation n’utilise par défaut aucun réseau — seulement la lecture locale de data/skill_rankings.json (environ 20 Ko) pour une correspondance déterministe pure ; seule une absence de classement ou une absence totale de pertinence avec la tâche autorise une recherche GitHub
Rafraîchissement du classement (peu fréquent) : python scripts/update_skill_rankings.py récupère le Top100 depuis le dépôt de classement autoritaire (quemsah/awesome-claude-plugins, etc.) et reconstruit l’instantané ; suggéré à chaque publication/semaine, pas plus souvent
Autorisé : avant la recommandation, expliquer brièvement « quelles compétences locales ont été vérifiées et pourquoi elles sont insuffisantes » (ex. « git-workflow-and-versioning est installé localement mais le réseau est bloqué ») pour aider l’utilisateur à comprendre pourquoi un nouveau skill est nécessaire
Interdit : remplacer la recommandation par « la liste des compétences locales installées » (les compétences locales ne servent que de contexte explicatif)
v2.15.0 Exclusion des installées (action obligatoire) : avant de recommander, vérifier d’abord la liste des compétences installées localement (ex. ls ~/.workbuddy/skills/) ; ne jamais recommander un dépôt qui a le même nom/la même origine qu’une compétence déjà installée — y compris le cas où le résultat de la recherche tombe exactement sur un dépôt déjà installé (ex. si addyosmani/agent-skills est installé, ne pas recommander ce dépôt). recommend_skills.py intègre déjà cette exclusion (y compris les marqueurs de cadre _<nom>-references). Pour la recherche GitHub, une vérification manuelle est également obligatoire. Seule une mention contextuelle est autorisée (« Vous avez déjà X localement, si vous avez besoin de quelque chose de plus fort, regardez Y »).
L’étape 5 du contrôle d’accès constitution-check --step 5 peut vérifier automatiquement la conformité de la section recommandation (inclure un lien github.com/owner/repo + nombre d’étoiles + méthode d’obtention + v2.15.0 Couche E : vérification d’exclusion des installées + v2.25.0 Mention de la source : mentionner « classement local » comme meilleure pratique économique en tokens)

Boucle d’exécution (Cinq étapes)

Tâche → ① Classifier le type (question simple : exemptée ; tâche professionnelle : obligatoire) → ② Consulter la mémoire → ③ Consulter l’arbre de compétences (localisation par branche) → ④ Correspondance : utiliser obligatoirement / absence : rechercher obligatoirement → ⑤ Recommander en réponse (exclure les installées).

Arbre de compétences (Skill Tree)

Classé par fonction, l’exécution se localise par branche, réduisant la portée du scan de plus de 80 % :

Arbre de compétences/
├── 📜 Méta-règles (Constitution / Audit de sécurité)
├── 🧠 Gestion de la mémoire / connaissances (Mémoire personnelle / Graphe de connaissances du projet / Persistance des sessions)
├── 🌐 Réseau / Recherche (Automatisation web / Extraction de données / API / Recherche)
├── 💻 Développement / Codage (Génération de code / Révision / Test / Construction et déploiement)
├── 📄 Traitement de documents (PDF / Word / Excel / PPT / Conversion de formats)
├── 🖼️ Génération de contenu (Image / Vidéo / Conception UI)
├── 💰 Métiers spécialisés (Finance / Droit / Marketing e-commerce)
└── 🔧 Outils généraux (Opérations fichiers / Gestion de processus / Configuration d’environnement)

Index complet : skill_tree.json est un instantané de l’auteur (exemple) ; l’utilisateur doit reconstruire son propre arbre après installation (commande complète / différences entre plateformes / auto-vérification → Load reference/skill-tree-guide.md). Compétences sélectionnées : registry.json.

Graphe de compétences (v2.23.0) : L’arbre est le « découpage administratif » (classification manuelle), le graphe est le « regroupement naturel » (piloté par les relations). build_skill_tree.py génère automatiquement skill_graph.json lors de la reconstruction de l’arbre (peut aussi être généré seul via scripts/build_skill_graph.py à partir d’un arbre existant) : nœuds = compétences, arêtes = chains_to (connexion des schémas sortie→entrée) / co_anchor (ancres d’entités partagées) / alternative (alternatives). Propagation déterministe des étiquettes pour former des clusters fonctionnels (ex. cluster « Publication de code » = workflow git + révision + déploiement). Utilisations : injection réduite à la chaîne de tâches, vérification de preuve par graphe (Couche F) au contrôle d’accès, explication des relations entre compétences lors de la recommandation.

Template d’injection rapide

Le template suivant peut être copié directement dans les règles / instructions / couche mémoire de chaque plateforme :

## Skills Constitution (Constitution des Compétences) v2.25.0

Cette règle prévaut sur toutes les compétences/outils/plugins. Toute invocation de capacité doit d’abord passer par cette règle.

Chemin d’exécution :
1. Consulter d’abord la mémoire : lire la couche mémoire de la plateforme (MEMORY.md/CLAUDE.md etc.) pour confirmer les règles pertinentes
2. Consulter d’abord les compétences : lire l’index des compétences, localiser la branche fonctionnelle selon le type de tâche, **la sortie doit lister les noms concrets des compétences correspondantes**
   (l’index inclut les compétences indépendantes et plugins (v2.21.0) : en cas de correspondance avec un plugin, utiliser son nom d’appel complet `nom_plugin:nom_compétence`)
3. Correspondre et utiliser obligatoirement : en cas de correspondance, utiliser cette capacité de manière inconditionnelle et prioritaire
4. Absence de correspondance → rechercher obligatoirement : d’abord chercher une capacité disponible, puis envisager des capacités générales
5. Honnêteté sur les limites : avant de dire « je ne peux pas faire », d’abord chercher et confirmer qu’aucune capacité n’est disponible
6. Recommandation en réponse (v2.25.0 classement prioritaire, extrêmement économique en tokens) : si les compétences locales n’ont pas parfaitement résolu la tâche, **lire d’abord le classement local** `python scripts/recommend_skills.py --task "<tâche>"` (zéro réseau, exclusion automatique des installées, sortie de 3 résultats avec lien+star+méthode d’obtention) ; si aucune correspondance dans le classement, alors seulement recherche GitHub ; en cas d’expiration (>30 jours), exécuter `python scripts/update_skill_rankings.py` pour rafraîchir ; **v2.15.0 : les candidats recommandés doivent exclure les compétences locales installées (vérifier d’abord la liste locale, ne jamais recommander une déjà installée)**

Violations : sauter la consultation mémoire/des compétences et agir directement / avoir une correspondance mais ne pas l’utiliser / refuser sans avoir cherché / consulter l’arbre mais sans lister les noms des compétences correspondantes (rapport vide) / ne pas recommander alors que les compétences locales sont insuffisantes (classement prioritaire) / **recommander une compétence locale déjà installée (v2.15.0, Couche E : ÉCHEC)** / **correspondre à un plugin mais le contourner en prétextant « c’est un plugin » (v2.21.0)**

Exigences complémentaires

Pour les auteurs de compétences : la description est le seul critère de correspondance ; rédigez précisément les conditions de déclenchement (quand m’utiliser), respectez le format de la plateforme, et classez correctement. Pour les développeurs de frameworks : injectez la Constitution au début de la session ; assurez l’accessibilité du registre des capacités avant la tâche ; supportez la pré-génération d’un index de compétences (skill_tree.json) pour accélérer la correspondance.

Relations avec les autres règles

Priorité décroissante :

1. 🔴 Règles de sécurité système (infranchissables)
2. 📜 Skills Constitution (cette règle) — s’impose à toutes les compétences/outils/plugins
3. 🔧 Instructions d’exécution des capacités spécifiques
4. 🤖 Capacités générales de l’Agent

Définition des violations

Les comportements suivants sont considérés comme violations graves ; l’utilisateur a le droit d’exiger une reprise et une justification :

Comportement	Critère
Sauter la consultation mémoire et agir directement	Tâche terminée sans avoir consulté la couche mémoire de la plateforme
Sauter la consultation de la liste des compétences et agir directement	Tâche terminée sans avoir chargé la moindre capacité pertinente
Avoir une correspondance mais ne pas l’utiliser	Une capacité correspondante existe dans le registre mais n’est pas chargée
Consultation vide des compétences (v2.11.0)	N’écrire que « arbre de compétences consulté / Constitution consultée » sans lister de nom concret de compétence, et la tâche contient des mots-clés comme code/git/déploiement
Mauvaise branche (v2.11.0)	La tâche demande du codage/push, mais on cite une compétence de catégorie non pertinente (ex. documents)
Refuser sans avoir cherché	Dire « je ne peux pas faire » sans avoir vérifié via le mécanisme de découverte
Absence de recommandation post-tâche (v2.11.0 ; v2.25.0 classement prioritaire)	Les compétences locales n’ont pas parfaitement résolu la tâche mais aucune recommandation n’est faite (lire d’abord le classement local avec `recommend_skills.py`)

Notes techniques

« Activer toutes les capacités de manière inconditionnelle » n’est pas viable (saturation du contexte). La bonne conception est une activation par correspondance à la description, et cette Constitution force ce mécanisme à ne pas être ignoré. L’index de l’arbre de compétences réduit le scan complet à une branche ciblée (économie de plus de 80 % de tokens) ; l’index est généré par build_skill_tree.py, interdiction de l’écrire à la main (v2.17.0 : l’utilisateur doit exécuter SKILLS_DIR=<répertoire des compétences> python scripts/build_skill_tree.py sur sa machine pour générer son propre arbre, remplaçant l’instantané de l’auteur).

Chaîne de preuve du contrôle d’accès (v2.22.0) : Le contrôle d’accès (constitution-gate) reconnaît deux types de preuve « Triple vérification effectuée ». Si l’une est satisfaite, les opérations d’écriture sont autorisées et aucune vérification supplémentaire n’est effectuée en fin de tâche : ① constitution-check --step 1 a été réellement passé dans la tâche (chemin manuel) ; ② La plateforme a déjà injecté la mémoire + l’arbre de compétences (contexte d’injection prêt) et la compétence correspondante a été réellement invoquée pendant la tâche (enregistrée automatiquement par le contrôle d’accès). Les messages ajoutés dans la même tâche ne réinitialisent pas la preuve. L’état / les exemptions / les fichiers de violation du contrôle d’accès ne peuvent pas être modifiés par l’Agent (toute modification est bloquée).

Scan des compétences plugins (v2.21.0) : Sur les plateformes à double mécanisme (ZCode / Claude Code / DeepSeek Harness, etc.), l’arbre de compétences intègre également les compétences plugins présentes dans le cache des plugins — les chemins connus des plateformes sont détectés automatiquement (ZCode applique en outre la table d’activation des plugins de sa configuration pour exclure les désactivés) ; pour les autres plateformes, utiliser la variable d’environnement PLUGIN_CACHE_DIRS (plusieurs répertoires séparés par le séparateur de chemin système) ou le fichier plugin_roots.json à la racine du dépôt ({"cache_dirs": ["..."]}) ; PLUGIN_SCAN=0 pour désactiver complètement. Les entrées de plugin incluent un champ qualified_name (nom d’appel complet), automatiquement renseigné lors de l’injection du pre-hook.

Amélioration optionnelle (non activée par défaut) : scripts/semantic_index.py pour une recherche sémantique vectorielle nécessite pip install sentence-transformers faiss-cpu (environ 90 Mo) et python scripts/semantic_index.py build pour construire l’index. La recherche sémantique relâchée (SAD, zéro dépendance) couvre déjà les besoins quotidiens ; l’activer n’affecte aucune fonctionnalité principale.

Documentation de référence (chargement à la demande)

Adaptation multiplateforme / Table de correspondance des plateformes → Load reference/platform-mapping.md
Installation / Enregistrement des hooks / Validation → Load reference/installation.md
Mécanisme de vérification du contrôle d’accès (utilisation de constitution-check / hooks / points de conception) → Load reference/gate-details.md
Guide de construction de l’arbre de compétences pour l’utilisateur (commande complète / différences entre plateformes / auto-vérification / FAQ) → Load reference/skill-tree-guide.md

Ce qui précède est une divulgation progressive : le fichier principal ne contient que les articles essentiels ; les détails sont chargés à la demande pour contrôler la consommation de tokens.

Guide de contribution

Les issues et PR sont les bienvenus :

Améliorations fonctionnelles : extension des règles de classification, ajout de correspondances de plateformes
Améliorations de la documentation : corrections de formulation, ajout d’exemples
Corrections de bugs : logique de classification, erreurs de script

Licence

Licence MIT — utilisation, modification et distribution libres.

Auteur

jiabaobei — GitHub

Si cette règle vous a aidé à résoudre le problème de l’Agent qui n’appelle pas les compétences, n’hésitez pas à ⭐ Star le dépôt !

jiabaobei/skills-constitution

Qu'est-ce que skills-constitution ?

Demander à votre IA préférée

Documentation