- Un proyecto open source creado por Addy Osmani, director de AI en Google Cloud, que empaqueta flujos de trabajo de nivel ingeniero senior como habilidades estructuradas para resolver el problema de que los agentes de codificación con IA se salten la especificación, las pruebas y la revisión de seguridad
- Está compuesto por 7 comandos slash y 19 habilidades que cubren todo el ciclo de vida de desarrollo (definición → planificación → construcción → verificación → revisión → despliegue)
/spec define qué se va a construir: "especificación antes que código"/plan planifica cómo implementarlo: "en tareas atómicas pequeñas"/build implementación incremental: "solo una porción a la vez"/test demuestra que funciona: "las pruebas son evidencia"/review puerta de calidad antes del merge: "mejorar la salud del código"/code-simplify simplificación del código: "claridad antes que ingenio"/ship despliegue a producción: "cuanto más rápido, más seguro"
- La habilidad adecuada se activa automáticamente según el contexto. Ej.) al diseñar una API se usa
api-and-interface-design, y al implementar UI se usa frontend-ui-engineering
- Los principios clave de la cultura de ingeniería de Google (Hyrum's Law, Beyonce Rule, Chesterton's Fence, Shift Left, etc.) están integrados directamente en los flujos de trabajo por etapa
Lista completa de las 19 habilidades
-
Define (aclarar qué se va a construir)
- idea-refine: estructura el pensamiento divergente/convergente para convertir una idea vaga en una propuesta concreta
- spec-driven-development: redacta un PRD antes de escribir código, cubriendo objetivos, comandos, estructura, estilo de código, pruebas y límites
-
Plan (descomposición)
- planning-and-task-breakdown: divide la especificación en tareas pequeñas y verificables con criterios de aceptación y orden de dependencias
-
Build (escritura de código)
- incremental-implementation: implementa, prueba, valida y hace commit con un enfoque de slices verticales delgados, con soporte para feature flags y cambios amigables con rollback
- test-driven-development: aplica Red-Green-Refactor, la pirámide de pruebas (80/15/5), DAMP sobre DRY y la Beyonce Rule
- context-engineering: entrega al agente la información correcta en el momento adecuado (archivos de reglas, empaquetado de contexto, integración con MCP)
- frontend-ui-engineering: arquitectura de componentes, sistema de diseño, gestión de estado, diseño responsivo y accesibilidad WCAG 2.1 AA
- api-and-interface-design: diseño contract-first, Hyrum's Law, One-Version Rule, semántica de errores y validación en los límites
-
Verify (demostrar funcionamiento)
- browser-testing-with-devtools: datos de runtime en tiempo real mediante Chrome DevTools MCP (inspección del DOM, logs de consola, trazas de red, profiling de rendimiento)
- debugging-and-error-recovery: triaje en 5 pasos (reproducir → localizar → reducir → corregir → blindar), regla de stop-the-line
-
Review (puerta de calidad antes de fusionar)
- code-review-and-quality: revisión en 5 ejes, tamaño de cambio (~100 líneas), etiquetas de severidad (Nit/Optional/FYI), criterios de velocidad de revisión
- code-simplification: Chesterton's Fence, Rule of 500, reducción de complejidad manteniendo el comportamiento exacto
- security-and-hardening: prevención del OWASP Top 10, patrones de autenticación, gestión de secretos, auditoría de dependencias y sistema de límites de 3 capas
- performance-optimization: enfoque de medir primero, metas de Core Web Vitals, flujo de trabajo de profiling y análisis de bundles
-
Ship (despliegue)
- git-workflow-and-versioning: desarrollo trunk-based, commits atómicos, tamaño de cambio (~100 líneas), patrón de commit como savepoint
- ci-cd-and-automation: Shift Left, Faster is Safer, feature flags y pipeline de puertas de calidad
- deprecation-and-migration: mentalidad de código-como-deuda, métodos de deprecación obligatoria/recomendada y eliminación de código zombi
- documentation-and-adrs: Architecture Decision Records, documentación de API y estándares de documentación inline (documentar el "por qué")
- shipping-and-launch: checklist previo al lanzamiento, ciclo de vida de feature flags, rollout gradual, procedimientos de rollback y configuración de monitoreo
Personas del agente
- Se preconfiguran 3 personas expertas para revisiones enfocadas
- code-reviewer: perspectiva de ingeniero senior staff, con una revisión en 5 ejes basada en el criterio de "¿lo aprobaría un staff engineer?"
- test-engineer: perspectiva de especialista en QA, análisis de estrategia de pruebas, cobertura y patrón Prove-It
- security-auditor: perspectiva de ingeniero de seguridad, detección de vulnerabilidades, modelado de amenazas y evaluación OWASP
Checklist de referencia
- 4 materiales de referencia rápida que las habilidades consultan cuando hace falta
- testing-patterns.md: estructura de pruebas, nombres, mocking, ejemplos de React/API/E2E y antipatrones
- security-checklist.md: chequeos antes del commit, autenticación, validación de entradas, headers, CORS y OWASP Top 10
- performance-checklist.md: metas de Core Web Vitals, checklist de frontend/backend y comandos de medición
- accessibility-checklist.md: navegación por teclado, lector de pantalla, diseño visual, ARIA y herramientas de prueba
Principios de diseño de las habilidades
- Proceso, no prosa: las habilidades son flujos de trabajo que el agente sigue, con pasos, checkpoints y criterios de salida; no son documentos de referencia
- Evitar racionalizaciones: todas las habilidades incluyen excusas comunes que usa el agente para saltarse pasos ("agregaré las pruebas después") y la lógica para refutarlas
- La verificación no es negociable: todas las habilidades terminan con requisitos de evidencia (pruebas aprobadas, salida de build, datos de runtime), y "parece que funciona" no es suficiente
- Divulgación progresiva:
SKILL.md es el punto de entrada, y las referencias de apoyo se cargan solo cuando hacen falta para minimizar el uso de tokens
Cómo instalarlo (herramientas compatibles)
- Claude Code (recomendado):
/plugin marketplace add addyosmani/agent-skills y luego /plugin install agent-skills@addy-agent-skills
- Desarrollo local: después de
git clone, usar claude --plugin-dir /path/to/agent-skills
- Cursor: copiar cualquier
SKILL.md a .cursor/rules/ o referenciar todo el directorio skills/
- Gemini CLI:
gemini skills install https://github.com/addyosmani/agent-skills.git
- Windsurf: agregar el contenido de las habilidades a la configuración de reglas de Windsurf
- GitHub Copilot: usar las definiciones de agente de
agents/ como personas de Copilot, y el contenido de las habilidades en .github/copilot-instructions.md
- Codex y otros agentes: como las habilidades son Markdown genérico, son compatibles con cualquier agente que soporte prompts de sistema o archivos de instrucciones
7 comentarios
Parece que últimamente se puso de moda publicar tus propios conjuntos de skills.
Como al final son archivos Markdown, no hace falta adoptarlos todos tal cual.
Mientras más tengas, más va a aumentar el consumo de tokens.
Es mejor decirle a tu agente: "analiza esto y tomemos solo lo necesario".
Así es como vas construyendo tu propio harness.
Sí. Creo que es la mejor manera de responder al torrente de proyectos open source que están saliendo.
Parece algo como speckit.
Nos dieron la instrucción interna de desarrollar usando solo vibe coding, así que probé aplicar varias cosas, pero al hacerlo me di cuenta de que tener excelentes habilidades de desarrollo no garantiza necesariamente una alta calidad..
Más bien, parece que la clave está en la capacidad de revisar y entender el código que genera la IA. Supongo que es una ironía que, mientras mejores se vuelven las herramientas, más importante se vuelve esa “capacidad de leer y juzgar”.
Addy Osmani, líder del equipo de Google Chrome, cambió de puesto a Director en Google Cloud AI.
Vaya, ¿cuándo lo movieron? Yo seguía pensando que estaba así. Ya lo corregí.
Yo también ya solo conozco a una persona en el equipo de Chrome: Paul Kinlan (líder de DevRel de Chrome). Cómo pasa el tiempo.