GitHub: 97 mil estrellas. Un plugin para Claude Code, Codex, Cursor, Windsurf, OpenCode, Gemini, Devin, Qoder, Hermes, Pi, Swival y como ocho más. Y yo, en vez de instalarlo — leí lo que hace y actualicé un solo archivo. Obtuve el 90% del valor sin una sola dependencia nueva.
Ponytail — un senior dev perezoso como plugin
Ponytail es un conjunto de reglas que hace que un agente de IA piense como el desarrollador senior más perezoso de la oficina. “No dice nada. Escribe una línea. Funciona.” Los benchmarks muestran en promedio un 54% menos de código con 100% de seguridad — medido en sesiones reales de Claude Code.
Su núcleo es una escalera de decisión — siete peldaños que el agente revisa antes de escribir nada:
- ¿Esto tiene que existir? (YAGNI)
- ¿Ya está en el codebase?
- ¿La stdlib lo hace?
- ¿Funcionalidad nativa de la plataforma?
- ¿Dependencia ya instalada?
- ¿Se puede en una línea?
- Solo entonces: el código mínimo que funciona.
Además: disciplina de output (código primero, máximo tres líneas de comentario), un marcador # ponytail: para documentar simplificaciones deliberadas con su límite conocido, y una regla de bugfixes: haz grep a cada caller, arregla la causa raíz, no el síntoma.
¿Plugin? No. Actualización de skill.
Hermes soporta plugins — podría haber ejecutado hermes plugins install DietrichGebert/ponytail --enable y reiniciar. ¿Pero para qué?
Hermes me preguntó si instalarlo. Le dije que en su lugar actualizara nuestro skill existente coding-minimalism, que ya se inyecta en cada sesión. Ya tenía 8 principios ahí, basados en la experiencia del equipo de Vercel Next.js, pero lo que faltaba era precisamente esta cualidad procedural — una escalera, pasos concretos en vez de principios abstractos.
El resultado: un archivo SKILL.md en ~/.hermes/skills/software-development/coding-minimalism/ recibió nuevas secciones — la escalera, disciplina de output, el marcador ponytail:, la disciplina de bugfixes y auto-testing.
Por qué esto es mejor que instalar
Sin redundancia. Si hubiera instalado el plugin, tendría dos conjuntos de reglas inyectados antes de cada turno del LLM — nuestros 8 principios existentes Y las reglas de ponytail. Se solapan ~60%, así que es mayormente ruido y tokens desperdiciados.
Cero dependencias nuevas. El plugin de ponytail requiere Node.js en el PATH, hooks de ciclo de vida, integración MCP. Nuestro skill es un archivo Markdown.
Nuestra propia voz. Las reglas de ponytail están en inglés, con ejemplos ajustados al ecosistema Node.js/frontend. Nuestra versión está en polaco, con nuestras propias trampas (¡la excepción de seguridad de datos!), contexto de MusicStudio y los detalles de los proyectos de Darek.
Selectividad. No todo en ponytail nos sirve. Sus niveles de intensidad (lite/full/ultra) y comandos (/ponytail-review, /ponytail-audit) son complejidad extra que no necesitamos, porque Hermes ya tiene su propio sistema de comandos. Tomamos lo valioso, saltamos el resto.
Segunda vez
No es la primera vez que importamos buenas prácticas en vez de instalar. Nuestros 8 principios originales de minimalismo vienen de la experiencia del equipo de Vercel Next.js (60 mil millones de tokens analizados — su conclusión principal: el mayor desperdicio no son los bugs, es el over-engineering). No instalé Vercel. Lo leí, lo entendí, lo adapté.
El patrón: leer → extraer → adaptar
El valor real de un proyecto open-source muchas veces no está en npm install — está en el modelo mental que hay detrás. Un plugin es solo empaquetado. Las reglas son la esencia.
La próxima vez que veas un repo popular en GitHub — antes de escribir install, abre SKILL.md o AGENTS.md. Lee la escalera de decisión. Pregúntate qué 20% de las reglas entrega el 80% del valor en tu contexto. Luego actualiza tu propio conjunto de reglas — sin dependencias nuevas, sin conflictos, sin tokens desperdiciados en redundancia.
O simplemente pregúntale a tu agente. El mío lo resolvió en 5 minutos.