Por Devy — yoDEV.dev
Tu agente de IA no escribe tests. No crea specs. No revisa su propio código. No porque no sepa — sino porque nadie le dijo que tenía que hacerlo.
Ese es el problema que Addy Osmani —engineering lead de Google Chrome— decidió resolver. El resultado se llama agent-skills, un framework open source que ya tiene 33K estrellas en GitHub y que está cambiando cómo los equipos trabajan con agentes de IA en producción.
El problema: los agentes toman el camino corto
Cuando le pedís a un agente de IA que implemente una feature, hace exactamente eso: implementa la feature. No te pregunta si tenés un spec. No escribe el test antes del código. No evalúa si el cambio cruza un límite de seguridad. No considera qué tan legible va a ser el PR para tu equipo.
Toma el camino más corto hacia “listo” y declara victoria.
Esto no es un bug del modelo — es un problema de ausencia de proceso. Un ingeniero senior no solo escribe el código: surfea supuestos, rompe el trabajo en chunks revisables, elige la solución aburrida sobre la ingeniosa, y deja evidencia de que el resultado es correcto. Esos pasos no aparecen en el diff, pero son la diferencia entre software confiable y software que rompe en producción.
agent-skills le mete ese andamiaje al agente de manera explícita.
Qué es una “skill”
Una skill es un archivo Markdown con frontmatter que se inyecta en el contexto del agente cuando la situación lo requiere. Pero atención a la distinción clave que hace Osmani: una skill no es documentación de referencia. Es un workflow.
No es “todo lo que deberías saber sobre testing.” Es una secuencia de pasos que el agente sigue, con checkpoints que producen evidencia y criterios de salida definidos. La diferencia importa: si le metés un ensayo de 2.000 palabras sobre buenas prácticas al contexto, el agente genera texto plausible y salta el testing. Si le metés un workflow (escribí el test que falla, correlo, mirá cómo falla, escribí el mínimo código para que pase, refactorizá), el agente tiene algo concreto que ejecutar — y vos tenés algo concreto que verificar.
Proceso sobre prosa. Workflows sobre referencia. Pasos con criterios de salida sobre ensayos sin ellos.
Las 21 skills del pack
El repositorio incluye 21 skills organizadas alrededor de seis fases del ciclo de desarrollo, con siete slash commands como puntos de entrada:
| Fase | Comando | Qué hace |
|---|---|---|
| Definir | /spec |
Crea un SPEC.md antes de tocar una línea de código |
| Planificar | /plan |
Descompone el trabajo en tareas atómicas |
| Construir | /build |
Implementa en vertical slices con feature flags |
| Verificar | /test |
TDD estricto: Red → Green → Refactor |
| Revisar | /review |
Code review de cinco ejes con etiquetas de severidad |
| Shipper | /ship |
Deploy seguro con checklist de launch |
Además, /code-simplify atraviesa todo el ciclo para limpiar el código generado por IA antes de que llegue a un PR.
Las skills se activan automáticamente según el contexto: si estás diseñando una API, se activa api-and-interface-design. Si estás construyendo UI, se activa frontend-ui-engineering. No necesitás invocarlas manualmente.
Las cinco ideas centrales que vale la pena robar
1. Proceso sobre prosa
Ya lo mencionamos, pero es la idea más importante del proyecto. Si tu equipo tiene un handbook de 200 páginas, nadie lo lee bajo presión de tiempo. Un conjunto pequeño de workflows con checkpoints, sí.
2. Tablas de anti-racionalización
Esta es la decisión de diseño más original del repo. Cada skill incluye una tabla con las excusas comunes que un agente (o un engineer cansado) usa para saltarse el workflow, junto con un rebatidor escrito. Por ejemplo:
- “Esta tarea es demasiado simple para necesitar un spec.” → Los criterios de aceptación aplican igual. Cinco líneas está bien. Cero líneas, no.
- “Voy a escribir los tests después.” → “Después” es la palabra clave. No existe el después. Escribí el test que falla primero.
- “Los tests pasan, shipeemos.” → Los tests que pasan son evidencia, no prueba. ¿Revisaste el runtime? ¿Un humano leyó el diff?
Los LLMs son excelentes racionalizando. Estas tablas son rebatidores pre-escritos a mentiras que el agente todavía no contó.
3. La verificación es no-negociable
Cada skill termina con evidencia concreta: tests que pasan, build limpio, un reviewer que da el OK. “Parece correcto” nunca es suficiente. Sin evidencia, la tarea no está terminada.
4. Progressive disclosure
No cargues las 21 skills al contexto al inicio de la sesión. Una meta-skill (using-agent-skills) actúa como router y decide qué skill aplica a la tarea actual. Así podés tener una biblioteca de 21 skills en un slot de 5K tokens sin saturar el contexto.
5. Scope discipline
El meta-skill tiene una regla no-negociable: tocá solo lo que te pidieron. No refactorices sistemas adyacentes. No eliminés código que no entendés del todo. No empieces a reescribir un archivo porque encontraste un TODO.
Esto parece obvio hasta que mirás a un agente decidir que arreglar un bug requiere modernizar tres archivos no relacionados. El scope discipline es el factor más determinante de si el PR de un agente es mergeable o hay que deshacerlo.
El ADN de Google Engineering
Las skills están saturadas de prácticas de Software Engineering at Google y la cultura de ingeniería pública de Google. Algunas referencias concretas:
- Ley de Hyrum en
api-and-interface-design— todo comportamiento observable de tu API va a ser dependido eventualmente - La Regla Beyoncé y la pirámide de tests (80/15/5) en
test-driven-development— si te gustó, poné un test - DAMP sobre DRY en tests — los tests de Google son explícitamente más legibles que DRY
- PRs de ~100 líneas con etiquetas Critical/Nit/Optional/FYI en
code-review-and-quality - La Cerca de Chesterton en
code-simplification— no eliminés algo hasta entender por qué está ahí - Trunk-based development y commits atómicos en
git-workflow-and-versioning
Ninguna de estas es una idea nueva. El punto es que ninguna viene activada por defecto en el agente.
Cómo instalarlo en Claude Code
La forma más directa si usás Claude Code:
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
Con eso tenés los slash commands (/spec, /plan, /build, /test, /review, /ship, /code-simplify) y las skills se activan automáticamente según el contexto.
Para Cursor: copiá el contenido de cualquier SKILL.md en .cursor/rules/.
Para Windsurf: el repositorio incluye integración con el Rules Engine de Windsurf — hay una PR activa (#134) que moderniza esa integración.
Para Gemini CLI: tiene su propio install path documentado en el README.
Sin instalar nada: cloná el repo, navegá a skills/ y copiá el contenido del SKILL.md relevante directamente en tu conversación. Las skills son Markdown plano — funcionan en cualquier herramienta que acepte un system prompt.
El modo “robá la idea sin instalar nada”
Osmani describe tres modos de uso. El tercero —y el que más recomienda para empezar— es usar las skills como especificación de qué significa codear bien con IA, sin instalar nada.
Leé code-review-and-quality.md y aplicá el framework de cinco ejes al proceso de review de tu equipo. Leé test-driven-development.md y usalo para zanjar el próximo “¿necesitamos escribir el test primero?” con un junior. Leé el meta-skill y robá estos cinco puntos para tu propio CLAUDE.md:
- Surfear supuestos antes de construir
- Parar y preguntar cuando los requerimientos se contradicen
- Pushear back cuando corresponde — el agente no es una máquina de “sí”
- Preferir la solución aburrida y obvia
- Tocar solo lo que te pidieron
Eso es una cultura de ingeniería útil en cinco líneas.
El proyecto hermano: awesome-agent-skills
La comunidad ya tomó el formato y lo extendió. El repositorio VoltAgent/awesome-agent-skills agrega más de 1.200 skills contribuidas por equipos de desarrollo de distintas herramientas y frameworks — y también está trending esta semana.
Si el pack oficial de 21 skills no cubre tu stack específico (digamos, skills para trabajar con Supabase, o para proyectos Django, o para pipelines de datos con dbt), es probable que alguien ya haya contribuido algo en ese repo.
Por qué esto importa ahora
El desafío del momento no es conseguir que el agente genere código — eso ya funciona. El desafío es conseguir que el código generado sea auditable, reproducible y mergeable sin que un senior tenga que reescribir la mitad.
agent-skills ataca exactamente ese problema. No con prompts mágicos ni con un modelo más grande, sino con lo más simple: darle al agente los mismos workflows que un ingeniero experimentado se fuerza a seguir porque aprendió de los incidentes que causa saltárselos.
33K estrellas en pocas semanas desde el lanzamiento sugieren que mucha gente estaba esperando exactamente esto.
¿Ya usás algún tipo de CLAUDE.md o rules file para guiar a tu agente? ¿Qué workflows le costó más aprender a seguir? Contanos en los comentarios.