📖 Glosario vivo (lee antes — vuelve siempre que lo necesites)
Ya sabes qué son una skill, procedure y grill-me (Trilha 3). Aquí solo están los términos nuevos de este módulo —fija estos antes de seguir:
🔗 grill-me → PRD → issues
🧠 Imagínalo así: una fábrica de muebles. La madera en bruto entra; pasa por la sierra, luego por la lijadora y después por el barniz. Cada estación hace una algo bien hecho y lo pasa adelante. Nadie intenta serrar, lijar y barnizar en el mismo movimiento. Tu pensamiento también se convierte en una línea de montaje: idea en bruto → entrevista → documento → tareas.
En el módulo 3.5 viste la grill-me — la skill que te entrevista hasta llegar a un shared understanding (entendimiento compartido). Es poderosa por sí sola, pero Matt Pocock no se queda ahí: la usa como primera estación de una línea. En sus palabras, él encadena tres skills seguidas: grill-me → two-PRD → to-issues. Es lo que él llama, en la práctica, «pipeline de pensamiento».
La lógica de cada estación: la grill-me saca el desorden de tu cabeza y alinea la visión; la two-PRD toma esta alineación y escribe un PRD (el documento de requisitos del producto); y la to-issues divide el PRD en un backlog de issues listas para implementar. Pasas de una idea vaga en la cabeza a tareas concretas en el backlog, sin escribir una sola línea de código en el camino. El porqué: cada paso es pequeño y verificable, así que es fácil corregirlo antes de que el error se propague. El error común es saltar directamente de la idea al código (pedir "implementa esto" a ciegas) y descubrir, tres horas después, que la IA construyó algo equivocado.
El pipeline de Matt: tres skills encadenadas se convierten en una línea de ensamblaje del pensamiento.
En 1 frase: encadenar skills es montar una línea de producción que lleva tu idea en bruto hasta un backlog de tareas listas.
Profundiza (opcional): ¿por qué «two-PRD»?
El nombre sugiere una skill que produce el PRD en dos pasadas — primero un borrador amplio, después una versión refinada — en vez de intentar acertar en todo de una vez. Es el mismo principio del pipeline aplicado dentro de una estación: los pasos pequeños y verificables casi siempre superan a un golpe gigante. Lo importante no es el nombre exacto de la skill, sino la idea: cada estación hace un trabajo enfocado y entrega algo mejor de lo que recibió.
⛓️ Procedimientos en secuencia
🧠 Imagínalo así: una receta de pastel con pasos numerados. No echas los huevos, la harina y la levadura de cualquier manera y cruzas los dedos: bates las claras primero, luego mezcla y después hornea. El orden es la receta. Encadenar procedures es exactamente eso: pasos numerados que tú lanza, uno a la vez.
Recuerda la distinción de la Ruta 3: existen procedimientos (tú invocas) y abilities (el modelo lo invoca por sí solo). El pipeline de Matt está hecho de procedimientos: decide en cada paso qué skill ejecutar. Por eso, «encadenar» aquí no es magia automática, sino tú llamando a grill-me, leyendo el resultado, luego llamando a two-PRD, volviendo a leer y solo entonces a to-issues. Cada eslabón de la cadena es una decisión consciente tuya.
¿Por qué usar procedures y no una «mega-skill» que lo hace todo? Porque cada estación tiene un punto de control. Después de grill-me verificas si la alineación coincide con tu visión; después del PRD verificas si los requisitos son correctos; solo entonces permites que se divida en issues. Si algo salió mal, corriges ahí, barato, antes de propagarlo al resto. El error común es querer que la IA pase de idea → código con un solo comando: entonces no hay dónde detenerse y corregir, y cuando aparece el error ya contaminó todo. Una secuencia con checkpoints es más lenta en cada paso, pero mucho más rápida en total, porque casi nunca tienes que rehacer nada.
Recuperación rápida: ¿por qué Matt usa procedures encadenadas en vez de una única «mega-skill» que lo hace todo?
En 1 frase: son procedimientos (tú los invocas), uno a la vez, con un punto de verificación entre cada eslabón de la cadena.
🎮 Tú al volante
🧠 Imagínalo así: un auto con piloto automático. Puedes soltar el volante y dejar que te lleve — pero Matt prefiere mantener las manos en el volante. El auto ayuda con la parte tediosa (mantenerse en el carril), pero él elige el destino y cada curva. El pensamiento es suyo; la IA es solo la dirección asistida.
Aquí aparece la filosofía central de Matt, que surgió en la Trilha 3 y se cierra ahora: él prefiere procedures justamente porque quiere estar al volante. En sus palabras: "I know my skills, I don't want to delegate my thinking" ("conozco mis skills, no quiero delegar mi pensamiento"). Le oculta al modelo la mayoría de las descripciones de las skills (disable model invocation) y mantiene el conocimiento en la persona. El pipeline grill-me → PRD → issues es la forma concreta de hacerlo: la IA ejecuta cada etapa, pero quien dirige la cadena eres tú.
Aquí hay un contraste entre escuelas que vale la pena conocer. Otras personas (p. ej., el enfoque Superpowers, de la Obra) prefieren lo opuesto: dejar que el el modelo al mando, invocando skills por su cuenta. Matt prefiere el humano al mando. No es que una esté bien y la otra mal: es una decisión sobre cuánto quieres delegar el pensamiento. O porqué de la elección de Matt: el pensamiento de producto y arquitectura es la parte que de verdad crece contigo, así que no delega esta parte. El error común es confundir «dejar que la IA haga el trabajo pesado» con «dejar que la IA tome las decisiones»: encadenar procedimientos te da lo primero sin ceder lo segundo.
🔬 Ejemplo resuelto: la misma función, con y sin el volante
Tarea: agregar "exportar informe en PDF" a la app. Las mismas skills disponibles, dos posturas:
Sin el volante
"IA, agrega la exportación a PDF; tú decides todo." → Elige una biblioteca pesada, inventa un diseño y rompe la pantalla de informes existente. Te das cuenta recién al final y tienes que rehacerlo.
Con el volante (pipeline)
grill-me te pregunta: «¿una página o varias? ¿Reutilizar el diseño actual?» → se ponen de acuerdo. two-PRD redacta los requisitos. to-issues genera 3 issues pequeñas. Revisas cada paso, y la IA implementa lo que tú decidió.
En 1 frase: la IA hace el trabajo pesado de cada estación; el pensamiento — y el volante — siguen siendo tuyos.
♻️ ¿Se repitió 3 veces? Se convierte en skill
🧠 Imagínalo así: tú anotas la misma receta de café en un papelito cada mañana. La tercera vez, te detienes y piensas: "¿por qué no pego esto en la pared de una vez?". A partir de ahí, nadie en casa tiene que recordarlo: está escrito. Skill es el papel en la pared de tu flujo de trabajo.
En programación existe un principio famoso: DRY ("Don't Repeat Yourself", no te repitas). La idea clásica: si copias y pegas el mismo fragmento de código, conviértelo en una sola función. Matt aplica esto al humano: si hiciste lo mismo plan, lo mismo flujo de pensamiento, varias veces manualmente: detente y conviértelo en una skill. Su frase es directa: "I've made this plan 100 times → turn it into a skill" ("hice este plan 100 veces → conviértelo en una skill").
La regla práctica que funciona: si lo repetiste unas tres veces, se convierte en una skill. Una vez puede ser suerte; dos, coincidencia; a la tercera ya es un patrón, y un patrón pide automatización. Recuerda la Ruta 2: puedes empaquetar knowledge + skill (lo que sabes y lo que ya has hecho muchas veces) en un procedimiento reutilizable. Lo que no se puede empaquetar es la sabiduría (saber CUÁNDO usarlo); por eso el disparador "repetiste 3x" es tuyo, no de la IA. El error común son dos extremos: o nunca empaquetar (y rehacer el mismo plan para siempre), o empaquetar todo demasiado pronto (y llenar el contexto de skills que usaste una sola vez). La tercera repetición es el punto de equilibrio.
En 1 frase: DRY humano = la tercera vez que repitas un plan a mano, conviértelo en una skill.
Profundiza (opcional): ¿por qué «3 veces» y no «1 vez»?
Empaquetar demasiado pronto tiene un costo que ya conoces de la Trilha 3: cada skill se filtra tu description en la ventana de contexto. Una skill que usaste una sola vez es puro costo, sin retorno. Esperar a la tercera repetición garantiza que el patrón es real y recurrente; entonces la inversión de escribir la skill se compensa muchas veces. Es el equilibrio entre no repetirse (DRY) y no inflar el contexto (higiene de contexto).
🌊 Distribuir al equipo
🧠 Imagínalo así: un restaurante donde solo el chef sabe preparar la salsa secreta. Cuando falta, el plato sale mal. Ahora escribe la receta y pégala en la cocina: todo el cocinero siempre acierta con la salsa. El peor plato de la casa subió de nivel. Una skill compartida es la receta en la pared de la cocina del equipo.
Aquí la cosa se pone grande. Después de convertirlo en skill, Matt lo distribuyes al equipo: "distribute to the team, everyone plans the same way" ("distribúyelo al equipo, todos planifican de la misma manera"). De repente, tu mejor flujo de planificación no vive solo en tu cabeza: se convierte en el estándar de todos. El júnior que planificaba mal ahora planifica con la misma skill que el sénior. Eso es lo que él llama "raising the floor" (elevar el piso): el peor caso del equipo mejora.
Fíjate en la diferencia entre elevar el techo e elevar el piso. Entrenar a una estrella individual eleva el límite: el mejor se vuelve mejor. Distribuir una skill eleva el piso — o peor El resultado posible del equipo mejora, porque nadie tiene que empezar desde cero. Y elevar el piso suele dar más frutos: un equipo donde incluso la peor planificación ya es «buena» produce con una calidad mucho más consistente. Esto se conecta con la Ruta 2 («tus skills son el techo»): cuando empaquetas y distribuyes, elevas el techo de cada persona a la vez. El error común es tratar tus skills como un secreto competitivo dentro del equipo: guardarlas solo para ti no te hace más valioso, hace que todo el equipo sea más lento.
En 1 frase: distribuir la skill eleva el nivel mínimo: la peor planificación del equipo pasa a ser, como mínimo, la mejor que tienes.
🔁 Contribuir de vuelta
🧠 Imagínalo así: la receta en la pared de la cocina no es sagrada. Cuando un cocinero descubre que una pizca de limón mejora la salsa, edita la receta en la pared. Al día siguiente, todos ya preparan mejor la salsa. La skill compartida está viva: mejora con el uso de todos.
El último eslabón cierra el ciclo: contribuir de vuelta. La frase completa de Matt es: "distribute to the team, everyone plans the same way, contributing back to that skill, raising the floor". Es decir: el equipo no solo usa la skill — cuando alguien detecta una mejora, la aporta a la skill compartida. Es el modelo de open-source aplicado a tu flujo interno: muchos ojos, muchas mejoras, un artefacto cada vez mejor.
Por eso, «elevar el piso» no es un evento único, sino un ciclo: cada contribución vuelve a elevar el piso, y el nuevo piso se convierte en el punto de partida de todos. Observa cómo se conecta todo lo de la Ruta 3: la anatomía de la skill (3.1) te dio la pieza; el costo de contexto (3.2) te enseñó a ocultarla cuando hace falta; teach skill (3.3) y la enseñanza que retiene (3.4) mostraron skills que aprenden; grill-me (3.5) te dio la primera estación; y ahora encadenas, empaquetas, distribuyes y mejoras en equipo. El error común es tratar la skill como "lista" después de escribirla: las buenas skills están vivas. A continuación, copia el pipeline completo y úsalo hoy:
# PIPELINE: da ideia crua ao backlog (rode UMA estação por vez, conferindo entre elas) # 1) grill-me — alinhe a visão antes de qualquer código /grill-me > Interview me relentlessly about every aspect of this plan until we reach a > shared understanding. Ask one question at a time and give your recommended > answer. If a question can be answered by exploring the codebase, do that instead. # -> CONFIRA: o entendimento bate com a minha visão? (se não, ajuste aqui) # 2) two-PRD — transforme o alinhamento num PRD /two-prd > Com base no que alinhamos, escreva um PRD: objetivo, requisitos, escopo, > o que está FORA do escopo, e critérios de aceite. # -> CONFIRA: os requisitos estão certos? falta algo? (corrija o PRD aqui) # 3) to-issues — quebre o PRD em tarefas pequenas /to-issues > Quebre este PRD em issues pequenas e independentes. Cada issue: título, > descrição e critério de aceite. Sem implementar nada ainda. # -> CONFIRA: cada issue é pequena e clara? entregue no backlog. # DRY humano: fez este pipeline 3x? -> vire skill -> distribua pro time -> # todos contribuem de volta -> o piso do time sobe.
Recuperación rápida: ¿qué significa «contribuir de vuelta» a una skill compartida?
En 1 frase: la skill está viva — quien la usa la mejora y la devuelve, y el nivel del equipo sube con cada contribución.
🧾 Resumen del módulo
Próxima ruta:
Ruta 4 — Técnicas Avanzadas: AFK, sandboxes, GitHub Actions, colas y sistemas que se mejoran a sí mismos. Sales del ciclo y pones a los agentes a trabajar mientras duermes.