Le plugin pour agents de code : Claude Code, Codex, GitHub Copilot

Le dépôt ddd-ts-kit est la marketplace du plugin pour les trois agents :

Agent	Installation	Une skill s'appelle
Claude Code	/plugin marketplace add gbourgeat/ddd-ts-kit, puis /plugin install ddd-ts-kit@ddd-ts-kit	/ddd-ts-kit:start
Codex	codex plugin marketplace add gbourgeat/ddd-ts-kit, puis installer ddd-ts-kit depuis /plugins et approuver ses hooks dans /hooks	$start
Copilot CLI	copilot plugin marketplace add gbourgeat/ddd-ts-kit, puis copilot plugin install ddd-ts-kit@ddd-ts-kit	par son nom, start
Agent cloud de Copilot, VS Code	déclaré par le .github/copilot/settings.json qu'écrit init : l'agent cloud l'installe, VS Code le recommande	par son nom, start

Vingt-deux skills, dans l'ordre où un projet les rencontre :

Skill	Usage
start	conduire un projet d'une expression des besoins jusqu'à des contextes qui fonctionnent (lancée par l'utilisateur)
discover-domain	un event storming léger, par écrit
bounded-contexts	trouver les contextes et les classer cœur, de soutien ou génériques
glossary	le langage omniprésent d'un contexte et son CONTEXT.md, avant tout code
context-map	amont, aval et patron de relation pour chaque paire de contextes
bootstrap	choisir la stack et créer le projet (lancée par l'utilisateur)
plan-slices	le travail en tranches verticales par contexte, ordonnées, avec leurs commandes de génération
parallel-work	répartir les tranches entre plusieurs agents ou personnes sans collision
scaffold	un fichier de n'importe quel rôle, à partir d'un template
use-case	une fonctionnalité de bout en bout, test d'abord
integration-event	faire collaborer deux contextes par un événement versionné
wiring	les ports comme classes abstraites, les déclarations, la racine de composition, les fakes dans les tests
persistence	repositories, unité de travail, outbox, modèles de lecture, migrations, quel que soit l'ORM
access-control	authentification, permissions par cas d'usage, acteur explicite, politiques
cross-cutting	journalisation, métriques, traçage, remontée des erreurs, journal d'audit, résilience et cache appliqués de l'extérieur
testing	des fakes au lieu de mocks, des builders, étant donné / quand / alors, de bout en bout
clean-code	nommage, ordre des fonctions, commentaires, testabilité
document	contrat OpenAPI et ses clients typés, catalogue d'événements, AsyncAPI, listes générées, enregistrements de décision
extract-service	garder chaque contexte prêt à tourner comme son propre service, et l'extraire
deviation	que faire quand on vous demande de contourner une règle
quality-gate	lancer les contrôles à la bonne portée et corriger à la cause racine
commit-discipline	une tranche par commit, les fichiers générés avec ce qui les a générés

Quatre agents : domain-explorer (réponses en lecture seule sur ce qui existe et où), context-builder (construit les tranches d'un contexte dans son propre worktree), domain-test-writer (transforme les entrées it.todo en specs) et architecture-reviewer (revue en lecture seule d'un diff, d'une branche ou d'un contexte).

Le hook est la partie qui rend le reste contraignant. Dans un projet qui a un ddd-ts-kit.config.json, il rappelle la démarche et la carte des contextes au début de la session, signale quand les packages installés ne sont pas la version que décrivent les skills, refuse un fichier écrit à la main là où un générateur existe ainsi que toute modification d'un contrat généré, demande l'avis du propriétaire du projet avant qu'une désactivation, un test sauté ou un changement des règles soit écrit, vérifie chaque fichier écrit et renvoie les violations avec leur correction, et refuse de terminer tant que des erreurs d'architecture restent. Il rappelle, sans bloquer, quand les changements non commités dépassent la taille conseillée d'un commit, et dans le worktree d'un worker (.ddd-ts-kit/worker.json), il refuse une écriture hors du contexte du worker. En cas de panne, il laisse passer : une garde cassée ne bloque jamais le travail. Mettez "guard": "advise" dans la configuration pour être consulté au lieu d'essuyer un refus, "off" pour le faire taire.

Chaque agent reçoit ce que son hôte exécute. Les skills fonctionnent dans les trois. Les quatre agents sont des sous-agents de Claude Code ; Codex ne charge aucun agent depuis un plugin, et une session par worktree tient le rôle de context-builder. Le hook tourne partout où l'hôte exécute les hooks d'un plugin : il lit les patchs de Codex et les appels d'outils de Copilot aussi bien que ceux de Claude Code. Codex ne sait pas poser de question à l'utilisateur : ce que Claude Code soumet au propriétaire du projet y est signalé à l'utilisateur, et laissé aux vérifications du pipeline.

Même sans plugin, un projet guide chaque agent : init écrit AGENTS.md, le guide que lisent Codex, Copilot et la plupart des agents (CLAUDE.md l'importe), les règles par couche pour Claude Code dans .claude/rules/ et les mêmes règles pour Copilot dans .github/instructions/, ciblées par applyTo, et, avec le pipeline GitHub, copilot-setup-steps.yml, qui installe le projet avant le démarrage de l'agent cloud de Copilot. npm run verify et le pipeline tiennent chaque agent aux mêmes règles.