ponytail: o mesmo trabalho com metade do código

O que é e porque importa

Pedes ao Claude um calendário para escolher uma data, e ele constrói um do zero: 335 linhas para ler e corrigir quando avariam. E o teu projeto já tinha o seu campo de texto, e todos os navegadores já trazem um calendário. Bastavam dez linhas.

O ponytail põe dentro do teu Claude um programador sénior preguiçoso, no bom sentido. Antes de escrever, lê o código em que a alteração mexe e procura o que já existe: no projeto, no navegador ou na linguagem, nas bibliotecas que tens instaladas. Depois escreve só o que falta. Mas os controlos não os corta, e onde há dinheiro ou segurança deixa um pequeno teste.

É um prompt (uma skill, ou seja, um ficheiro de instruções para o Claude) mais um plugin que o carrega em cada sessão. Gratuito, licença MIT, mais de 180.000 estrelas no GitHub no fim de outubro. O autor mediu-o em 39 tarefas: em média menos 53% de linhas e menos 26% de custo. Como lê-los: passo 6. É para quem constrói sozinho com o Claude Code e não quer reler código inútil.

1. Instala-o no Claude Code

Abre o Claude Code e envia estas duas linhas como duas mensagens separadas: numa só, diz o guia de instalação, não funciona.

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

A primeira adiciona o marketplace, o catálogo de onde o Claude Code vai buscar o plugin. A segunda abre a ficha do plugin: lê o que instala e escolhe «Install for you», para valer em todos os teus projetos. Na app de desktop, separador Code, escreve as mesmas linhas no campo do prompt.

Para confirmar que está ativo:

1. Em /plugin, separador Installed, está o ponytail.
2. No início de cada sessão, o ponytail mostra o nível ativo.
3. Só /ponytail diz-te o nível; se estava desligado, liga-o.

Outros agentes: copia o ficheiro AGENTS.md do repo para o teu projeto (regras sempre ativas, sem comandos) ou segue o INSTALL.md.

2. Como pensa: a escada antes de escrever

O coração do ponytail é uma escada. Lê a tarefa e o código em que mexe, e para no primeiro degrau que resolve tudo:

1. É mesmo preciso? O que ninguém pediu, salta-o e diz-to numa linha.
2. Já existe no projeto? Um componente ou uma função que usas noutro sítio: usa isso.
3. A linguagem ou o navegador fazem isso? Usa isso, mas um componente do projeto vem primeiro.
4. Uma biblioteca já instalada faz isso? Nunca uma biblioteca nova por meia dúzia de linhas.
5. Chega uma linha clara? Uma linha.
6. Só então o mínimo de código que funciona, com um pequeno teste se houver lógica.

O calendário vem do benchmark dele, com o pedido «adiciona um seletor de datas». Sem ponytail, 335 linhas. Com ponytail, 10, que reutilizam o componente Input do projeto com type="date": o calendário é o navegador que o traz. Sendo honesto: é o caso mais extremo das 39 tarefas. Em muitas tarefas pequenas a diferença é pouca ou nenhuma.

Para o veres a trabalhar, pede assim (muda as partes entre [ ]):

Adiciona [um seletor de datas] a [o formulário de reserva]. Antes de escreveres, diz-me o que já existe no projeto, no navegador ou nas bibliotecas instaladas que faça este trabalho, e em que degrau paraste.

3. Os três níveis de intensidade, e off

Arranca sozinho, no nível full. Mudas com /ponytail e o nível, até ao fim da sessão.

• lite: faz o que pediste e numa linha propõe-te a versão mais pequena. Uso-o quando o pedido já está decidido.
• full: a escada do passo 2, com o teste onde é preciso. É o que mantenho quase sempre.
• ultra: além disso põe o pedido em causa e, antes de construir, diz-te o que a necessidade não justifica. Uso-o no início de um projeto.
• off: desliga-o. Também chega uma mensagem só com «stop ponytail».

/ponytail ultra

Para mudar o nível de partida de todas as sessões, escreve-o em ~/.config/ponytail/config.json (no Windows em %APPDATA%\ponytail):

{ "defaultMode": "lite" }

Ou há a variável de ambiente PONYTAIL_DEFAULT_MODE, que se sobrepõe ao ficheiro. Com "off" não arranca sozinho: ligas tu com /ponytail.

4. Os dois comandos de revisão

Os dois escrevem um relatório e não mexem no código. Cada problema vem numerado e diz o que faz esse código, o que corre mal, como se corrige e o que acontece se o deixares. O relatório costuma vir num inglês simples.

/ponytail-review: a alteração que acabaste de fazer

Sozinho, olha para as alterações que ainda não estão num commit, ou para o último commit se não houver nenhuma. Lê também o código que as usa, porque uma alteração pode estragar um ficheiro em que não mexeste. Para escolher o que vê, acrescenta uma palavra: uncommitted, staged (prontas para o commit), branch ou o link de um PR.

/ponytail-review branch

Depois responde com os números:

Corrige a 1 e a 3 com a correção mais pequena que propuseste. As outras deixa-as.

/ponytail-audit: o projeto inteiro, por ordem

Os mesmos controlos, no repo inteiro ou na pasta que lhe indicares. Primeiro faz o mapa: por onde entram os dados, onde acabam, quanta carga tem de aguentar. Depois ordena no máximo 20 problemas, do mais grave para o menos, e diz-te por onde começar. Eu lanço-o num projeto que não abro há meses.

/ponytail-audit

Se no menu do Claude Code vires os comandos com o nome do plugin à frente, tipo /ponytail:ponytail-review, usa essa forma.

5. Os atalhos assinalados e a faixa por cima do prompt

Quando escolhe um atalho com um limite conhecido, o ponytail escreve-o no código com um comentário shortcut: seguido do limite e de quando mudá-lo. Por exemplo uma lista em memória que aguenta enquanto os utilizadores forem poucos. São decisões, não erros, mas é preciso relê-las: o /ponytail-debt junta-as num registo e assinala as que não dizem quando revê-las.

/ponytail-debt

Escreve este registo em PONYTAIL-DEBT.md.

Com um Claude Code recente, no terminal e na app de desktop, há uma faixa por cima do prompt: quanto a tarefa consome, o tempo do agente, quanto código reutilizou, se os testes passaram. /ponytail band esconde-a e volta a mostrá-la.

6. Os números, lidos com honestidade

São números do próprio autor: 39 tarefas, Claude Code com Opus, 5 execuções por tarefa. O método e os scripts estão no repo.

• Linhas de código: menos 53% em média (entre 41% e 63%).
• Custo: menos 26% a preço de tabela (entre 16% e 36%). Com uma subscrição não pagas menos: gastas menos do teu limite.
• Um teste onde a lógica o pede: 98% das vezes, contra 68% sem ponytail.
• Correção, nas 18 tarefas com verificações escondidas: empate. Menos código não tirou segurança, mas também não acrescentou.

No benchmark o agente não podia correr comandos: mede-se o que escreve, não como trabalha no teu projeto. E o ponytail continua a ser um prompt: o Claude pode enganar-se na mesma, e os atalhos és tu que os relês.

Os erros mais comuns

• Enviar as duas linhas de instalação numa só mensagem.
• Instalá-lo a partir de uma cópia: o original é só DietrichGebert/ponytail no GitHub (ou @dietrichgebert/ponytail no npm) e nunca contém ficheiros .exe ou .dll.
• Não ter Node.js: as instruções funcionam, mas em cada mensagem aparece o erro «node: command not found».
• Deixar os comentários shortcut: por ler: o limite que indicam chega mais cedo ou mais tarde.

Checklist

• Enviei as duas linhas de instalação como duas mensagens separadas
• Ao escrever /ponytail vejo o nível ativo
• Experimentei o /ponytail-review numa alteração minha a sério
• Li os atalhos com o /ponytail-debt

Perguntas frequentes