Extensibilité de Pi

Le modèle d’extension de Pi

Pi adopte une philosophie “core minimal, tout extensible”. Là où Claude Code intègre 15+ outils, un system prompt de ~10 000 tokens, des hooks, des permissions et MCP en natif, Pi démarre avec 4 outils (read, write, edit, bash) et un system prompt de ~200 tokens.

Tout le reste s’ajoute par-dessus via quatre mécanismes d’extension.

1. Extensions (packages npm/git)

Une extension est un package installable qui ajoute des outils, des hooks ou des commandes à Pi :

pi install npm:@team/lint-extension
pi install git:github.com/user/my-tools

Chaque extension peut exposer de nouveaux outils que le modèle pourra appeler, exactement comme les 4 outils core. La différence avec MCP : les extensions Pi sont des packages JavaScript/TypeScript installés localement, pas des serveurs indépendants communiquant via un protocole standardisé.

2. Skills (fichiers Markdown)

Les skills de Pi sont des fichiers Markdown qui encapsulent un workflow récurrent. Elles fonctionnent comme les slash commands de Claude Code : un prompt pré-rédigé et paramétrable que l’agent exécute.

Une skill capitalise un savoir-faire. Au lieu de réécrire un prompt à chaque fois, on l’encode une fois et on le réutilise. C’est le leverage point LP12 (instructions persistantes) rendu explicite.

3. Prompt templates

Des templates réutilisables pour des tâches récurrentes. Plus légers qu’une skill, ils servent de point de départ pour des variations d’un même type de requête (ex : “review de PR”, “ajout d’endpoint REST”).

4. Sessions en arbre

Pi supporte des sessions avec branchement (arbre), contrairement aux sessions linéaires de Claude Code. On peut créer des branches à partir d’un point de la conversation pour explorer plusieurs pistes sans perdre le contexte parent.

Les sessions en arbre permettent d’explorer des alternatives sans polluer l’historique principal. Utile pour tester deux approches de refactoring et garder la meilleure.

Comparaison des mécanismes d’extensibilité

Le modèle extensible de Pi donne un contrôle total, mais impose un coût d’assemblage. Il n’y a pas de configuration “clé en main” — chaque équipe doit construire son propre stack d’extensions. C’est un choix délibéré : flexibilité maximale contre facilité d’adoption.

Lien avec l’Agentic Layer

Le concept d’Agentic Layer consiste à traiter la configuration de l’agent comme une couche architecturale à part entière : skills, garde-fous, observabilité, budget.

Dans Pi, cette couche se construit explicitement par assemblage :

• Skills = les workflows délégables à l’agent
• Extensions = les outils et hooks (garde-fous, vérifications)
• Prompt templates = la standardisation des interactions
• Sessions en arbre = l’observabilité et l’exploration

Avec Pi, l’Agentic Layer n’est pas implicite (comme dans Claude Code avec CLAUDE.md + hooks + MCP). Elle est entièrement explicite et assemblée pièce par pièce. Plus de travail initial, mais plus de contrôle sur chaque composant.

Extensions vs MCP : quand préférer quoi

Les extensions Pi et les serveurs MCP résolvent le même problème (étendre les capacités de l’agent) avec des architectures différentes :

• Extension Pi : package local, même processus, spécifique à Pi, simple à développer, pas d’interopérabilité cross-agent.
• Serveur MCP : processus séparé, protocole standardisé, interopérable (fonctionne avec Claude Code, Cursor, etc.), plus complexe à développer.

Pour une équipe qui utilise exclusivement Pi, les extensions suffisent. Pour une équipe avec des agents hétérogènes, MCP offre une standardisation transverse.

Construire une Agentic Layer avec Pi

Pour une équipe, la stratégie la plus robuste est de centraliser les extensions dans un mono-repo versionné :

1. Un package d’extensions d’équipe (hooks, outils, vérifications) installable via git
2. Des skills partagées dans le repo projet (comme un CLAUDE.md)
3. Des prompt templates standardisés pour les tâches récurrentes
4. Une documentation de la configuration attendue

C’est l’équivalent Pi d’un CLAUDE.md + hooks + MCP bien configuré dans Claude Code — mais assemblé explicitement plutôt qu’intégré par défaut.