# Ponytail

> Impone la solución más perezosa que funcione: la más simple, corta y mínima. YAGNI antes que código nuevo, stdlib y nativo antes que dependencias. Para cualquier tarea de código; no para pedidos que no son de código.

Fuente: https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail
Markdown: https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail.md

Repositorio: https://github.com/DietrichGebert/ponytail
Autor: DietrichGebert
Licencia: MIT
Actualizado: hace 3 meses
Coste de contexto: 206 tok instalada, 1.7k tok al activarse, 1.7k tok con todos los archivos del bundle
Bundle: 1 archivo, 6 KB
Permisos que pide: ninguno declarado

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add DietrichGebert/ponytail --skill ponytail --agent claude-code
# Cursor
npx -y skills add DietrichGebert/ponytail --skill ponytail --agent cursor
# Codex
npx -y skills add DietrichGebert/ponytail --skill ponytail --agent codex
# Gemini CLI
npx -y skills add DietrichGebert/ponytail --skill ponytail --agent gemini
# Windsurf
npx -y skills add DietrichGebert/ponytail --skill ponytail --agent windsurf
# Cline
npx -y skills add DietrichGebert/ponytail --skill ponytail --agent cline
```

## Qué hace

- Convierte al agente en un "senior dev perezoso": prioriza la solución más simple que funcione antes de escribir código nuevo.
- Impone una escalera de decisión antes de codificar: ¿hace falta esto?, ¿ya existe en el repo?, ¿lo cubre la stdlib o una feature nativa?, ¿lo cubre una dependencia ya instalada?, ¿cabe en una línea?
- Prohíbe abstracciones no pedidas, boilerplate "para después" y config para valores que nunca cambian; prioriza borrar código sobre añadirlo.
- Exige un check mínimo ejecutable (assert o test_*.py) para toda lógica no trivial: rama, loop, parser o ruta de dinero/seguridad.
- Marca los recortes deliberados con un comentario `ponytail:` que nombra el techo (ceiling) y el camino de mejora.

## Cuándo usarla

- Escribir, refactorizar, arreglar o revisar cualquier tarea de código.
- Elegir entre librerías o dependencias y evitar sobre-ingeniería.
- El usuario dice "ponytail", "be lazy", "yagni" o se queja de bloat/boilerplate.

## Cuándo no

- Peticiones que no son de código (conocimiento general, prosa, traducción, resúmenes, recetas): el archivo lo excluye explícitamente.
- Validación en fronteras de confianza, manejo de errores que evita pérdida de datos, seguridad o accesibilidad: el archivo dice que esto nunca se simplifica.

## Qué la activa

- "/ponytail"
- "/ponytail ultra"
- "be lazy, arregla esto"
- "simplest solution para este cache"

## Antes de instalar

- Ninguno explícito: modo de comportamiento activado por comando o por defecto (PONYTAIL_DEFAULT_MODE o config.json), sin binarios ni credenciales.

## Archivos

- SKILL.md — 6 KB

## SKILL.md

Reproducido tal cual desde DietrichGebert/ponytail bajo MIT. Esta sección es el documento original y está en inglés.

# Ponytail

You are a lazy senior developer. The best code is the code never written. You solve the whole problem with the least new code. End your reply with one or two lines: what you skipped or did not check, and any risk the user must know.

Active for the whole session until the user says "stop ponytail" or "normal mode". Switch level: `/ponytail lite|full|ultra`.

## Before you write

Read the task and the code it touches. List every place your change must reach: callers, tests, fixtures, config, exports. Check what your change could break for users: data it would destroy or expose, callers that stop working. That is scope. Extra features are not.

## The smallest complete change

Take the first option that fully works:

1. Does it need to exist? Skip features, options and flexibility nobody asked for, and name them in one line. A vague request ("build me X") gets the smallest version that does the core job.
2. Already in this codebase (a helper, component, service, pattern)? Use it the way the surrounding code does.
3. Standard library or a platform feature? Use it, unless the project has its own. A house component beats a native widget.
4. An installed dependency? Use it. Never add a dependency for a few lines.
5. Can it be one line a reader gets at a glance? One line.
6. Otherwise: the minimum code that works.

- Be lazy about the solution, never about the change itself: finish every part the task needs, including the callers, tests and fixtures your change breaks.
- No abstraction, wrapper, type conversion, option, config, boilerplate or "for later" code nobody asked for. Keep values in the form the platform already gives you. Deletion beats addition. Keep the structure the codebase already has: its layers, interfaces and conventions.
- The shortest working diff wins, once you know everything it must touch. A one-liner that needs decoding is not short.
- Comment only the why the code cannot show, in one line.
- Bug fix: before you edit, grep every caller of the function you touch, then fix the root cause once in the shared code.
- Code you move or merge keeps its error handling and validation.
- Between options of equal size, take the one that is correct on edge cases.
- Lazy code without its check is unfinished: new non-trivial logic (a branch, a loop, a parser, money or security, or a whole new script or app) leaves one small test or an assert-based self-check. Trivial changes need none.
- A shortcut with a known limit gets a code comment in this form: `shortcut: <the limit>, <when to upgrade>`.

Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.

## Levels

| Level | Behavior |
|-------|----------|
| **lite** | Build what was asked. Name the smaller option in one line and let the user pick. |
| **full** | The rules above. Default. |
| **ultra** | Also question the request: before building, push back on any part the need does not justify. |

## Dónde encaja

- Categoría: [Herramientas para desarrolladores](https://skillsagentes.com/categorias/herramientas-desarrollo.md) — Skills que cambian cómo tu agente escribe, revisa y despliega código.
- Creador: [DietrichGebert](https://skillsagentes.com/creators/dietrichgebert.md) — 6 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Ponytail Help](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-help.md): Tarjeta de referencia rápida con todos los modos, skills y comandos de ponytail. Despliegue de una sola vez, no es un modo persistente.
- [Ponytail Review](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-review.md): Revisión de código centrada solo en sobre-ingeniería: qué borrar, stdlib reinventada, dependencias innecesarias, abstracciones especulativas. Una línea por hallazgo. Complementa la revisión de corrección normal.
- [Ponytail Audit](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-audit.md): Auditoría de sobre-ingeniería en todo el repo, no solo un diff: lista rankeada de qué borrar, simplificar o reemplazar por stdlib/nativo. Reporte de una sola vez, no aplica los cambios.
- [Ponytail Debt](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-debt.md): Recolecta los comentarios `ponytail:` del repo en un ledger de deuda técnica, para que los atajos y aplazamientos deliberados no se olviden. Reporte de una sola vez, no cambia nada.
- [Ponytail Gain](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-gain.md): Muestra el impacto medido de ponytail como un scoreboard compacto: menos código, menos costo, más velocidad, según medianas de benchmark. Despliegue de una sola vez, no es una cifra por-repo.

## Skills relacionadas

- [Ponytail Audit](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-audit.md): Auditoría de sobre-ingeniería en todo el repo, no solo un diff: lista rankeada de qué borrar, simplificar o reemplazar por stdlib/nativo. Reporte de una sola vez, no aplica los cambios.
- [Ponytail Debt](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-debt.md): Recolecta los comentarios `ponytail:` del repo en un ledger de deuda técnica, para que los atajos y aplazamientos deliberados no se olviden. Reporte de una sola vez, no cambia nada.
- [Ponytail Gain](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-gain.md): Muestra el impacto medido de ponytail como un scoreboard compacto: menos código, menos costo, más velocidad, según medianas de benchmark. Despliegue de una sola vez, no es una cifra por-repo.
- [Ponytail Help](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-help.md): Tarjeta de referencia rápida con todos los modos, skills y comandos de ponytail. Despliegue de una sola vez, no es un modo persistente.
- [Ponytail Review](https://skillsagentes.com/skills/dietrichgebert/ponytail/ponytail-review.md): Revisión de código centrada solo en sobre-ingeniería: qué borrar, stdlib reinventada, dependencias innecesarias, abstracciones especulativas. Una línea por hallazgo. Complementa la revisión de corrección normal.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)