Synergie des compétences — règles d'arbitrage
Une autorité pour déterminer quelle compétence l'emporte lorsque plusieurs s'activent. Lisez ceci lorsque deux compétences ou plus s'appliquent de manière plausible à la tâche en cours.
Note d'utilisation : cette compétence est l'ensemble détaillé des règles. Une charte concise (recommandée pour les configurations toujours actives) se trouve dans la racine du dépôt sous
AGENTS.md.template; copiez-la dans AGENTS.md pour que la règle fondamentale soit chargée à chaque session. Cette compétence est la référence à la demande.
La règle fondamentale
Les compétences de workflow (quoi faire) priment sur les compétences de mode (comment parler/écrire) pour la même tâche. La compétence de mode s'adapte ; la compétence de workflow n'est jamais affaiblie.
Tout ce qui suit est une application de cette règle. Si un cas spécifique n'est pas listé, appliquez la règle fondamentale et indiquez-le.
Arbitrage workflow contre workflow
Deux compétences de workflow ou plus peuvent toutes correspondre de manière plausible à la même tâche. Choisissez selon cette échelle, dans l'ordre :
- L'intention explicite l'emporte. Si l'utilisateur a nommé le type de tâche (review, test, design, plan...), la compétence pour ce type dirige. Pas de délibération.
- La portée décide. Un changement unique (un diff, une fonction, un fichier) prend la compétence la plus légère et la moins coûteuse ; un changement transversal (architecture, refactorisation multi-fichiers, nouveau système) prend la compétence la plus approfondie.
- Ordre du cycle de vie. Planification → construction → vérification est la séquence par défaut. Lorsque les compétences sont des phases d'un même effort (design, puis implémentation, puis review), exécutez-les dans cet ordre au lieu d'en choisir une.
- Composer plutôt que choisir. Si deux compétences sont des phases séquentielles, exécutez les deux dans l'ordre et énoncez l'ordre explicitement ("tdd d'abord, puis review").
- Toujours ambigu ? Demandez. Donnez une recommandation d'une ligne et laissez l'utilisateur choisir. Ne choisissez jamais silencieusement une compétence de workflow — la mauvaise coûte toute une tâche, pas une réponse.
Taxonomie des compétences
Classez chaque compétence installée avant d'arbitrer :
- Compétences de workflow — dictent ce qui est fait : review, test, design, recherche, écriture, refactorisation, planification. Elles produisent des livrables.
- Compétences de mode — dictent comment l'agent sonne ou combien il écrit : compression, verbosité, style, concision. Elles ne produisent rien par elles-mêmes.
- Compétences de routage — choisissent quel workflow exécuter (optionnel). Elles ne doivent jamais être écrasées par une compétence de mode.
Si une compétence de mode modifie le livrable d'une compétence de workflow (rapport, doc, message de commit, corps de PR), la compétence de mode cède. Si une compétence de workflow et une compétence de mode s'activent toutes deux et que la sortie de la compétence de workflow est le livrable, la compétence de mode cède.
Cette charte prime sur les auto-descriptions des compétences. Le frontmatter d'une compétence peut revendiquer un déclenchement automatique sur une phrase large (ex. "déclenchement automatique sur review"). Ces revendications sont supplantées ici : le routage suit la désambiguïsation de cette charte, et non la revendication de déclenchement de la compétence elle-même. Si une compétence revendique un déclencheur que cette charte assigne ailleurs, la charte l'emporte.
Matrice de priorité (remplissez vos propres compétences)
Remplacez les noms de compétences d'exemple ci-dessous par les compétences réellement installées dans votre environnement. Les lignes sont ordonnées par la fréquence à laquelle le conflit apparaît en pratique.
| Tâche | Dirige (workflow) | Cède | Comportement |
|---|---|---|---|
| Conception UI / polissage / critique visuelle | ex. votre compétence de design | ex. votre compétence de code minimal | Design dirige ; code minimal à intensité réduite (pas de gonflement, mais pas de veto YAGNI sur l'artisanat du design) |
| Revue de code approfondie (normes + spécifications) | ex. votre compétence de revue complète | ex. votre compétence de compression | Rapport complet en prose normale ; compression désactivée sauf si l'utilisateur demande un retour concis |
| Audit de sur-ingénierie | ex. votre compétence de revue axée sur la suppression | ex. votre compétence de revue complète | Passage à un seul axe, axé sur la suppression ; ignorer le rapport complet |
| Retour rapide concis sur PR | ex. votre compétence de commentaire concis | — | Uniquement lorsque l'utilisateur a explicitement demandé des commentaires compressés |
| Tester un plan / une idée à l'épreuve | ex. votre compétence d'entretien/interrogatoire | ex. votre compétence de compression | Entretien en prose normale ; un interrogatoire compressé perd sa profondeur |
| Construction de fonctionnalité test-first | ex. votre compétence TDD + votre compétence de code minimal | — | Combo : les tests sont une validation, jamais coupés ; implémentation minimale qui passe au rouge-vert |
| Conception de module / API | ex. votre compétence de docs de conception | ex. votre compétence de code minimal | Phase de conception : la profondeur l'emporte. Phase d'implémentation : l'échelle du code minimal s'applique |
| Écriture / édition / enseignement | ex. votre compétence d'écriture | ex. votre compétence de compression | Expression complète requise ; compression désactivée |
| Recherche / capture de documentation | ex. votre compétence de recherche | ex. votre compétence de compression | Les fichiers de sortie sont des livrables ; la compression n'affecte que le chat, jamais le contenu du fichier |
| Toute tâche de codage, aucune autre compétence déclenchée | ex. votre compétence de code minimal | ex. votre compétence de compression | Code minimal à pleine puissance ; compression à la demande uniquement (son coût d'entrée par tour dépasse souvent les économies sur les tâches lourdes en code) |
Désambiguïsation des déclencheurs
Lorsque plusieurs compétences partagent un mot de déclenchement, acheminez par intention, pas par quelle compétence a correspondu en premier :
- "review this" → revue complète par défaut. La revue axée sur la suppression uniquement si l'utilisateur dit "sur-ingénierie" / "trop de code". La revue par commentaire concis uniquement si l'utilisateur demande des retours compressés.
- "grill" / "interview me" → la variante avec état (laisse une trace de doc) lorsqu'une base de code existe ; la variante sans état lorsqu'elle est autonome ; la variante par lots lorsque l'utilisateur veut toutes les questions à la fois.
- "handoff" → la variante de rédaction de document par défaut ; la variante de lancement d'agent en arrière-plan uniquement lorsque l'utilisateur veut un agent en arrière-plan immédiat.
- "make a plan/spec/tickets" → acheminez par type d'artefact : spécifications, tickets, PRD, issues, questionnaire.
Discipline des compétences de mode
- Une compétence de mode n'efface jamais le livrable d'une compétence de workflow. Elle peut compresser la prose du chat uniquement. Les rapports, fichiers, messages de commit et corps de PR écrits par les compétences de workflow restent complets.
- La ligne de validation de la compétence de code minimal a trois niveaux : (1) La validation réelle reste : validation d'entrée, gestion d'erreurs pour les dépendances externes, sécurité, accessibilité — jamais coupée. (2) La défense spéculative est dans le champ : vérifications qui ne peuvent pas se déclencher, wrappers défensifs pour "et si" — coupez-les, c'est le travail de la compétence de code minimal. (3) Les tests et la documentation de la tâche suivent les exigences explicites de l'utilisateur : la compétence de code minimal n'utilise jamais YAGNI pour couper les tests ou la documentation que l'utilisateur exige — mais la redondance dans les tests, le sur-mockage et le gonflement dans la documentation restent légitimes.
- Deux compétences de mode qui se déclenchent ensemble (compression + code minimal) : le code minimal régit le code, la compression régit le chat — mais seulement si la session est lourde en prose ; sur les sessions lourdes en code, la compression doit être désactivée ou à intensité réduite (perte nette de jetons sinon).
- Les sous-agents héritent de l'arbitrage. Lors du lancement d'un sous-agent pour une tâche de revue ou de recherche, énoncez le mode explicitement dans la tâche : "prose normale" ou "sortie compressée". Ne le laissez jamais implicite.
Combinaisons qui payent leur loyer
- Compétence TDD + compétence de code minimal — test-first, implémentation minimale.
- Revue complète, puis revue axée sur la suppression sur le même diff — passage complet, puis un passage de suppression.
- Compétence d'entretien + compétence de compression de mémoire — compressez les notes de session accumulées après l'entretien.
- Compétence de message de commit concis après la fin de toute compétence de workflow — toujours sûr.
- Compétence de routage pour le routage du flux, cette compétence pour l'arbitrage de mode — le routeur choisit la route, la synergie choisit la vitesse.
Personnalisation
Cette compétence est un cadre, pas une configuration. Pour la faire vôtre :
- Remplacez chaque "ex. votre compétence X" dans la matrice de priorité par les vrais noms de compétences de votre environnement. Une référence remplie utilisant des compétences publiques courantes se trouve dans
examples/example-config.md— copiez-la et remplacez vos propres noms au lieu de remplir le modèle à partir de zéro. - Supprimez les lignes pour les types de tâches que vous ne rencontrez jamais.
- Si votre environnement a un fichier de règles global (AGENTS.md ou équivalent), copiez la règle fondamentale dedans pour que chaque environnement la charge.
- Si un nouveau conflit apparaît qui n'est pas couvert, classez les deux compétences (workflow ou mode), appliquez la règle fondamentale et ajoutez une ligne.