ponytail: el mismo trabajo con la mitad de código

Qué es y por qué importa

Le pides a Claude un calendario para elegir una fecha, y lo construye desde cero: 335 líneas que leer y arreglar cuando se rompen. Y eso que tu proyecto ya tenía su campo de texto, y cada navegador ya trae un calendario. Bastaban diez líneas.

ponytail mete en tu Claude a un programador senior perezoso, en el buen sentido. Antes de escribir, lee el código que toca el cambio y busca lo que ya existe: en el proyecto, en el navegador o el lenguaje, en las librerías que tienes instaladas. Luego escribe solo lo que falta. Pero los controles no los recorta, y donde hay dinero o seguridad deja un pequeño test.

Es un prompt (una skill, es decir, un archivo de instrucciones para Claude) más un plugin que lo carga en cada sesión. Gratis, licencia MIT, más de 180.000 estrellas en GitHub a finales de octubre. Su autor lo midió en 39 tareas: de media un 53% menos de líneas y un 26% menos de coste. Cómo leerlos: paso 6. Es para quien construye solo con Claude Code y no quiere releer código inútil.

1. Instálalo en Claude Code

Abre Claude Code y manda estas dos líneas como dos mensajes separados: en uno solo, dice la guía de instalación, no funciona.

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

La primera añade el marketplace, el catálogo del que Claude Code saca el plugin. La segunda abre la ficha del plugin: lee qué instala y elige «Install for you», así vale en todos tus proyectos. En la app de escritorio, pestaña Code, escribe las mismas líneas en el campo del prompt.

Para comprobar que está activo:

1. En /plugin, pestaña Installed, está ponytail.
2. Al empezar cada sesión, ponytail muestra el nivel activo.
3. /ponytail solo te dice el nivel; si estaba apagado, lo enciende.

Otros agentes: copia el archivo AGENTS.md del repo en tu proyecto (reglas siempre activas, sin comandos) o sigue INSTALL.md.

2. Cómo razona: la escalera antes de escribir

El corazón de ponytail es una escalera. Lee la tarea y el código que toca, y se detiene en el primer peldaño que lo resuelve todo:

1. ¿Hace falta de verdad? Lo que nadie ha pedido se lo salta, y te lo dice en una línea.
2. ¿Ya está en el proyecto? Un componente o una función que usas en otro sitio: usa eso.
3. ¿Lo hacen el lenguaje o el navegador? Usa eso, pero un componente del proyecto va antes.
4. ¿Lo hace una librería ya instalada? Nunca una librería nueva por unas pocas líneas.
5. ¿Basta una línea clara? Una línea.
6. Solo entonces el mínimo código que funciona, con un pequeño test si hay lógica.

El calendario viene de su benchmark, con la petición «añade un selector de fechas». Sin ponytail, 335 líneas. Con ponytail, 10, que reutilizan el componente Input del proyecto con type="date": el calendario lo pone el navegador. Te soy sincero: es el caso más extremo de las 39 tareas. En muchas tareas pequeñas la diferencia es poca o ninguna.

Para verlo trabajar, pídeselo así (cambia las partes entre [ ]):

Añade [un selector de fechas] a [el formulario de reserva]. Antes de escribir, dime qué hay ya en el proyecto, en el navegador o en las librerías instaladas que haga este trabajo, y en qué peldaño te has detenido.

3. Los tres niveles de intensidad, y off

Arranca solo, en el nivel full. Lo cambias con /ponytail y el nivel, hasta que acaba la sesión.

• lite: hace lo que has pedido y en una línea te propone la versión más pequeña. Lo uso cuando la petición ya está decidida.
• full: la escalera del paso 2, con el test donde hace falta. Es el que mantengo casi siempre.
• ultra: además pone en duda la petición y, antes de construir, te dice qué no justifica la necesidad. Lo uso al empezar un proyecto.
• off: lo apaga. También basta un mensaje con solo «stop ponytail».

/ponytail ultra

Para cambiar el nivel de partida de todas las sesiones, escríbelo en ~/.config/ponytail/config.json (en Windows en %APPDATA%\ponytail):

{ "defaultMode": "lite" }

O está la variable de entorno PONYTAIL_DEFAULT_MODE, que gana sobre el archivo. Con "off" no arranca solo: lo enciendes tú con /ponytail.

4. Los dos comandos de revisión

Los dos escriben un informe y no tocan el código. Cada problema va numerado y dice qué hace ese código, qué sale mal, cómo se arregla y qué pasa si lo dejas. El informe suele estar en un inglés sencillo.

/ponytail-review: el cambio que acabas de hacer

Solo, mira los cambios que aún no están en un commit, o el último commit si no hay ninguno. Lee también el código que los usa, porque un cambio puede romper un archivo que no has tocado. Para elegir qué mira, añade una palabra: uncommitted, staged (listos para el commit), branch o el enlace de una PR.

/ponytail-review branch

Luego responde con los números:

Arregla la 1 y la 3 con la corrección más pequeña que has propuesto. Las demás déjalas.

/ponytail-audit: todo el proyecto, por orden

Los mismos controles, en todo el repo o en la carpeta que le nombres. Primero hace el mapa: por dónde entran los datos, dónde acaban, cuánta carga tiene que aguantar. Luego ordena como máximo 20 problemas, del más grave al menos, y te dice por cuál empezar. Yo lo lanzo en un proyecto que no abro desde hace meses.

/ponytail-audit

Si en el menú de Claude Code ves los comandos con el nombre del plugin delante, tipo /ponytail:ponytail-review, usa esa forma.

5. Los atajos marcados y la franja sobre el prompt

Cuando elige un atajo con un límite conocido, ponytail lo escribe en el código con un comentario shortcut: seguido del límite y de cuándo cambiarlo. Por ejemplo una lista en memoria que aguanta mientras los usuarios sean pocos. Son decisiones, no errores, pero hay que releerlas: /ponytail-debt las reúne en un registro y señala las que no dicen cuándo revisarlas.

/ponytail-debt

Escribe este registro en PONYTAIL-DEBT.md.

Con un Claude Code reciente, en la terminal y en la app de escritorio, hay una franja sobre el prompt: cuánto consume la tarea, el tiempo del agente, cuánto código ha reutilizado, si los tests han pasado. /ponytail band la oculta y la vuelve a mostrar.

6. Los números, leídos con honestidad

Son números de su propio autor: 39 tareas, Claude Code con Opus, 5 pruebas por tarea. El método y los scripts están en el repo.

• Líneas de código: un 53% menos de media (entre el 41% y el 63%).
• Coste: un 26% menos a precio de tarifa (entre el 16% y el 36%). Con una suscripción no pagas menos: consumes menos de tu límite.
• Un test donde la lógica lo pide: el 98% de las veces, frente al 68% sin ponytail.
• Corrección, en las 18 tareas con controles ocultos: empate. Menos código no ha quitado seguridad, pero tampoco ha añadido.

En el benchmark el agente no podía lanzar comandos: mide lo que escribe, no cómo trabaja en tu proyecto. Y ponytail sigue siendo un prompt: Claude puede equivocarse igual, y los atajos los relees tú.

Errores comunes

• Mandar las dos líneas de instalación en un solo mensaje.
• Instalarlo desde una copia: el original es solo DietrichGebert/ponytail en GitHub (o @dietrichgebert/ponytail en npm) y nunca contiene archivos .exe o .dll.
• No tener Node.js: las instrucciones funcionan, pero en cada mensaje aparece el error «node: command not found».
• Dejar los comentarios shortcut: sin leer: el límite que indican llega tarde o temprano.

Lista de comprobación

• He mandado las dos líneas de instalación como dos mensajes separados
• Escribiendo /ponytail veo el nivel activo
• He probado /ponytail-review en un cambio mío real
• He leído los atajos con /ponytail-debt

Preguntas frecuentes