oh-my-customcode — l’outil qui « compile » les agents Claude Code au lieu de les « configurer »

Quand on commence à faire travailler plusieurs agents avec Claude Code, on finit par se heurter sans cesse au même mur.
On rédige des documents de skills, on ajoute des YAML d’agents, on branche des règles, on relie le routage,
et en cas de conflit, on modifie directement CLAUDE.md. Et à chaque changement de projet, il faut tout recommencer.

C’est pour ça que j’ai créé oh-my-customcode.
La phrase tout en haut du README résume parfaitement l’identité du produit.

Your AI Agent Stack. Compiled, Not Configured.

Il repose sur deux axes.

1) Un agent n’est pas une configuration, mais un artefact compilé.

• .claude/skills/ = code source (connaissances et workflows réutilisables)
• .claude/agents/ = artefacts de build (experts assemblés à partir de skills)
• mgr-sauron = compilateur (validation de structure)
• .claude/rules/ = spécification (contraintes et règles de build)
• skill de routage = linker (relie les tâches et les agents)

Les skills évoluent indépendamment, et les agents peuvent être recompilés à tout moment avec les skills mis à jour. Cette séparation est le point de départ du runtime.

2) S’il n’existe pas d’expert, on en crée un à la volée.

Si on demande « peux-tu reviewer ce module Terraform ? » et qu’aucun expert enregistré n’existe, le système ne tombe pas en échec : il fonctionne ainsi.

• Routage : détection de l’absence d’expert Terraform
• mgr-creator : exploration du skill infra-aws-expert + du guide docker-best-practices
• Génération de infra-terraform-expert.md
• Exécution immédiate de la review
• L’agent généré reste disponible pour les appels suivants

Ce n’est pas un fallback, c’est un choix d’architecture. L’absence d’expertise est traitée comme un problème de build.

---

Fourni par défaut

Avec un simple omcustom init, on obtient 48 agents / 107 skills / 22 règles / 39 guides.

  npm install -g oh-my-customcode  
  cd your-project  
  omcustom init  

Quelques décisions de conception

• La conversation principale est un orchestrateur singleton (R010).
  Elle n’écrit pas directement dans les fichiers, et toutes les tâches sont déléguées à des agents dédiés via le routage.
  Les contextes ne se mélangent pas.

• Le model tiering est explicitement défini.
  Architecture et recherche sur opus, implémentation et création d’agents sur sonnet,
  recherche et vérification de comptage sur haiku. Le pattern reasoning-sandwich (opus → sonnet → haiku) est la forme par défaut.

• Les tâches indépendantes s’exécutent en parallèle (R009).
  Jusqu’à 4 par message.

• Les hooks de sécurité sont de type advisory.
  secret-filter, audit-log, schema-validator, PostCompact (réinjection des règles après compaction)
  Ils ne bloquent rien et ne laissent que des avertissements.

• RTK est installé par défaut pour réduire de 60 à 90 % les tokens de sortie CLI.

---

En toute franchise

Il existe déjà pas mal de solutions de type « plugin Claude Code façon oh-my-zsh ».
J’en ai moi-même essayé plusieurs, et j’ai beaucoup de respect pour elles.
C’est pourquoi oh-my-customcode met l’accent non pas sur une collection de templates, mais sur un runtime où compilateur, routeur et managers fonctionnent réellement.
Si vous voulez savoir ce que cette implémentation résout différemment par rapport à d’autres ayant le même concept, posez-moi la question et j’y répondrai.

• GitHub: https://github.com/baekenough/oh-my-customcode
• npm: https://www.npmjs.com/package/oh-my-customcode

Pourquoi un orchestrateur singleton ? Pourquoi avoir séparé sauron dans un agent distinct ? Comment les heuristiques de model tiering ont-elles été définies ? ...

Laissez vos questions en commentaire.
Les premiers retours sont ceux qui me font le plus plaisir.

[moderator]

Le message a été déplacé vers Show GN.
À noter que les publications dont la catégorie a été ajustée par un modérateur peuvent voir leur visibilité sur la page d’accueil limitée, merci donc de vérifier une nouvelle fois la catégorie avant de publier.