📖 Glosario vivo (lee antes — vuelve siempre que lo necesites)
Este es el módulo final: aquí unes el ciclo de revisión con el «dónde encontrar». Estos son los términos nuevos de este tema:
🎬 Video walkthrough + TTS
🧠 Imagínalo así: un albañil termina una habitación y, en vez de enviarte el plano con garabatos, graba un video corto recorriendo la casa: «mira, aquí quedó el enchufe, abrí la ventana, la puerta cierra bien»; y va narrando mientras muestra. En 40 segundos entiendes más que leyendo 50 páginas. Eso es exactamente lo que hace la IA con cada cambio de pantalla.
Pocock describe lo que él llama revisión fluida: en cualquier cambio de front-end, la IA registra un video por sí misma recorriendo el cambio — abre la página nueva, hace clic en los botones y muestra cómo funciona de verdad. A partir de este video, llama a una herramienta de TTS (texto a voz) y narra lo que está pasando. El resultado: el PR te llega con un video de la cosa funcionando, con narración.
La razón es directa: ver es más rápido que leer. En vez de abrir 12 archivos de código e intentar imaginar el comportamiento mentalmente, presionas play y ve el cambio en marcha, con alguien explicándotelo. En sus palabras: "con cualquier cambio de front-end, la IA graba un video de sí misma recorriendo el cambio, usa TTS y lo narra — así el PR tiene un video de la funcionalidad en acción." Y es honesto sobre la etapa: "we're scratching the surface" (apenas hemos arañado la superficie). El error común es pensar que esto es un adorno; en la práctica, es lo que convierte una revisión de 20 minutos en una de 1 minuto.
La IA produce la evidencia visual; tú solo la ves y apruebas.
En 1 frase: en lugar de leer el código, ves un video narrado del cambio funcionando dentro del propio PR.
Profundiza (opcional): ¿por qué un video y no una captura de pantalla?
Una captura de pantalla muestra un estado estático; el comportamiento (la animación, qué ocurre al hacer clic, el estado de error) desaparece. El video captura el interacción — y la narración TTS aporta contexto («ahora envío el formulario vacío para mostrar la validación»). Es la diferencia entre ver la foto de un auto y verlo en marcha: solo una opción demuestra que funciona.
⚡ Optimizar la revisión humana
🧠 Imagínalo así: un gerente que recibe 20 informes separados cada mañana se volverá loco. Pero si el equipo reúne todo en un resumen de una página con los puntos en común, decide rápido. El secreto no es trabajar más, sino hacer que la revisión más barata para quien revisa.
El lema de Pocock aquí es claro: "optimiza para la revisión humana, hazlo más rápido" (optimiza la revisión humana, hazla más rápida). La revisión fluida es una forma; otra es no revisar 20 correcciones pequeñas una por una. En su lugar, sugiere generar un HTML al estilo de la teach skill con los patrones comunes de los bugs — un resumen que muestra qué es lo que más falla. Así revisas el estándar, no cada elemento por separado, y además aprendes a mejorar el sistema.
Hay un punto importante detrás de esto: "GitHub no se hizo para la era agéntica". Las herramientas de review se diseñaron para que humanos revisen a otros humanos, a ritmo humano. Cuando un agente abre decenas de PR al día, ese flujo se atasca. Por eso vale la pena invertir en lo que hace que la revisión sea rápida — video narrado, resúmenes de patrones, agrupación. El error común es mantener el ritual de revisar todo línea por línea como antes: te conviertes en el cuello de botella de tu propio sistema.
🔬 Ejemplo resuelto: 18 fixes de null-check se convierten en 1 review
Escenario: durante la noche, el agente abrió 18 PRs para corregir errores de «valor nulo». Dos formas de abordarlo:
Sin optimizar
Abres los 18 PRs, lees el diff de cada uno y apruebas uno por uno. ~2 horas, la atención agotada y no ves el patrón que hay detrás.
Review optimizado
El agente genera un HTML: "todos vienen de campos opcionales de la API sin valor predeterminado". Lees 1 página, ves la causa raíz, apruebas en lote y creas 1 skill que evita toda esa clase de bug. ~10 min.
En 1 frase: no revises 20 cosas pequeñas — revisa su patrón y optimiza la revisión para que sea rápida.
Recuperación rápida: ¿cuál es el objetivo del "review fluido"?
📦 mattpocock/skills
🧠 Imagínalo así: no necesitas inventar una receta de cocina desde cero: existe un recetario gratuito con recetas probadas que alguien que cocina muy bien ya preparó. Tomar la receta lista y adaptarla a tu horno es mucho más inteligente que empezar con harina y huevo.
El primer lugar donde buscar es el repositorio público github.com/mattpocock/skills — el cuaderno de skills del propio Pocock. De ahí vienen las skills que muestra en el video: la teach skill, a grill-me, las del pipeline (grill-me → PRD → issues). Como son procedimientos, la instalas, la usas y personaliza — no tienes que estar de acuerdo con todo; adáptalo a tu proyecto.
La razón para empezar con skills ya hechas: ya incluyen conocimiento incorporado (principios de enseñanza, preguntas adversariales, formato de PRD). Obtienes meses de prueba y error gratis. Y como funcionan con múltiples agentes (Claude Code, Codex, etc.), no quedas atado a una herramienta — en línea con el «setup agent-agnostic» de la Trilha 1. El error común es instalar todo de una vez y saturar el contexto (recuerda la Trilha 1.6: cada skill consume una parte de la ventana de contexto). Incluye solo lo que vas a usar.
En 1 frase: github.com/mattpocock/skills es el cuaderno de procedures listas de Pocock: tómalas, úsalas y adáptalas.
🌐 aihero.dev / aihero.dev/skills
🧠 Imagínalo así: además del recetario, el chef tiene un sitio web y un boletín semanal donde explica las técnicas detrás de cada plato y avisa cuando inventa uno nuevo. Quien se suscribe nunca queda desactualizado. Es el complemento del repositorio.
El segundo lugar es el aihero.dev (y la sección aihero.dev/skills) —el sitio de contenido de Pocock, con una newsletter. Mientras GitHub guarda el código de las skills, aihero.dev guarda el contexto: por qué existe cada skill, cómo se diseñó y qué hay de nuevo. Allí aparecen skills actualizadas y explicaciones. Piensa en GitHub como la despensa y en aihero.dev como el libro que te enseña a cocinar.
La razón para seguir ambos: las skills evolucionan rápido. El repositorio te da la versión actual; el boletín te avisa cuando algo cambia y por qué. Suscribirte es la forma barata de mantener tu harness afinado sin tener que vigilar GitHub todos los días. El error común es copiar una skill una vez y no volver a revisarla: te pierdes las mejoras y te quedas con una versión vieja de algo que su autor ya perfeccionó. Seguir la fuente es parte de «construir patrimonio», no de «alquilar» (Trilha 1).
En 1 frase: GitHub te da el código; aihero.dev (y su newsletter) te da el porqué y las actualizaciones.
⌨️ npx skills latest add
🧠 Imagínalo así: instalar una skill es como descargar una app de la tienda: escribes un comando, eliges la que quieres de una lista y listo: ya está disponible para usar. Sin armar nada a mano.
Se instala con un solo comando: npx skills latest add. O npx descarga y ejecuta el instalador de inmediato; te muestra una lista de skills disponibles y tú elige cuál agregar (por ejemplo, la teach skill). Así fue exactamente como Pocock instaló la teach skill en el video. Y lo mejor: "funciona en Claude Code, Codex, etc." — el mismo comando, varios agentes.
Un detalle entre bastidores que cuenta Pocock: ejecuta Claude Code con Opus 4.8, medium effort (no usa Fable), y espera cerca de 1 mes antes de adoptar un modelo nuevo; hizo esto con el Opus 4.5. Es decir, el comando es estable y agnóstico; la elección del modelo es una decisión aparte y tranquila. El error común es empezar a agregar decenas de skills "por si acaso": cada una filtra su descripción en el contexto. Agrega una, úsala de verdad y solo entonces agrega la siguiente. Copia el comando de abajo:
# 1) INSTALAR uma skill (escolha na lista — ex.: a teach skill) # funciona em Claude Code, Codex etc. npx skills latest add # 2) ONDE ACHAR skills prontas (o "caderno de receitas" do Pocock): # - GitHub (o código): https://github.com/mattpocock/skills # - Site + contexto: https://aihero.dev # - Skills + newsletter: https://aihero.dev/skills # Dica: adicione UMA skill, use de verdade, depois a próxima. # Setup do Matt: Claude Code + Opus 4.8 (medium effort); espera ~1 mês p/ adotar modelo novo.
En 1 frase: npx skills latest add abre una lista, tú eliges la skill y funciona en Claude Code, Codex y compañía.
Recuperación rápida: ¿cómo instala Pocock una skill (p. ej., la teach)?
🚀 Los 2 primeros pasos hoy
🧠 Imagínalo así: antes de redecorar la casa llena de trastos, vacías la habitación para ver el espacio real — y solo entonces vuelves a poner, pieza por pieza, lo que de verdad hace falta. Primero la limpieza, después los muebles.
El cierre de Pocock son dos pasos para hacer hoy. Paso 1: el reset: elimina todo — toda skill, plugin, MCP server, tu CLAUDE.md, agents.md → vuelve a cero absoluto y observa el agente. "Everyone bloats up their context window with too much stuff" (todo el mundo satura la ventana de contexto). En el modo básico ves lo que el agente realmente hace y lo que falta.
Paso 2 — reorganizar con procedures: ve agregando encima, y que sean procedimientos (no abilities), instaladas de una manera que puedas personalizar y experimentar. Vuelve a incorporar solo lo que eches de menos (por ejemplo, el brainstorming de superpowers). Después sigue el ciclo de siempre: encuentra problemas → encuentra soluciones → delega la implementación a un agente AFK. "AFK is just incredible — takes a bit of setup, but then it goes crazy." O error común es saltarte el reset y seguir acumulando: nunca ves lo que realmente necesitas.
PASSO 1 — RESET (volte ao zero e observe): [ ] deletar TODAS as skills [ ] deletar plugins e MCP servers [ ] deletar CLAUDE.md e agents.md [ ] rodar uma tarefa real e OBSERVAR o agente puro (o que falta?) PASSO 2 — RECAMADAR (só o necessário, e procedures): [ ] trazer de volta só o que senti falta (ex.: brainstorming do superpowers) [ ] instalar como PROCEDURE customizável: npx skills latest add [ ] achar problemas → achar soluções → delegar a implementação a um agente AFK
En 1 frase: resetea a cero y observa; después reorganiza solo con procedures personalizables — y delega el resto al AFK.
🎉 ¡Felicidades! Completaste el HARNESS.
Recorriste las 5 rutas del método Matt Pocock: desde los fundamentos (motor × chasis) hasta las habilidades humanas, desde las skills de IA hasta las técnicas avanzadas, hasta las soluciones listas para copiar. Ahora tienes el vocabulario e las recetas. Este último módulo cerró el ciclo: hacer que el review humano sea fluido y saber exactamente dónde buscar skills para seguir evolucionando.
npx skills latest add y elige de la lista; funciona en Claude Code, Codex, etc.¿Y ahora?
Haz los 2 pasos de hoy en tu proyecto real. Vuelve a las soluciones de la Trilha 5 siempre que necesites copiar una receta: para eso fueron creadas. Recuerda la tesis principal: el secreto no está en el modelo, está en el harness que controlas. ¡Que te vaya bien! 🏎️