tl;dr : faites en sorte que votre agent s'exprime visuellement plutôt qu'en murs de prose.
1npx skills add humanlayer/skills --skill show-me
Plus léger et plus rapide que le HTML, et assez bon pour la plupart des problèmes de dev.
Les agents de codage sont à peu près illisibles
L'ancien CEO de Reddit :
https://x.com/yishan/status/2086534431075098628
Mario Zechner, créateur de pi :
https://x.com/badlogicgames/status/2087068077309542889
Connor de Replicas :
https://x.com/connortbot/status/2081881377147109413
Dillon Mulroy a même créé un skill popularisé un skill de [@backnotprop](https://x.com/@backnotprop) pour demander au modèle de simplifier son langage.
https://x.com/dillon_mulroy/status/2079238358358778142
Le contenu est le suivant :
Reformulez votre dernier message. Arrêtez le jargon et parlez de manière cohérente. Exprimez-vous plus simplement et plus brièvement, comme un humain qui parle à un autre.
j'en ai vraiment marre
Les agents sont devenus plus intelligents sur le papier, mais l'expérience d'utilisation s'est nettement dégradée sur ce plan.
Ce que les gens aimaient chez Claude — sa voix, sa personnalité, son « âme » — a été lessivé dans le donjon du RL.
sol est un peu moins gênant, mais il nous sert encore régulièrement des murs de jargon qui font décrocher.
Voici une réponse que j'ai reçue récemment. Ça arrive plusieurs fois par jour.
ma proposition : show-me
Nous avons bricolé des outils internes pour améliorer ça, notamment pour le codage, et nous les publions dans un skill que nous avons appelé show-me.
Il est disponible dans humanlayer dès aujourd'hui, et si vous le voulez dans n'importe quel autre agent de codage, vous pouvez l'obtenir ici :
1npx skills add humanlayer/skills --skill show-me
Ou procurez-vous la version intégrée de humanlayer qui prend en charge le HTML en ligne et les diagrammes de manière native :
1brew trust humanlayer/humanlayer2brew tap humanlayer/humanlayer3brew install humanlayer
Si vous avez déjà regardé la conférence de Coda Hale sur l'intuition vs l'attention dans les systèmes d'infrastructure, c'est en partie inspiré de ça :
- analyser des informations est difficile et épuisant
- votre cortex visuel a été entraîné pendant des millions d'années à traiter sans effort des informations visuelles riches
- optimisez les outils en conséquence
Tout comme une hache doit épouser la main humaine pour être utile, un logiciel doit épouser l'esprit humain pour être utile
/show-me invite l'agent à utiliser des visuels concis pour expliquer ce qui se passe, plutôt que des murs de prose.
C'est vraiment utile pour la conception de programme — la phase que beaucoup de gens sautent de nos jours, mais que je considère comme essentielle. Vous devriez discuter de la forme du code (les types, les signatures, les piles d'appels) avant que les agents ne se mettent au travail pour l'écrire.
Les mêmes techniques peuvent aussi être utilisées pour explorer de gros diffs après coup, afin de comprendre ce qu'il faut creuser pendant la revue de code.
Ce qu'il y a dedans
arbres de composants
Même idée côté frontend, en gardant les hooks d'état et les frontières de modules qui comptent, et en laissant tout le reste de côté.
J'ai partagé celui-ci sur Twitter en décembre 2025 :
https://x.com/dexhorthy/status/1998968236617199803
piles d'appels
Pour du travail d'orchestration ou de contrôle de flux, ou simplement tout problème de type backend, Dillon nous a donné cette forme de « pile d'appels ».
https://x.com/dillon_mulroy/status/2059985696148849025
Tanishq a même écrit un outil pour les calculer directement depuis l'AST :
https://x.com/tanishqk/status/2085800689129935342
diagrammes
Un classique. Si votre interface de chat prend en charge le rendu Mermaid en ligne, ça peut beaucoup aider. (Parfois c'est encore du slop, mais c'est généralement mieux que de lire des mots)
Beaucoup d'options ici. Nous aimons surtout les diagrammes d'état et les diagrammes de séquence.
organisation des fichiers
Une arborescence de fichiers simplifiée, une ligne de responsabilité par entrée. Pratique pour savoir « où ça vit » et pour cadrer un refactoring.
pseudocode
Surtout pour les trucs algorithmiques, le pseudocode peut être plus concis.
types et signatures
La forme du code avant même qu'il n'existe — ce qui est trop interne pour un document d'architecture, mais sur lequel un agent peut encore se tromper.
1interface Item {2 id: ItemId3 parentId: ItemId | null4 // ...5}67interface Cursor {8 position: ItemId9 direction: 'up' | 'down'10 // ...11}1213resolveTarget(items: Item[], cursor: Cursor) -> ItemId | null
syntaxe de diff
Vous pouvez aussi utiliser la syntaxe de diff pour ça, si la plupart du contenu est inchangé :
Pour un changement de composant :
Pour un changement d'arbre d'appels :
Pour un changement d'organisation de fichiers :
Et pour un changement d'état ou de flux de contrôle, où la forme est du pseudocode plutôt que du vrai code :
maquettes HTML
Le HTML a remplacé Figma pour une grande partie de notre travail de prototypage. (pour être honnête, je n'ai jamais vraiment été très à l'aise avec Figma de toute façon)
diagrammes HTML
Parfois, c'est un diagramme ou une explication qu'il vous faut.
Dans humanlayer, nous laissons l'agent inclure du HTML directement dans les réponses de l'assistant.
Mais vous pouvez aussi simplement l'ouvrir dans votre navigateur.
autres inspirations
Je veux aussi tirer mon chapeau à @mattpocockuk pour les explications HTML générées par son skill /teach — très bien fait.
allez l'essayer
1npx skills add humanlayer/skills --skill show-me
Après avoir installé le skill, invoquez /show-me ou demandez à l'agent d'utiliser le skill show-me. Pointez-le vers une route, un service, une fonctionnalité, une pull request ou un sujet du moment, ou utilisez-le simplement pour demander au modèle de reformuler une question ou une déclaration.
C'est trop de contenu. Montre-moi.
ou
/show-me en tant qu'explication HTML
Dites-nous ce que vous en pensez ! Taguez @humanlayer_dev ou @dexhorthy avec vos résultats ou ce que vous avez personnalisé/ajouté, et on en discute !
GIF
