/show-me: representações visuais compactas para agentes de programação

tl;dr: faça seu agente conversar visualmente em vez de em paredes de texto.

1npx skills add humanlayer/skills --skill show-me

Mais leve e rápido que HTML, bom o suficiente para a maioria dos problemas típicos de desenvolvimento.

Agentes de programação são praticamente ilegíveis

O ex-CEO do Reddit:

https://x.com/yishan/status/2086534431075098628

Mario Zechner, criador do pi:

https://x.com/badlogicgames/status/2087068077309542889

Connor, da Replicas:

https://x.com/connortbot/status/2081881377147109413

Dillon Mulroy até criou uma skill *popularizou uma skill do @backnotprop para pedir que o modelo simplifique a linguagem.

https://x.com/dillon_mulroy/status/2079238358358778142

O conteúdo é:

Reformule sua última mensagem. Pare de usar jargões e fale de forma coerente. Diga de forma mais simples e concisa, como um humano falando com outro.

estou de saco cheio disso

Os agentes ficaram mais inteligentes no papel, mas a experiência de usá-los piorou visivelmente nesse aspecto

O que as pessoas costumavam amar no Claude — a voz, a personalidade, a "alma" — foi apagado no calabouço do RL

A sol é um pouco menos cringe, mas ainda nos bombardeia regularmente com paredes de jargão que fazem os olhos ficarem vidrados

Aqui está uma resposta que recebi recentemente. Isso acontece várias vezes por dia

minha proposta: show me

Temos brincado com ferramentas internas para melhorar isso, especificamente para programação, e as publicamos em uma skill que chamamos de show-me.

Ela já está no ar no humanlayer hoje, e se você quiser usá-la em qualquer outro agente de programação, pode obtê-la aqui:

1npx skills add humanlayer/skills --skill show-me

Ou instale a versão nativa do humanlayer, que inclui HTML inline e diagramas de primeira classe:

1brew trust humanlayer/humanlayer
2brew tap humanlayer/humanlayer
3brew install humanlayer

Se você já assistiu à palestra do coda hale sobre intuição vs. atenção em sistemas de infraestrutura, isso é um pouco inspirado nela:

• analisar informação é difícil e exaustivo
• seu córtex visual foi treinado ao longo de milhões de anos para processar informações visuais ricas sem esforço
• otimize as ferramentas de acordo

Assim como um machado precisa se ajustar à mão humana para ser útil, o software precisa se ajustar à mente humana para ser útil

/show-me instrui o agente a usar recursos visuais concisos para explicar o que está acontecendo, em vez de paredes de texto.

Isso é muito bom para design de programa — a fase que muitos ignoram hoje em dia, mas que eu considero essencial. Você deve discutir o formato do código (os tipos, as assinaturas, as pilhas de chamadas) antes de os agentes começarem a escrevê-lo.

As mesmas técnicas também podem ser usadas para explorar grandes diffs a posteriori e entender no que se aprofundar durante a revisão.

O que tem dentro

árvores de componentes

A mesma ideia no frontend, mantendo os hooks de estado e os limites de módulo que importam e deixando todo o resto de fora.

Compartilhei este no Twitter em dezembro de 2025:

https://x.com/dexhorthy/status/1998968236617199803

pilhas de chamadas

Para trabalho de orquestração ou fluxo de controle, ou qualquer problema com cara de backend, o Dillon nos deu esse formato de "pilha de chamadas".

https://x.com/dillon_mulroy/status/2059985696148849025

O Tanishq até escreveu uma ferramenta para calculá-las direto da AST

https://x.com/tanishqk/status/2085800689129935342

diagramas

Um clássico. Se sua interface de chat suporta mermaid inline, isso pode ajudar muito. (Às vezes ainda sai porcaria, mas geralmente é melhor do que ler palavras)

Tem muitas opções aqui. Gostamos mais de diagramas de estado e de sequência.

estrutura de arquivos

Uma árvore de arquivos rasa, com uma linha de responsabilidade por entrada. Ótima para saber "onde isso mora" e para delimitar o escopo de uma refatoração.

pseudocódigo

Principalmente para coisas algorítmicas, o pseudocódigo pode ser mais conciso.

tipos e assinaturas

O formato do código antes de existir qualquer coisa — o que é interno demais para um doc de arquitetura, mas que um agente ainda assim pode errar.

1interface Item {
2  id: ItemId
3  parentId: ItemId | null
4  // ...
5}
6
7interface Cursor {
8  position: ItemId
9  direction: 'up' | 'down'
10  // ...
11}
12
13resolveTarget(items: Item[], cursor: Cursor) -> ItemId | null

sintaxe de diff

Você também pode usar sintaxe de diff para isso, se a maior parte do conteúdo não mudou:

Para uma mudança de componente:

Para uma mudança de árvore de chamadas:

Para uma mudança de estrutura de arquivos:

E para uma mudança de estado ou de fluxo de controle, em que o formato é pseudocódigo em vez de código real:

mockups em HTML

O HTML substituiu o Figma em grande parte do nosso trabalho de prototipagem. (pra ser sincero, nunca fui muito habilidoso com o Figma de qualquer forma)

diagramas em HTML

Às vezes, o que você precisa é de um diagrama ou de um explicador.

No humanlayer, deixamos o agente incluir HTML diretamente nas respostas do assistente.

Mas você também pode simplesmente abri-lo no navegador.

outras inspirações

Também quero tirar o chapéu para o @mattpocockuk pelos explicadores em HTML gerados pela skill /teach dele — muito bons.

vai testar

1npx skills add humanlayer/skills --skill show-me

Depois de instalar a skill, invoque /show-me ou peça ao agente para usar a skill show-me. Aponte para uma rota, serviço, funcionalidade, pull request ou tópico atual, ou apenas use-a para pedir que o modelo reformule uma pergunta ou afirmação.

isso é conteúdo demais. me mostra.

ou

/show-me como um explicador em HTML

Conta pra gente o que você achou! Marca o @humanlayer_dev ou o @dexhorthy com seus resultados ou com o que você personalizou/adicionou e vamos trocar ideias!

GIF