Pocock vs pstack vs Osmani: qué pack de skills instalar (y cuándo no instalar ninguno)

Fuente: Rob Shocks (@robshocks) · YouTube · 7-oct-2026 · 12:53 · 106.955 vistas · 1.732 likes · 58,7K suscriptores · canal en inglés, con doblaje automático a otros idiomas URL canónica: https://www.youtube.com/watch?v=sU9MW8Ycq2M Capítulos del propio vídeo: Intro 0:00 · Quién es Addy Osmani 0:45 · El ciclo de seis fases 1:30 · Dentro de los skills 3:00 · Patrocinio (Neon) 4:30 · Pocock vs Addy vs pstack 5:15 · El cara a cara de los 87 $ 7:00 · No necesitas todo esto 8:00 · Construye tus propios skills 9:00 · Outro 9:45

Qué es

Rob Shocks cierra una trilogía de vídeos sobre skill packs para agentes de código y compara los tres grandes:

• addyosmani/agent-skills — Addy Osmani (ex-Google, Chrome DX y Core Web Vitals, autor de Learning JavaScript Design Patterns, hoy en Anthropic). 100.000+ estrellas en pocas semanas; el propio repositorio lleva ya 109.161 estrellas y 11.383 forks (MIT, creado el 15-feb-2026).
• mattpocock/skills — Matt Pocock (Total TypeScript). 299.360 estrellas, 25.135 forks (MIT, 3-feb-2026).
• pstack — Lauren Tan «poteto» (React core team, Meta → Netflix → Cursor), dentro de cursor/plugins (13.329 estrellas al repo contenedor).

La tesis del vídeo no es «cuál gana» sino que son tres ángulos del mismo oficio y que correr los tres en todos los proyectos es sobreingeniería. El mensaje final: los skills no enseñan nada nuevo al agente; codifican cómo trabajas tú, y ese es el activo.

El ciclo de seis fases de Osmani

Addy estructura su pack como un SDLC literal, sin metáforas: Define → Plan → Build → Verify → Review → Ship, cada fase con su comando.

Son 9 comandos slash más 25 skills (24 de ciclo de vida + using-agent-skills, el meta-skill que enruta el trabajo al flujo correcto) y 4 personas revisoras: staff engineer (code-reviewer), QA (test-engineer), seguridad (security-auditor) y rendimiento web (web-performance-auditor). Además, references/ con 7 checklists de apoyo (definition of done, testing patterns, seguridad, rendimiento, accesibilidad, observabilidad, orquestación).

Las 25 skills, por fase (verificado en el README)

• Meta: using-agent-skills.
• Define: interview-me (entrevista de una pregunta a la vez hasta ~95 % de confianza), idea-refine, spec-driven-development (PRD con objetivos, comandos, estructura, estilo, testing y límites), constraint-driven-development (escribe CONSTRAINTS.md con umbrales y detecta al agente que silencia checks para poner el build en verde).
• Plan: planning-and-task-breakdown (tareas con criterios de aceptación y orden de dependencias).
• Build: incremental-implementation (rebanadas verticales finas: implementar, testear, verificar, commit), test-driven-development (red-green-refactor, pirámide 80/15/5, DAMP sobre DRY, Beyoncé Rule), context-engineering, source-driven-development (fundamentar cada decisión de framework en documentación oficial y citarla), doubt-driven-development, frontend-ui-engineering (WCAG 2.1 AA), api-and-interface-design (contrato primero, ley de Hyrum, One-Version Rule).
• Verify: browser-testing-with-devtools (Chrome DevTools MCP: DOM, consola, red, profiling) y debugging-and-error-recovery (reproducir, localizar, reducir, arreglar, blindar).
• Review: code-review-and-quality (revisión de cinco ejes, cambios de ~100 líneas, severidades Nit/Optional/FYI), code-simplification (Chesterton's Fence, Rule of 500), security-and-hardening (OWASP Top 10, secretos, auditoría de dependencias), performance-optimization (medir primero, Core Web Vitals).
• Ship: git-workflow-and-versioning (trunk-based, commits atómicos), ci-cd-and-automation (shift left, feature flags), deprecation-and-migration (código como pasivo), documentation-and-adrs, observability-and-instrumentation (RED, OpenTelemetry, alertas por síntoma), shipping-and-launch (staged rollout, rollback, flags).

Lo que de verdad hay dentro de un skill

Rob insiste en que lo interesante no son los slash commands sino los ficheros: cada SKILL.md sigue la misma anatomía (frontmatter, overview, cuándo usarlo, proceso paso a paso, tabla de racionalizaciones, red flags y requisitos de verificación).

La pieza que más destaca del vídeo es la tabla anti-racionalización: la lista de excusas que un agente se inventa para saltarse un paso, con la réplica escrita al lado. Literalmente: «esto es demasiado simple para testear», «lo he probado a mano». Es el mismo repertorio de excusas de un junior, pero escrito antes de que ocurra, que es lo que lo hace eficaz.

/build auto y doubt-driven development

• /build auto: apruebas el plan una vez y ejecuta todas las tareas en una sola pasada autónoma. Lo que quita es el paso manual entre tareas; lo que no quita es la verificación: cada tarea sigue siendo test-driven, se commitea por separado y el proceso se detiene ante fallos o pasos arriesgados.
• doubt-driven development: para cualquier decisión no trivial se abre un contexto limpio cuyo único trabajo es dudar de la afirmación. Secuencia CLAIM → EXTRACT → DOUBT → RECONCILE → STOP. Es revisión adversarial durante la construcción, no solo al final.

Los clásicos que Addy mete dentro

Ley de Hyrum en diseño de APIs, Beyoncé Rule y pirámide de tests en TDD, Chesterton's Fence en simplificación, trunk-based development y commits atómicos en git, «el código es un pasivo» en deprecación, cambios de ~100 líneas y normas de velocidad de revisión en code review. Todo eso viene de Software Engineering at Google y de la guía de prácticas de ingeniería de Google, y está embebido en el procedimiento, no citado en un párrafo.

Los otros dos packs, en una frase cada uno

Matt Pocock — «¿estamos de acuerdo en qué estamos construyendo?» Su pack es pequeño, composable y deliberadamente anti-framework (dice que BMAD, Spec-Kit o Superpowers te quitan el control del proceso). El primitivo central es el grilling: entrevista implacable, una pregunta a la vez, recorriendo el árbol de diseño hasta resolver cada rama. De ahí salen grill-me y grill-with-docs, que además construye el modelo de dominio del proyecto, mantiene GLOSSARY.md y escribe ADRs. A eso se suman to-spec, to-tickets (tickets «tracer bullet» con sus dependencias), wayfinder (planificar trabajo que no cabe en una sesión como un mapa de tickets de decisión), implement-spec (subagentes en paralelo sobre la frontera lista) y code-review en dos ejes —estándares del repo vs. fidelidad a la especificación— con subagentes separados para que no se contaminen. Distingue explícitamente entre skills user-invoked y model-invoked para tratar el contexto como un presupuesto escaso.

pstack / Lauren Tan — «si quieres ir rápido, ve primero a fondo» No tiene skills de planificación: su línea es «la mejor spec es el código». El peso está en la investigación, la verificación y la revisión multimodal a posteriori, con la regla de que «el build ha pasado» no cuenta como evidencia. La puerta de entrada es /poteto-mode, que empareja tu petición con uno de 23 playbooks (investigación, bug fix, perf, hillclimb, forense de runtime, forense de trazas, feature, refactor, prototipo, paridad visual, eval a ciegas, babysit de PR, shipping, autonomous run, orchestrate, autopilot-full, autopilot-stack, session pickup, pausa segura, plan multifase, limpieza de worktrees, abrir PR…). Encima lleva 24 principios cortos (laziness-protocol, subtract-before-you-add, boundary-discipline, make-operations-idempotent, attack-the-premise…) y skills de paralelismo real: /arena (N intentos del mismo problema y quedarse con lo mejor de cada uno), /swarm (N workers sobre rebanadas distintas y un informe agregado), /interrogate (varios modelos intentando romper tu diff), /no-comments con el subagente Comment Sicko. Reparte además el trabajo por fortaleza de modelo: por defecto el panel es opus 5.5 / grok.

Cómo elegir (y por qué no hace falta todo)

La comparativa honesta la publica el propio repo de Addy en docs/comparison.md, y coincide con la del vídeo:

Rob lo traduce a tres situaciones:

• Problema difuso, no sabes lo que quieres, o codebase que vas a habitar años → Pocock. «grill-me es el primer skill que instalaría».
• Equipo que publica a producción y quiere un proceso predecible con puertas de calidad sin diseñarlas tú → Osmani. Es el más «empresa» y el más portable (se instala en 70+ agentes).
• Bug que no reproduces, migraciones, swarms, agentes que corren toda la noche → pstack.

Y el aviso, que es el verdadero mensaje del vídeo:

La ceremonia debe igualar lo que está en juego. Cambiar el color de un botón: hazlo y míralo. Prototipo visual: itera tú. Feature pequeña: una sesión de grilling y TDD. Feature grande o difusa: spec + plan por fases con verificación entre fases. Producción, seguridad o algo irreversible: revisión completa, doubt-driven development y endurecimiento.

Él mismo reconoce que mantiene tres perfiles de runtime —ligero, medio y pesado— y que poda: el exceso de skills infla y confunde la ventana de contexto, y algunas se auto-disparan cuando no las quieres. El propio Addy recomienda en su guía de adopción un despliegue gradual y verification-first en una base de código existente, no instalar 25 skills y lanzarlas todas.

La economía del modelo

Los números que sí están verificados (API de GitHub, consulta del 21-oct-2026):

• addyosmani/agent-skills — 109.161 estrellas, 11.383 forks, 25 skills, 4 personas, 7 checklists, 9 comandos, 25 ficheros de caso en evals/, 13 scripts. MIT; creado el 15-feb-2026, último push relevante 13-oct-2026.
• mattpocock/skills — 299.360 estrellas, 25.135 forks. MIT; creado el 3-feb-2026. Newsletter propia con ~60.000 suscriptores.
• obra/superpowers — 302.905 estrellas (el que más, y el que el vídeo usa como referencia de «metodología completa»).
• cursor/plugins (contenedor de pstack) — 13.329 estrellas, 1.319 forks.
• vercel-labs/skills (npx skills) — 35.923 estrellas. Es la vía rápida: instala en 70+ agentes con un comando.
• bmad-code-org/BMAD-METHOD — 54.406 estrellas. El «anti-modelo» que citan tanto Pocock como el vídeo.

Coste de propiedad real, que el vídeo menciona pero no cuantifica con precisión:

• Cada skill instalado es texto que el agente tiene que considerar en cada turno. pstack pesa 27 KB solo de README; el de Addy, 25,9 KB / 410 líneas. Instalar los tres packs completos es meter decenas de miles de tokens de instrucciones antes de escribir una línea.
• El modelo de negocio de los tres es el mismo y no es el repo: audiencia. Addy tiene el respaldo de Anthropic y un repo con evals en CI; Pocock vende formación en Total TypeScript y newsletter; Lauren Tan monetiza vía Cursor; y el propio autor del vídeo cobra por su curso y comunidad («Switch to Mention», lista de espera en la descripción) además del patrocinio de Neon insertado en el minuto 4:30.
• El capítulo «The $87 head-to-head» (7:00) existe en los capítulos del vídeo, pero la transcripción automática no desarrolla la cifra: no hay en el audio un desglose de ese gasto que se pueda citar. Quien quiera el número tendrá que verlo en pantalla.

Dónde está el dinero (lectura para Plataforma IA)

1. Auditoría de «puertas de calidad» para equipos que ya usan agentes. Casi ninguna pyme española con 5-30 devs usando Claude Code o Cursor tiene escritos sus criterios: ni CONSTRAINTS.md, ni ADRs, ni un definition of done, ni tests que prueben algo. Un pack de skills bien adaptado es el entregable perfecto: no es software, es proceso, se factura rápido y se renueva.
2. Instalación adaptada + formación, no «instalar el repo». El valor está en el paso 2 que casi nadie hace: rollout incremental verification-first sobre una base existente, con las convenciones del equipo dentro. Un kit propio (skills en español, con los nombres de sus módulos y su glosario) se parece sospechosamente a un activo reutilizable entre clientes del mismo vertical.
3. Mantenimiento como suscripción. Los tres repos se mueven a diario (Addy: 25 skills con evals; pstack: 23 playbooks). Un «tu pack, actualizado y auditado cada mes» es recurrente puro: comparar versión, medir auto-triggers, podar.
4. Nicho real en España: sectores donde la revisión de seguridad y la deprecación no son opcionales (sanidad, seguros, banca mediana, administración local). Ahí el pack de Osmani gana por cobertura —OWASP, deprecación, observabilidad, ADRs— y eso se vende como cumplimiento, no como productividad.
5. Formación ejecutiva de una hora con la escalera de ceremonia: es el mejor gancho comercial que hay en el vídeo, porque pone precio a la sobreingeniería sin hablar de tecnología.

Cifras de precio abajo: estimación propia, no del vídeo. Referencia de mercado para el mercado español: auditoría + pack adaptado 3.500-8.000 €, mantenimiento 400-900 €/mes, formación 1.200-2.400 €/día. Lo que las sostiene no es el repo (es gratis y MIT) sino que el cliente no va a leer 25 SKILL.md ni va a decidir qué podar.

Herramientas y links referenciados

Los tres packs

• addyosmani/agent-skills — https://github.com/addyosmani/agent-skills · skills de ingeniería de producción para agentes. Instalación rápida en 70+ agentes: npx skills add addyosmani/agent-skills (o --list para ver antes). Nativo en Claude Code: /plugin marketplace add addyosmani/agent-skills + /plugin install agent-skills@addy-agent-skills. Codex: codex plugin marketplace add addyosmani/agent-skills + codex plugin add agent-skills@agent-skills. Gemini CLI: gemini skills install https://github.com/addyosmani/agent-skills.git --path skills. Cuándo: equipo que quiere puertas de calidad y ciclo completo con checkpoints humanos.
• mattpocock/skills — https://github.com/mattpocock/skills · skills pequeñas y composables. Claude Code: claude plugin install mattpocock-skills@claude-plugins-official. Cualquier otro agente: npx skills@latest add mattpocock/skills -a <agente> (incluye setup-matt-pocock-skills, que hay que ejecutar una vez por repo). Cuándo: problema difuso, alineación previa, diseño que importa.
• pstack — https://github.com/cursor/plugins/tree/main/pstack · workflows rigurosos y paralelizables de Lauren Tan. En Cursor: /add-plugin pstack. En Claude Code: /plugin marketplace add cursor/plugins + /plugin install pstack@cursor-plugins (los comandos quedan prefijados: /pstack:poteto-mode). Cuándo: bugs difíciles, migraciones, swarms, ejecuciones nocturnas.
• Ecosistema de comparación
  • Superpowers (obra) — https://github.com/obra/superpowers · metodología completa basada en subagentes y worktrees; el término medio del que hablan los otros dos.
  • BMAD-METHOD — https://github.com/bmad-code-org/BMAD-METHOD · el framework ágil para agentes que Pocock critica explícitamente por quitar el control del proceso.
  • vercel-labs/skills — https://github.com/vercel-labs/skills · el CLI npx skills, la vía neutral para instalar cualquier pack en cualquier agente.

Documentación citada dentro de los repos

• Comparativa oficial de los tres packs: https://github.com/addyosmani/agent-skills/blob/main/docs/comparison.md
• Guía de adopción (rollout incremental verification-first): https://github.com/addyosmani/agent-skills/blob/main/docs/adoption-guide.md
• Software Engineering at Google (base de las ideas embebidas): https://abseil.io/resources/swe-book
• Guía de prácticas de ingeniería de Google: https://google.github.io/eng-practices/

Del propio vídeo (patrocinio y monetización)

• Neon — https://get.neon.com/VKIr4Dc · patrocinador. Base de datos Postgres con branching instantáneo, más storage, functions, auth y AI gateway; el argumento es que cada agente cree una rama de base de datos, funciones, buckets y usuarios para no tocar producción.
• Curso y comunidad «Switch to Mention» — https://switchdim.s.gy/yt-addy-osmani-agent-skills · lista de espera del curso del autor sobre construir tu propia biblioteca de skills.
• Rob Shocks — X: https://x.com/robshocks · LinkedIn: https://www.linkedin.com/in/robertoshaughnessy/ · Instagram: https://www.instagram.com/therobshocks/ · contacto: info@switchdimension.com

Stack de extracción usado para esta ficha: transcripción automática de YouTube (youtube-transcript-api en venv aislado; yt-dlp falla en este host con «The page needs to be reloaded» en todos los clientes probados), metadatos y URLs reales de la descripción leídos del DOM con navegador real (los enlaces salen como redirecciones de YouTube, hay que resolver el parámetro q=), y verificación de cada repositorio contra la API de GitHub.

Lo que el post no dice

• Es un vídeo con interés comercial. Patrocinio de Neon en el minuto 4:30 (con el argumento de branching de base de datos que no tiene nada que ver con la comparación de skills), curso propio con lista de espera y enlaces de afiliado. El propio autor dice que la serie tiene tres entregas: es contenido de embudo, no un benchmark.
• La comparación es cualitativa. No hay una prueba reproducible con la misma tarea en los tres packs. El capítulo «The $87 head-to-head» promete un cara a cara con cifra, pero la transcripción no lo desarrolla: el dato no es verificable desde el audio.
• Las estrellas no miden calidad. Matt Pocock (299.360) y Superpowers (302.905) superan a Osmani (109.161) por tamaño de audiencia y antigüedad, no por resultados. El propio README de Addy renuncia explícitamente a comparar estrellas.
• No hay ni una cifra de coste de tokens. Instalar los tres packs mete decenas de miles de tokens de instrucciones por sesión; las tablas anti-racionalización y los principios son útiles y también caros. El consejo de «podar» es correcto pero se queda en anécdota, sin método de medición.
• Nada sobre gobernanza. Si el equipo entero adopta un pack: ¿quién lo versiona?, ¿cómo se revisan los cambios de una skill?, ¿cómo se mide si mejora el resultado? Ninguno de los tres repos trae un proceso de cambio para equipos, y el vídeo lo ignora.
• pstack asume un presupuesto de modelos alto. Su configuración por defecto reparte trabajo entre opus 5.5 y grok; para una pyme eso es una factura de API que el vídeo no menciona al recomendar «pstack para agentes nocturnos».
• «Construye el tuyo» es también el producto que vende. El consejo final —no trates los packs como religión, roba lo que funcione, escribe tus skills— es sensato y, a la vez, exactamente el gancho del curso de pago. La conclusión más útil no es adoptar un pack: es leer los tres, quedarse con la escalera de ceremonia y escribir cinco skills propias con las convenciones de tu equipo antes de instalar veinticinco ajenas.