As 6 skills do Ponytail: qual comando usar em cada situação

Fala aí, beleza? O Ponytail virou febre no GitHub e a maioria das pessoas usa ele igual: instala, deixa o modo padrão ligado e nunca mais toca no assunto

Aí ficam cinco skills paradas ali, esperando

O Ponytail é um projeto open source criado e mantido por DietrichGebert, com uma descrição que já entrega o espírito da coisa: "Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote."

Ou seja: fazer seu agente pensar como o dev senior mais preguiçoso da sala (e isso é bom!)

O detalhe que muita gente não sabe: ele não é um comando só

São seis skills que aparecem como comandos de barra: /ponytail, /ponytail-review, /ponytail-audit, /ponytail-debt, /ponytail-gain e /ponytail-help

Cada um responde um tipo de pergunta diferente

Bora mapear? 😀

O que você precisa antes de usar as skills

Duas coisas, só

A primeira: um agente de código compatível

O Ponytail não é exclusivo do Claude Code, ele é distribuído para vários agentes: Claude Code, Codex CLI, GitHub Copilot CLI, Cursor, Windsurf, OpenCode e Gemini CLI, entre outros

Se o teu ambiente for o OpenCode, aliás, vale dar uma olhada em qual interface usar em cada situação antes, porque muda o fluxo de trabalho

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

A segunda: o Ponytail instalado

No Claude Code, a instalação é por plugin, dois comandos:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

O primeiro adiciona o marketplace, o segundo instala o plugin

E se a ideia de "skill" ainda soa meio abstrata pra ti, tem um post aqui do blog explicando a diferença entre skills, comandos e subagentes que ajuda a encaixar a peça

As 6 skills do Ponytail, uma a uma: o que cada comando responde

Cada bloco aqui tem três coisas: a pergunta que o comando responde, o que ele te devolve e o erro comum que faz a galera usar errado

1. /ponytail: a skill principal, o modo que roda ANTES do código

A pergunta que ela responde: "qual é a solução mais simples que resolve isso?"

Essa é a skill principal e ela força a solução mais simples que funciona, aplicando uma escada de decisão YAGNI: essa tarefa precisa existir? dá pra usar a biblioteca padrão em vez de código próprio? dá pra usar recurso nativo da plataforma em vez de puxar dependência?

O agente para no primeiro degrau que resolve, e segue

É um modo sempre ativo, que roda antes de escrever código, não um relatório

Ela tem três intensidades: lite (segue o teu pedido mas sussurra a alternativa), full (o padrão: faz o certo e te avisa da dívida) e ultra (contesta o teu pedido de frente, na lata)

Dá pra desligar e religar também: /ponytail off desliga, /ponytail religa

Erro comum: achar que é comando de uma passada só, tipo "rodei, deu resultado, acabou". Não é. É modo, ele fica lá influenciando cada decisão de código até você desligar

2. /ponytail-review: a pergunta é "o que eu inventei demais NESTE diff?"

Essa skill examina o diff atual em busca de over-engineering e devolve uma lista do que apagar: um achado por linha, com a substituição sugerida

Os alvos típicos são bem reconhecíveis: reinventar a stdlib, dependência desnecessária, abstração especulativa e flexibilidade morta (aquele parâmetro que você jurou que ia usar um dia)

O escopo dela é APENAS complexidade e over-engineering

Bug de correção, falha de segurança e performance estão explicitamente de fora, esses casos vão pra uma revisão normal

E ela não aplica as correções, só lista

Erro comum: usar o /ponytail-review no lugar da revisão de código normal e sair achando que o PR está limpo. Ele te diz o que sobra, não te diz o que está quebrado

3. /ponytail-audit: a pergunta é "quanta gordura tem no repositório INTEIRO?"

Mesmo espírito do review, escopo MUITO maior: em vez de olhar só o diff, ele varre o repositório todo procurando over-engineering

O que volta é uma lista ranqueada do que apagar, simplificar ou trocar por equivalente da stdlib ou recurso nativo, terminando com o total de linhas e dependências que dá pra cortar

Os alvos típicos são aquele clássico de projeto que cresceu sem poda: dependência que a stdlib ou a plataforma já entrega, interface com uma única implementação, factory com um só produto, wrapper que apenas delega, arquivo que exporta uma coisa só, flags e config mortos e stdlib feita à mão

Erro comum: esperar que ele corrija. É relatório de uma passada só, ele não aplica nada. Você lê, decide e manda apagar

4. /ponytail-debt: a pergunta é "o que eu deixei pra depois e nunca mais olhei?"

Essa aqui é diferente das outras e é a minha favorita de conceito

Ela coleta todos os comentários marcados com ponytail: no código e monta um registro de dívida

A convenção do marcador é ponytail: <teto>, <caminho de upgrade>, ou seja: até onde essa solução simples aguenta, e qual é o caminho quando ela não aguentar mais

Cada ocorrência vira uma linha do registro

A localização é por grep no repositório, ignorando node_modules, .git e saída de build:

grep -rnE '(#|//) ?ponytail:' .

Erro comum: marcador fora da convenção não entra no registro. Se você escreveu do teu jeito, o grep não pega e a dívida some do mapa

5. /ponytail-gain: a pergunta é "quanto essa parada economiza, no geral?"

Ele mostra um placar compacto do impacto medido: menos código, menos custo, mais velocidade

Só que atenção AQUI, porque é onde mora a confusão: esses números vêm das medianas do benchmark do projeto

É exibição de uma passada só, não é um modo persistente, e não é um número calculado a partir do TEU repositório

Erro comum: ler o placar como métrica local e sair dizendo "o Ponytail cortou 54% do meu código". Não foi o teu código que ele mediu 🙂

6. /ponytail-help: a pergunta é "peraí, qual era mesmo o comando?"

O cartão de referência rápida dos modos, skills e comandos do Ponytail

Exibição de uma passada só: não muda o modo, não escreve arquivo de flag, não persiste nada

Ele também responde a "ponytail help" ou "what ponytail commands", então se você esquecer a barra, ainda funciona

Erro comum: quase nenhum, esse é o mais inofensivo do pacote. O erro é não lembrar que ele existe e ficar caçando na documentação

Três situações reais e o comando certo para cada uma

Agora a parte que interessa: parar de rodar sempre o mesmo comando

Se liga em três cenários bem comuns

Situação 1: você terminou a feature e vai abrir o PR

Aqui o escopo é o teu diff, e só ele

Roda /ponytail-review, lê os achados linha a linha e decide o que apagar antes de alguém revisar

Depois disso, revisão normal por cima, porque bug e segurança não são o escopo dessa skill

Situação 2: você herdou um projeto inchado

Entrou num código que ninguém poda há dois anos, com wrapper que só delega e interface com uma implementação só

O diff aqui não te ajuda em nada, você quer o mapa do território

Roda /ponytail-audit e usa a lista ranqueada (com o total de linhas e dependências cortáveis) como plano de faxina

Situação 3: chegou a hora de pagar a dívida

Você vem usando o modo full, o agente vem te avisando das dívidas e você vem marcando com ponytail: <teto>, <caminho de upgrade>

Um dia o tráfego cresce, ou o requisito muda

Roda /ponytail-debt e o registro te diz exatamente quais soluções simples chegaram no teto e qual é o caminho de upgrade de cada uma

Bem melhor que caçar TODO espalhado, né? 😀

Dá pra resumir o mapa numa tabelinha:

O que os números do Ponytail dizem (e o que não dizem)

Antes de rodar o /ponytail-gain e se empolgar, vale entender de onde vem aquele placar

O número atual do README é de 54% menos código, com custo e tempo menores

Medido contra o mesmo agente sem a skill, deu ~54% menos linhas alteradas, 22% menos tokens, 20% mais barato e 27% mais rápido

A metodologia: média de 12 tarefas de feature com Haiku 4.5, quatro execuções por braço, em um repositório real FastAPI + React

Agora a parte honesta: o ganho varia MUITO conforme a tarefa

Ele chega a 94% onde o agente tende a superconstruir, e os dois exemplos são ótimos: o date picker caiu de 404 para 23 linhas, e o color picker de 287 para 23, porque a skill simplesmente usa o input nativo

E fica perto de zero onde o código já é mínimo

Faz sentido, né? Não dá pra cortar gordura de código que não tem gordura

Tem outro detalhe que eu acho que conta muito a favor do projeto: o benchmark original foi CORRIGIDO depois de contestação da comunidade

A manchete inicial falava em 80% a 94% menos código, e vinha de uma linha de base falha

Um contribuidor apontou o problema, o mantenedor refez o benchmark como execução agêntica real, pontuando o código efetivamente commitado, e publicou o número menor: 54%

Publicar um número menor que o próprio hype é raro, e é sinal de projeto sério

Sobre tamanho: o Ponytail é um repositório de arquivos de instrução, não de código, e cresceu rápido pra caramba, passou de 44.000 estrelas em nove dias

E segue em manutenção ativa em agosto de 2026, com issues abertas entre 15 e 20 de agosto e pull requests recentes mergeados, incluindo um adapter de tier de plugin para o Cursor em 16/08/2026

Conclusão

A régua de escolha dos comandos do Ponytail cabe numa linha: diff é /ponytail-review, repositório inteiro é /ponytail-audit, dívida marcada é /ponytail-debt, placar do benchmark é /ponytail-gain, consulta rápida é /ponytail-help

E /ponytail não é comando de uma passada, é o modo que fica ligado enquanto você escreve

O próximo passo é bem simples: instala pelo /plugin, roda /ponytail-help pra ver o cartão inteiro na tua frente, e começa por um /ponytail-review no diff que você já tem aberto aí

Aposto que tem abstração especulativa esperando pra ser apagada 😀

Até o próximo post!