oh-my-openagent-toolkit - Un toolkit d’exploitation local, parti de Claude Code et stabilisé sur OpenCode/oh-my-openagent

Bonjour.
Depuis l’époque où j’utilisais intensivement Claude Code, j’ai eu le sentiment que lorsqu’on branche réellement un agent de codage IA sur un projet, on finit par avoir besoin, plus que du code lui-même, d’une couche qui explique « comment travailler dans ce projet ».

Par exemple, des choses comme :

• vers où router telle ou telle demande
• quel built-in helper il est pertinent d’ajouter
• jusqu’où va le périmètre de support qu’on peut affirmer fermement dès maintenant
• où créer une nouvelle tâche et comment traiter un projet existant
• à partir de quel point et de quelle manière ajouter une couche de refinement côté UI

Au début, j’ai continué à affiner ma propre façon de faire du côté de Claude Code, puis j’ai essayé de basculer vers OpenCode en cours de route, et aujourd’hui je me suis fixé sur oh-my-openagent, où j’ai regroupé le tout sous une forme plus cohérente pour une utilisation sur des projets locaux.
J’ai publié cela sous le nom de oh-my-openagent-toolkit.

GitHub :
https://github.com/HanTechnology/oh-my-openagent-toolkit

Qu’est-ce que c’est ?

En une phrase,
il s’agit d’un companion toolkit local au projet, utilisé sur OpenCode + oh-my-openagent.

Plus concrètement,
il ne cherche pas à remplacer le harness upstream, mais se rapproche plutôt d’une couche d’exploitation locale qui vient s’ajouter par-dessus pour la rendre plus explicite.
Ce dépôt ajoute principalement les éléments suivants.

• thin routing
  • organise l’endroit où envoyer les demandes
  • indique plus clairement quelle category / helper est appropriée
• skill surface
  • organise les entrypoints de premier niveau sous .opencode/skills/
  • il y a actuellement 43 entrypoints, dont 40 dans la core surface et 3 dans un planned adjacent pack
• support boundary
  • sépare validated / guided / planned
  • pour distinguer « ça a l’air de fonctionner » de « on peut l’affirmer publiquement dès maintenant »
• workspace convention
  • définit comment lire depuis la racine du repo et sur quelle base travailler
• UI refinement layer
  • regroupe la famille impeccable en local
  • afin de pouvoir ajouter une refinement layer au-dessus de la route principale lors du travail sur l’UI

Pourquoi l’avoir créé ?

Quand on branche un agent de codage IA sur un vrai projet, il arrive un moment où la question « l’agent est-il intelligent ? » devient moins importante que « selon quelles règles l’agent doit-il fonctionner dans ce projet ? ».

C’est encore plus vrai quand plusieurs domaines se croisent.

• frontend / backend / systems / data / security / QA
• la frontière entre implémentation et validation
• la distinction entre documentation et surface réellement validated
• quand ajouter un agent helper et quand ne pas en ajouter

Plutôt que d’écrire tout cela longuement dans le prompt à chaque fois, ou de le garder uniquement dans la tête des gens,
j’ai pensé qu’il valait mieux le laisser dans le projet sous forme d’une fine couche d’exploitation.
J’ai également précisé clairement ce que ce dépôt ne cherche pas à faire.

Ce n’est pas l’une des trois choses suivantes.

• (X) la distribution upstream officielle de oh-my-openagent
• (X) un nouveau runtime qui remplace le harness
• (X) un autre control plane local

Autrement dit, c’est un companion toolkit qui se pose au-dessus de l’upstream,
pas une tentative de créer encore un nouveau framework.

Jusqu’où cela fonctionne-t-il aujourd’hui ?

Ici aussi, j’ai essayé de ne pas imposer de contraintes excessives.
Ce dépôt dispose actuellement d’une broad skill surface (43 compétences couvrant l’ensemble du développement),
mais celles qui sont actuellement marquées comme validated sont les 4 suivantes.

• frontend-product-delivery
• backend-service-delivery
• cloud-release-readiness
• ai-data-product-delivery

Toutes les autres sont classées comme guided ou planned.

À qui cela peut-il convenir ?

Cela peut convenir aux personnes suivantes.

• celles qui utilisent déjà OpenCode ou envisagent de l’essayer
• celles qui veulent définir plus clairement une couche d’exploitation locale de projet sur oh-my-openagent
• celles qui font réellement tourner des agents de codage IA à l’échelle d’un repo/worktree
  et veulent organiser le routing / support boundary / workspace rule
• celles qui veulent laisser le savoir opérationnel dans le projet plutôt que d’écrire uniquement de longs prompts

Démarrage rapide

Pour ce dépôt, on peut procéder en gros dans cet ordre.

1. Installer OpenCode
2. Configurer oh-my-openagent
3. Cloner le repo
4. Lancer opencode
5. Faire du vibe coding avec la combinaison Sisyphus ou Prometheus + Atlas de oh-my-openagent

Pour finir

Ce n’est pas encore vraiment un produit fini ;
c’est plutôt un toolkit d’exploitation locale que j’ai structuré parce que j’en avais concrètement besoin en passant de Claude Code à OpenCode puis à oh-my-openagent.

Si certains d’entre vous se sont posé des questions similaires, vos retours sont les bienvenus.

Repo :

https://github.com/HanTechnology/oh-my-openagent-toolkit