pstack-claude : porter une pile de compétences Cursor vers plusieurs agents de code

Contexte et définition du problème

Les agents de code ont beaucoup progressé en un an, mais un même modèle peut se comporter très différemment d'une tâche à l'autre. Souvent, la faiblesse ne vient pas du modèle, mais du processus autour de lui. L'agent modifie le code avant d'avoir reproduit la panne. Il annonce une correction sans vérifier les preuves. Ou il transforme un petit changement en refonte étendue. pstack cible ce manque de processus.

D'après le README, pstack de Lauren Tan est une pile de compétences Cursor tranchée, conçue pour améliorer les résultats des agents. pstack-claude en est un portage pour Claude Code, Codex, Pi et d'autres environnements d'agents. La description du dépôt cite aussi OpenCode, Gemini et Prime Agent. La difficulté d'un tel portage n'est pas de copier du texte. Il faut traduire les primitives que fournit Cursor, comme les sous-agents, les questions et les réveils, vers leurs équivalents dans d'autres environnements. Le dépôt le résume ainsi : « Cursor primitives translated for other harnesses ».

Le problème est concret. Les équipes utilisent souvent plusieurs outils d'agents, chacun avec son format de compétences et sa manière de les appeler. Si un bon workflow reste lié à un seul éditeur, l'expérience ne se réutilise pas. Un portage permet à la même méthode de se comporter de façon cohérente d'un environnement à l'autre. Un mot sur la méthode : cet article repose sur la lecture du README. Nous n'avons pas installé ni exécuté le projet. Tout jugement sur l'effet relève donc de l'analyse de conception, pas d'une mesure.

Cœur architectural et principes techniques

Le README permet de reconstituer le projet en quatre couches. La première couche est la compétence d'entrée, poteto-mode. Vous énoncez un objectif, par exemple « corriger le filtre de recherche qui se réinitialise quand je change de page », et elle choisit le bon workflow. Le README indique qu'elle garde le code concis, simple et vérifié. Le fichier SKILL.md liste des playbooks pour la planification, les fonctionnalités, la refactorisation, les problèmes de performance, les enquêtes, les prototypes, la maintenance de PR, la livraison et les projets plus longs. La deuxième couche est un ensemble de compétences composables. L'exemple du README mentionne `how`, `why` et `architect`. Pour un bogue, le déroulement est le suivant. L'agent reproduit la panne. Il enquête avec `how` et `why`. Il délègue la correction. Puis il relance le cas qui échouait. Si la correction franchit la frontière d'une fonction, poteto-mode fait intervenir `architect` avant l'implémentation. Vous recevez la correction, avec les preuves d'échec et de réussite. Cette livraison fondée d'abord sur les preuves est la partie la plus précieuse de la conception.

La troisième couche est l'adaptation à chaque environnement. Sur Claude Code, l'installation passe par la place de marché de plugins avec `/plugin marketplace add michael-denyer/pstack-claude` puis `/plugin install pstack@pstack-claude`. Codex utilise `codex plugin marketplace add` et `codex plugin add`. Pi utilise `pi install git:github.com/michael-denyer/pstack-claude`. Sur Pi, le paquet charge aussi une extension pstack. Elle ajoute les outils de sous-agent, de question et de réveil, une commande `/loop` et la consigne de routage. Le portage ne se limite donc pas à déplacer le texte des compétences. Il fournit une implémentation là où un environnement n'a pas la primitive. La quatrième couche concerne la politique et la configuration. Le portage suit l'amont et porte des forks de politique nommés, chacun déclaré dans `tools/forks.json`. La compétence `setup-pstack` modifie les modèles par défaut et fixe un effort de raisonnement par rôle. L'exemple du README est `arena runners: opus @xhigh, fable @max`. Sur Claude Code, ces réglages passent par les agents `pstack:effort-` ou `pstack:poteto-agent-` du plugin. Un rôle sans niveau garde l'effort de la session, sauf si la ligne `default effort` de la feuille en indique un. Le routage automatique peut être désactivé.

Évaluation pratique et applications

Trois fonctions méritent l'attention. La première est le routage automatique. Sur Claude Code et Codex, le plugin installe un hook de routage afin que toute tâche entrante passe d'abord par poteto-mode. Codex demande de faire confiance au hook via `/hooks` avant son exécution. C'est un choix de sécurité sain, car un hook change le comportement de l'agent et ne doit pas être activé en silence. Sur Pi, l'extension injecte la même consigne de routage. La deuxième est le réglage du modèle et de l'effort par rôle. Vous pouvez réserver le raisonnement coûteux et intense aux rôles qui en ont besoin, et faire tourner les autres à un niveau plus bas. Cela permet un arbitrage fin entre qualité et coût. La troisième est la frontière des données. Le README indique que pstack n'a ni serveur ni télémétrie. Tout ce que ses compétences demandent à votre agent de lire, y compris les transcriptions de session, part chez votre fournisseur de modèle. Les scripts s'exécutent en local, et les outils de PR utilisent votre connexion à la CLI GitHub. Cette formulation est franche. Elle ne promet pas que les données ne quittent jamais la machine. Elle dit où elles vont.

Côté usage, la pile convient aux tâches dont les critères d'acceptation sont clairs, comme un défaut qu'on peut écrire sous forme de cas en échec. Pour un travail exploratoire vague, les playbooks de planification et d'enquête conviennent mieux. Il faut aussi nommer les limites. Un processus plus strict coûte plus d'appels et de temps par tâche. Le résultat dépend de la capacité du modèle sous-jacent à suivre les consignes. Reste à vérifier, dans votre propre environnement cible, que la traduction des primitives est vraiment équivalente. Au moment de la rédaction, le dépôt affiche environ 1 194 étoiles. Nous n'avons trouvé aucun benchmark reproductible, donc nous ne concluons rien sur l'ampleur de l'amélioration.

Impact sur l'industrie et perspectives

pstack-claude reflète une tendance qui prend forme : les compétences et les workflows deviennent des actifs portables, indépendants d'un produit d'agent donné. Autrefois, les prompts et les procédures restaient dans les réglages d'un éditeur. Aujourd'hui, les places de marché de plugins, les répertoires de compétences et les systèmes de hooks ont des formes voisines dans plusieurs outils, et « écrire une fois, installer partout » devient réaliste. Le projet montre aussi une façon de maintenir côte à côte un amont et un aval. Le portage suit l'amont et inscrit ses propres écarts de politique dans une liste explicite, `tools/forks.json`. C'est plus transparent que des retouches discrètes, et l'utilisateur sait quelles règles il a installées. L'auteur publie également un plugin distinct, agent-formal-verify, qui ajoute la vérification de modèles TLA+ et des preuves Lean pour les bogues de concurrence et les invariants que les tests n'atteignent pas. Le partage est net. pstack assure la rigueur des workflows quotidiens. La vérification formelle couvre les recoins que les tests manquent.

Deux questions restent ouvertes. D'abord, l'écart entre les primitives des environnements va-t-il croître avec l'évolution de chaque outil, et le coût du portage avec lui ? Ensuite, peut-on mesurer objectivement la qualité d'un workflow ? Seules des évaluations publiques et reproductibles feront passer une pile de compétences de « semble raisonnable » à « fonctionne, preuves à l'appui ». Une équipe qui veut essayer devrait commencer dans un dépôt à faible risque, prendre un cas en échec existant, et vérifier si les preuves livrées réduisent vraiment les reprises.