Context Engineering Kit : des skills Claude Code à installer plugin par plugin

Le problème visé : le contexte de l'agent se remplit trop vite

Chaque skill ou agent chargé dans la fenêtre de contexte d'un assistant de code consomme des tokens qui ne serviront peut-être jamais à la tâche en cours. Le dépôt part de ce constat et propose une collection de prompts présentée comme « minimal token footprint », avec une préférence affichée pour des skills orientés commande et des sous-agents plutôt que des skills d'information générale. Le README justifie ce choix en expliquant que l'objectif est d'éviter de « populating context with unnecessary information ». La cible est donc l'équipe qui utilise déjà un agent de code au quotidien et qui veut ajouter des comportements précis (réflexion après implémentation, mémoire projet, revue de code) sans installer un paquet monolithique. Le dépôt se présente comme une marketplace, c'est-à-dire un catalogue depuis lequel on choisit ce qu'on charge. C'est un point de conception, pas un détail marketing : la granularité est la promesse centrale.

Ce que contient réellement le catalogue

Le README cite plusieurs plugins nommés : reflexion, sdd (Spec-Driven Development), sadd (Subagent-Driven Development), ddd et tech-stack. Les notes de version donnent quelques indications sur leur contenu. Le plugin sdd s'appuie sur la spécification Arc42 pour la documentation de développement, et la version 3.1.0 y a ajouté des règles DDD/SOLID dans l'agent développeur ainsi qu'un agent de revue de code appliquant des règles fonctionnelles et orientées objet, avec une analyse de gaspillage Muda pour réduire la complexité et la duplication. Le plugin sadd est décrit comme une version distillée de sdd, utilisant des sous-agents « meta-judge » et « judge » pour générer la spécification à la volée et en parallèle de l'implémentation. Le plugin tech-stack injecte automatiquement des bonnes pratiques TypeScript quand l'agent lit ou écrit des fichiers TypeScript, depuis la version 3.0.0. Le dépôt indique aussi inclure une alternative open source à CodeRabbit, sans que le README détaille laquelle ni comment elle fonctionne. C'est une lacune documentaire réelle : pour ce point précis, il faut aller chercher dans la documentation GitBook ou dans l'arborescence du dépôt.

Installation : quatre chemins, quatre niveaux de contrôle

Sur Claude Code, deux commandes suffisent. D'abord l'ajout de la marketplace :

/plugin marketplace add NeoLabHQ/context-engineering-kit

Puis l'installation d'un plugin précis, par exemple :

/plugin install reflexion@NeoLabHQ/context-engineering-kit

Le README précise que l'ajout de la marketplace rend les plugins disponibles mais ne charge aucun agent ni skill dans le contexte. Seule l'installation charge quelque chose, et uniquement les agents, commandes et skills du plugin concerné.

Les autres chemins sont moins sélectifs. Sur Gemini CLI, la commande est :

gemini extensions install https://github.com/NeoLabHQ/context-engineering-kit

Le README avertit explicitement que cela installe tous les skills et agents en un seul bundle, sans sélection par plugin, et suggère de supprimer après coup ce qui n'est pas nécessaire. Sur Antigravity CLI, la commande pointe vers un sous-dossier du dépôt :

agy plugin install https://github.com/NeoLabHQ/context-engineering-kit/antigravity

Même remarque : installation groupée, pas de sélection. Pour Cursor, Codex, OpenCode et autres, la voie passe par l'outil de vercel-labs :

npx skills add NeoLabHQ/context-engineering-kit

Là, la sélection est possible, mais le README signale deux réserves : chaque fournisseur a son propre format d'agent, et npx skills ne gère pas les sous-agents, donc l'expérience est incomplète. Une méthode alternative est mentionnée avec OpenSkills :

npx openskills install NeoLabHQ/context-engineering-kit npx openskills sync

Le mécanisme d'usage : commandes et hook

Le fonctionnement visible dans le README repose sur des commandes slash et sur un hook. L'exemple donné est une implémentation d'authentification suivie d'un appel à /reflect, qui analyse le résultat et propose des améliorations. Le README indique que si les problèmes sont évidents, l'agent les corrige immédiatement, et s'ils sont mineurs, il suggère des améliorations auxquelles l'utilisateur peut répondre. Vient ensuite /memorize, qui extrait les stratégies de résolution et les enregistre dans la mémoire du projet, avec l'objectif affiché d'éviter que les mêmes problèmes réapparaissent. Il existe une variante sans commande explicite : écrire « reflect » dans le prompt initial déclenche le hook qui lance /reflect automatiquement. Le README précise que l'utilisation de ce hook nécessite une configuration supplémentaire, mais le texte fourni est tronqué à cet endroit. Le détail de cette configuration n'est donc pas vérifiable ici, et je ne peux pas l'affirmer. Ce qui est clair, c'est que le modèle d'interaction est commande-centré : on n'ajoute pas un gros prompt système, on ajoute des points d'entrée que l'agent invoque au bon moment.

La limite principale : la granularité dépend de l'hôte

C'est le point le plus important et le plus facile à manquer. La promesse de granularité, présentée comme un axe de conception, n'est tenue que sur Claude Code. Sur Gemini CLI et Antigravity CLI, le README écrit noir sur blanc que la sélection par plugin n'existe pas et qu'il faut supprimer manuellement les skills et agents non désirés après installation. Cette suppression manuelle est un coût de maintenance qui revient à chaque mise à jour : rien dans le matériel fourni n'indique un mécanisme qui préserverait vos suppressions lors d'une réinstallation. Sur Cursor, Codex et OpenCode, la sélection est possible via npx skills, mais les sous-agents ne sont pas pris en charge, ce qui exclut une partie du fonctionnement décrit pour les plugins qui reposent sur des sous-agents, comme sadd avec ses agents meta-judge et judge. Autrement dit, le même dépôt donne des expériences différentes selon l'outil, et la version la plus complète est aussi la plus liée à un fournisseur. À noter aussi : le README annonce que le plugin sdd produit du code fonctionnel dans 99 % des cas sur des projets de production réels. C'est une affirmation de l'éditeur, sans protocole de mesure exposé dans le matériel fourni. Elle ne doit pas être lue comme un résultat indépendant.

Comparaison : kits de prompts contre agents de revue intégrés

Le dépôt se positionne face à deux familles d'outils. La première est celle des revues de code automatisées hébergées, du type CodeRabbit : un service qui commente les pull requests de l'extérieur. Le dépôt revendique une alternative open source à cet outil, ce qui déplace la revue dans votre agent et votre dépôt, sans dépendance à un service tiers, mais aussi sans tableau de bord ni historique centralisé. La différence d'approche est structurelle : la revue devient une commande que vous déclenchez, pas un bot qui commente systématiquement. La seconde famille est celle des collections de prompts copiées dans un fichier de configuration. Là, la différence tient au format : les skills suivent la spécification agentskills.io, ce qui les rend portables entre hôtes, avec les restrictions décrites plus haut. Un fichier de règles maison reste plus simple à auditer, parce qu'il tient dans un seul fichier que vous relisez en entier. Le kit échange cette lisibilité immédiate contre une sélection par plugin et une mise à jour suivie par versions, la dernière publiée étant la v3.10.0.

Licence et coût de suivi

Le dépôt est sous GPL-3.0. Concrètement, si vous redistribuez le kit modifié, ou si vous l'intégrez dans un produit distribué, la licence impose des obligations de publication du code source dérivé. Pour un usage interne en équipe, la question se pose différemment, mais elle mérite un examen par votre service juridique : je ne donne ici aucune interprétation juridique. Le rythme de publication est soutenu : trois versions entre le 18 et le 26 août 2026 selon les données fournies, avec des changements de fond entre mineures (réécriture du plugin sdd en v2.0.0, ajout de règles dans les agents en v3.1.0). Cela signifie que le contenu des prompts bouge, donc que le comportement de vos commandes peut changer sans action de votre part si vous suivez les mises à jour. Un kit de prompts n'est pas un paquet figé : chaque version peut modifier ce que l'agent fait après /reflect. La documentation de référence est hébergée sur GitBook, et le README renvoie aussi à une page de référence et à un guide d'intégration CI via GitHub Action. Pour un lecteur qui doit décider, le point à vérifier en premier n'est pas le nombre de plugins mais le contenu exact du plugin que vous comptez installer, dans la version que vous installez.

Conclusion éditoriale

À adopter si vous travaillez dans Claude Code et voulez ajouter des commandes ciblées comme /reflect ou /memorize sans charger tout un catalogue dans le contexte. À éviter si votre outil principal est Gemini CLI, Antigravity ou Cursor : ces chemins installent l'ensemble en un seul bloc et vous devrez supprimer à la main les skills inutiles. Avant de vous engager, vérifiez le contenu réel d'un plugin dans le dépôt et la compatibilité de votre version avec le format agentskills.io, car la documentation en ligne reste la seule source de détail sur chaque plugin.

Sources officielles

1. License: GPL-3.0
2. NeoLabHQ/context-engineering-kit on GitHub
3. Project website
4. README
5. Releases