oh-my-pi : adaptez votre agent avec skills et extensions

En résumé : Au 5 septembre 2026, choisissez oh-my-pi si vous voulez un agent de coding déjà intégré, ou Pi si vous préférez assembler un noyau minimal. Utilisez un skill pour formaliser une méthode récurrente et une extension seulement pour ajouter une capacité exécutable. Ma recommandation : commencez par un skill, puis n’ajoutez une extension qu’après avoir identifié une action manquante et audité son code.

Le modèle raisonne et produit du texte. Le harness détermine ce qu’il voit, ce qu’il est autorisé à exécuter et, si vous activez cette capacité, ce qu’il peut retrouver d’une session à l’autre.

Faut-il choisir Pi ou oh-my-pi ?

Pi, un socle volontairement minimal

Pi se présente comme un agent de coding dans le terminal, minimal et extensible. Son noyau fournit quatre outils par défaut : read, write, edit et bash. Vous choisissez ensuite les modèles, les fournisseurs et les personnalisations utiles à votre façon de travailler, notamment au moyen d’extensions, de skills et de packages.

Ce minimalisme n’est pas un manque à combler. Il constitue une décision de conception. Pi laisse volontairement des fonctions comme MCP, les sous-agents ou le mode plan à des extensions ou à des outils externes. Vous partez ainsi d’un socle réduit, puis vous composez votre environnement selon vos besoins réels plutôt que d’accepter un ensemble imposé.

oh-my-pi, le fork plus intégré

oh-my-pi, ou omp, est un fork de Pi avec une approche plus intégrée, souvent résumée par « batteries included ». Ce n’est ni un plugin installé sur Pi, ni une couche exécutée au-dessus de lui : Pi et omp sont deux choix de harness.

omp rassemble, entre autres, des primitives autour de LSP et DAP, des sous-agents, des sessions persistantes, une mémoire optionnelle et une lecture unifiée de ressources. Cette intégration évite d’assembler vous-même chaque capacité, mais elle ne garantit aucun résultat automatique. Les sous-agents restent à superviser et la mémoire, désactivée par défaut, demeure heuristique.

Le bon schéma mental est simple : le modèle dialogue avec le harness choisi — Pi ou omp — qui agit sur le projet via ses outils. Pi privilégie un noyau minimal ; omp intègre davantage de primitives. Votre préférence dépend du niveau d’assemblage et de contrôle que vous souhaitez conserver.

Que permet une extension ?

Hooks, outils et commandes

Une extension est un module TypeScript ou JavaScript qui ajoute ou modifie un comportement exécutable. Elle peut écouter les événements du cycle de vie de l’agent, puis enregistrer des outils, des commandes, des raccourcis, des flags ou des éléments d’interface. Elle intervient donc dans l’action, pas seulement dans la formulation des consignes.

Prenez une règle simple : aucune commande destructive ne doit partir sans confirmation. Un hook peut examiner une action avant son exécution et la bloquer lorsqu’elle enfreint cette règle. Une commande métier comme /release-check peut, de son côté, lancer les vérifications prévues pour une publication. Le résultat attendu est observable : l’action dangereuse est arrêtée ou la checklist est exécutée. Il ne repose pas sur une vague promesse de productivité.

Un custom tool est une action directement appelable par le modèle. Une extension offre un cadre plus large, piloté par les événements, qui peut elle-même enregistrer des outils. Cette distinction aide à choisir la plus petite surface technique nécessaire.

Une puissance à auditer

Cette puissance impose une précaution essentielle : les extensions omp ne sont pas sandboxées. Elles s’exécutent dans le même processus, avec les permissions de votre utilisateur. Une extension inconnue peut donc accéder à ce que votre session peut atteindre.

Avant toute installation, relisez le code source et vérifiez les chemins chargés, les commandes lancées et les données transmises. Accordez les permissions minimales, limitez d’abord le périmètre à un dépôt de test et gardez une confirmation humaine pour une suppression, une publication ou toute opération sensible. Une extension utile doit rendre l’action plus contrôlable, pas élargir silencieusement les risques.

À quoi sert un skill ?

Une procédure chargée à la demande

Un skill rassemble un savoir-faire, une procédure et des références dans un paquet centré sur un fichier SKILL.md. Ses métadonnées légères peuvent être exposées à l’agent avant que le contenu complet soit chargé. Cette divulgation progressive évite d’injecter en permanence une longue procédure dans chaque échange.

Définissez toujours clairement name et description, même si certains providers acceptent des variantes plus permissives. La description doit aider l’agent à comprendre quand employer la méthode. Vous pouvez ensuite invoquer explicitement le skill avec /skill:<name> ; le schéma skill:// permet d’en lire le paquet à la demande.

---
name: release-dedimarco
description: Préparer et vérifier une publication bilingue Dedimarco.
---

## Procédure

1. Vérifier les versions française et anglaise.
2. Contrôler les sources, l’image et les critères de publication.

Du prompt ponctuel au savoir-faire réutilisable

Niveau	Durée et portée	Contenu typique	Exemple	Limite principale
Prompt	Tâche ou tour courant	Objectif et contexte immédiat	« Analyse cette erreur Astro »	Se répète et se perd facilement
Skill	Sessions et projets récurrents	Procédure, contraintes, références	Checklist de publication bilingue	Doit être tenu à jour
Extension	Capacité exécutable	Hook, outil, commande, intégration	Bloquer une action ou appeler une API	Code privilégié à auditer et maintenir

Le prompt demande, le skill explique comment travailler, et l’extension fournit de quoi agir. omp sait en outre découvrir des skills issus de plusieurs harnesses, notamment dans les layouts .claude/skills/ et .opencode/skills/. Cette compatibilité peut réduire la réécriture initiale, sans dispenser de vérifier les conventions et le comportement dans votre environnement.

Comment combiner skills et extensions sans les empiler ?

Le fil rouge : publier un article Dedimarco

Imaginons un skill release-dedimarco. Il décrit la checklist Astro 7, l’alignement des versions française et anglaise, la vérification des sources, les contraintes de l’image et les critères de qualité. Il ne publie rien : il donne à l’agent un mode opératoire stable et vérifiable.

Une extension complète cette méthode avec une commande /release-check. Celle-ci peut cibler les fichiers concernés, déclencher les contrôles prévus et demander une confirmation avant publication. Le prompt du jour reste ponctuel : « prépare l’article sur ce sujet et applique le skill ». Chaque couche conserve ainsi un rôle distinct.

Cet exemple est une illustration construite à partir des API documentées, pas un package officiel. Son intérêt tient à la séparation des responsabilités : l’extension fournit l’outil, le skill fournit le mode opératoire, le prompt fixe l’objectif immédiat.

Choisir la couche la plus légère

Si le besoin ne se présente qu’une fois, commencez par un prompt précis. Si la même méthode revient sur plusieurs livrables, transformez-la en skill. N’écrivez une extension que lorsqu’une capacité exécutable manque réellement : bloquer une action, appeler une intégration ou exposer une commande métier.

Chaque composant ajoute de la maintenance et une surface de risque. Empiler des règles, des outils et des hooks ne rend pas mécaniquement l’agent meilleur. La bonne architecture est celle dont vous pouvez encore expliquer, relire et retirer chaque élément.

Quelles adaptations sont utiles à un développeur ?

Rédiger et publier en deux langues

Une publication bilingue se prête bien à une méthode explicite. Le skill fixe l’ordre de travail, l’identité des métadonnées communes, la cohérence des sections et la vérification des sources. L’extension peut exécuter les contrôles autorisés et signaler les écarts. Vous mesurez alors des résultats concrets : les deux fichiers existent, leur structure correspond et les critères de publication sont suivis. Le modèle participe à la rédaction, mais la qualité reste jugée sur ces critères observables.

Diagnostiquer un bug avec discipline

Un skill de diagnostic empêche l’agent de sauter directement vers la première correction plausible. Il impose une boucle : reproduire le défaut, le réduire, formuler des hypothèses, instrumenter, corriger la source puis produire une preuve. Les capacités exécutables dépendent de la surface concernée : terminal pour un programme en ligne de commande, navigateur pour une interface web, DAP pour inspecter l’état d’un processus. L’outil sert l’enquête ; la procédure maintient sa rigueur.

Appliquer les conventions d’un dépôt

Un skill projet peut consigner l’architecture, les règles de validation, le style attendu et les chemins de référence. L’agent n’a plus à redécouvrir ces décisions à chaque tâche. Les outils spécialisés lui permettent ensuite d’agir sans les contourner. Là encore, séparez la méthode de la capacité : savoir qu’une modification doit rester locale n’est pas la même chose que disposer d’un outil pour l’effectuer.

Retrouver les décisions utiles

Les sessions omp sont persistantes, arborescentes et append-only. Elles peuvent conserver la continuité d’un travail. Une mémoire optionnelle peut aussi faire remonter des observations antérieures, mais elle reste heuristique et ne doit jamais primer sur le code actuel ou vos instructions. Stockez seulement les informations nécessaires, en tenant compte de leur sensibilité. Une ancienne décision retrouvée est un indice à confronter au dépôt, pas une vérité définitive.

Comment commencer petit et garder le contrôle ?

Choisissez d’abord une tâche récurrente dont le résultat se vérifie : préparer une release, diagnostiquer un incident ou publier un contenu bilingue. Écrivez un skill minimal avec un nom explicite, une description utile, quelques étapes et des critères d’acceptation. Utilisez-le sur un périmètre limité, puis corrigez ce qui manque réellement.

Ajoutez une extension seulement si la méthode réclame une action que le harness ne sait pas encore effectuer ou encadrer. Auditez son code, réduisez ses permissions et conservez une validation humaine pour les changements importants. Si une règle, une référence ou un outil n’apporte plus de valeur, retirez-le. Une personnalisation abandonnée, mais toujours active devient rapidement une dette et un risque.

Enfin, distinguez trois dimensions. La capacité technique indique ce que l’agent peut faire. La méthode précise quand et comment il doit le faire. La qualité du modèle influence le raisonnement et la rédaction. Aucun de ces éléments ne compense automatiquement les faiblesses des deux autres. Votre contexte, vos critères d’acceptation et votre supervision restent déterminants.

OpenCode Go est-il une option économique pour essayer ?

Une option à budget fixe

OpenCode Go coûte 10 $ par mois au 5 septembre 2026. Ses limites de base publiées correspondent à 12 $ de valeur d’usage sur cinq heures, 30 $ par semaine et 60 $ par mois. Elles varient selon le modèle et peuvent évoluer : considérez-les comme un cadre publié, pas comme une promesse de consommation garantie.

Comparez ce forfait aux autres moyens d’accès selon vos tâches, vos modèles et votre fréquence d’utilisation, plutôt que sur le seul prix affiché.

Pourquoi commencer avec GLM-5.3-Flash ?

GLM-5.3-Flash figure dans le catalogue OpenCode Go. Ses tarifs publiés sont de 0,15 $ par million de tokens en entrée, 0,50 $ en sortie et 0,03 $ en lecture de cache.

C’est donc un point de départ économique à évaluer sur une tâche réelle, pas une garantie de réussite ni le meilleur choix pour tous les projets. Donnez-lui un objectif borné, puis observez la qualité, la vitesse et la consommation avant de conserver ce modèle ou d’en choisir un autre.

Vous pouvez essayer OpenCode Go avec ce lien de parrainage. L’abonnement coûte 10 $ par mois au 5 septembre 2026. Après un premier abonnement admissible, le filleul et le parrain reçoivent chacun 5 $ de crédit Go, à appliquer depuis la console. L’auto-parrainage, un compte déjà parrainé ou ayant déjà bénéficié de Go ne sont pas admissibles.

Conclusion

Pi choisit un noyau minimal à composer ; omp choisit une intégration plus fournie. Dans les deux cas, la personnalisation reste plus claire lorsque chaque couche garde son rôle : le prompt demande, le skill formalise la méthode et l’extension exécute ou encadre une action.

Je vous recommande de partir d’un workflow utile, avec un résultat mesurable. Prouvez sa valeur sur une tâche bornée, gardez la validation humaine, puis étendez progressivement l’environnement. Un agent bien adapté n’est pas celui qui accumule le plus de fonctions, mais celui dont vous maîtrisez les règles, les capacités et les limites.

Sources

Sources consultées le 5 septembre 2026 :

• Pi Coding Agent — présentation, installation et personnalisation
• oh-my-pi — présentation et installation
• oh-my-pi — extensions
• oh-my-pi — skills
• oh-my-pi — stockage des sessions
• oh-my-pi — mémoire optionnelle
• OpenCode Go — prix, modèles et limites d’usage
• OpenCode — règles du programme de parrainage