[🤖] Conecté el hilo y el criterio de mi trabajo con Codex Skills

✨ Resumen de GPT-5.6 Sol

Un registro de cómo mantuve intacto el hilo del trabajo haciendo que Codex Skills releyera las reglas y las evidencias actuales, para llevar directamente a la siguiente tarea y a la escritura el criterio que acababa de formar al configurar un servidor Linux.

Hoy establecí la base operativa de un servidor Linux dedicado a los servicios de la empresa. Instalé Ubuntu Server en un SSD nuevo, lo conecté por SSH dentro de la red y diseñé los límites entre usuarios para que el administrador humano, las AI Cells y los Runtimes de automatización de trabajo pudieran convivir en un mismo servidor sin invadir los permisos ni el estado de los demás.

La estructura concreta de discos, red y cuentas del servidor quedó documentada aparte en el artículo enlazado arriba. Lo que quiero contar aquí no es el método de instalación, sino la experiencia de terminar ese trabajo sin que se cortara el hilo de los criterios que había formado.

Después de dejar en una Skill de red cómo se conectaban el router, el NAS, el Runtime existente y el nuevo servidor Linux, ya no tuve que explicar otra vez toda la lista de equipos en la siguiente session de Codex. También separé lo que ya estaba terminado de lo que aún era solo diseño. El criterio operativo que había adquirido mientras trabajaba con el servidor quedó en un estado que la siguiente tarea podía heredar sin perder nada.

Bien. Ahora que ya me he acostumbrado a usar Skills, puedo montar cosas como esta en un momento. Está genial. Al final, sea lo que sea, parece importante mantener el hilo sin perder el criterio.

Lo que me gustó en ese momento no fue solo haber creado una Skill con rapidez.

El criterio operativo que acababa de adquirir al trabajar con el servidor pasó a la estructura de usuarios; esa estructura quedó en la Skill de red y, después, continuó en el devlog que explicaba el trabajo. Al terminar de escribirlo, enseguida pensé que podía crear otra Skill que buscara el trabajo reciente en las conversaciones y el historial de Git y lo convirtiera en una entrada de diario.

Construir un servidor y crear una Skill de escritura son tareas completamente distintas, pero en mi cabeza formaban parte del mismo hilo. Durante el trabajo anterior no dejé de pensar qué información debía quedar para que la siguiente tarea no empezara desde cero, y a continuación estaba aplicando la respuesta a la estructura de la siguiente herramienta.

La nueva Skill reutilizó el hilo que ya había construido

Antes había creado gsheet-hour-blocks para generar registros de trabajo por horas destinados a mi agenda personal. En lugar de resumir solo la conversación actual, también leía el historial de Git de los repositories relacionados y comprimía lo que realmente había hecho en frases para bloques horarios.

Esta vez solo cambiaba la salida.

La base para leer las conversaciones recientes, los commands, los resultados de tools y las evidencias de Git de un periodo determinado ya existía. La nueva Skill no tenía que extraer una lista de tareas de esas evidencias, sino encontrar los problemas que yo había sentido de verdad y los cambios en mi criterio, y escribirlos como un diario independiente que siguiera las reglas actuales del blog.

No hacía falta diseñarlo todo desde cero. La forma de trabajar que había aprendido antes se convirtió en material para la siguiente.

También seguía ahí la experiencia de convertir la pregunta que repetía cada vez —«¿De verdad lo has hecho perfectamente?»— en una Skill llamada audit-and-fix-until-clean. Cuando detecto una exigencia recurrente, dejo de escribir otro prompt largo y la convierto en una forma de trabajo reutilizable con una condición de cierre. Después de toparme varias veces con el mismo patrón, pude ver mucho más rápido qué partes debían entrar en una Skill y cuáles debían quedarse en el project original.

Gracias a ese criterio, la estructura general de blog-write-diary quedó definida enseguida.

Pero Codex tomó una vez el camino equivocado.

Copiar las reglas no mantendría el contexto: lo dividiría

Al principio intentó trasladar a la nueva Skill las reglas de categorías, estilo, fechas y traducciones de este blog.

Eso no era lo que yo quería.

No me refiero a que copies esas reglas dentro de la Skill. Para ser exactos, quiero que lea directamente las reglas y el contexto del project cdb. Trasladar las reglas en sí puede hacerse más adelante.

Las reglas del blog siguen cambiando. Copiarlas en la Skill haría que las mismas reglas existieran en dos sitios. Al principio podría funcionar, pero tarde o temprano las reglas actuales del project y las reglas antiguas recordadas por la Skill se separarían. Un mecanismo creado para mantener el contexto acabaría fijando un contexto obsoleto.

Por eso hice que blog-write-diary no fuera propietaria de las reglas del blog.

La Skill solo recuerda el procedimiento: en qué orden leer la conversación actual, los commands y las evidencias de Git; cómo encontrar el centro que los conecta en un único hilo; y que, antes de escribir el artículo, debe volver a comprobar el AGENTS.md, las categorías y los artículos vecinos actuales de cdb.

Las reglas que cambian permanecen en el project original, y cada vez que se ejecuta, la Skill vuelve a esa source of truth.

Esa diferencia era la clave. En vez de hacer que la IA recordara todo el contexto durante mucho tiempo, construí un camino para que pudiera volver a entrar con precisión en el contexto actual cuando hiciera falta.

Lo que se mantuvo no fue la cantidad de información, sino el criterio

El context de la IA es limitado. Las conversaciones largas se comprimen y, al pasar a otra session, los matices de las decisiones anteriores desaparecen con facilidad. Pero tampoco puedo guardar todas las conversaciones para siempre y hacer que la IA las relea completas cada vez.

Conservar toda la información no era lo importante.

Al empezar la siguiente tarea, necesitaba poder reconstruir por qué importaba un límite, qué había descartado ya, qué había decidido proteger y en qué source debía confiar ahora. Cuando se recupera ese estado, la IA no se limita a imitar la conclusión: puede continuar el razonamiento anterior.

A mí, como persona, me ocurría lo mismo.

Hoy veía de inmediato por qué había que separar las cuentas del servidor y los Runtimes, y por qué no se debían copiar las reglas del project en una Skill. Los motivos de esas decisiones seguían calientes. Cuando pasa el tiempo y solo queda una conclusión borrosa, releer la misma explicación no permite retomar el trabajo con el mismo criterio ni con la misma rapidez.

Una vez escribí que la memoria humana se comprime y revive a través de pistas. Esta vez había convertido esa idea en una forma real de trabajar.

Las Skills, AGENTS.md y el historial de Git no son almacenes que conserven cada instante. Son pistas que permiten a la IA de la siguiente session —y a mi yo del futuro— reconstruir el criterio necesario para volver al trabajo. Un camino que me permite seguir de nuevo las fuentes y las evidencias actuales hasta una conclusión resultó más útil que una sola conclusión bien conservada.

Mientras el criterio siga vivo, construyo también la siguiente parte del hilo

Lo que hizo agradable esta experiencia no fue solo haber creado blog-write-diary rápidamente.

El criterio que adquirí al montar el servidor Linux pasó a la estructura de usuarios y a la Skill de red. Esa decisión operativa continuó en el devlog, y el hilo de escribir ese artículo llevó al diseño de una nueva Skill de diario. En ningún momento tuve que volver por completo al principio.

Eso fue lo que me gustó.

Ya sea desarrollando o escribiendo, pasar a la siguiente tarea mientras las decisiones construidas en la anterior siguen vivas no solo aumenta la velocidad. Como no tengo que vagar buscando otra vez qué es importante, también se mantiene el nivel del resultado. Puedo explicar por qué algo funciona y, cuando veo una estructura equivocada, puedo detenerme antes.

La estructura que creé para manejar el context corto de la IA también está compensando mi memoria corta. Pero el hecho de que las personas y la IA olvidemos no es toda la conclusión de este texto.

Lo que quiero seguir construyendo se parece menos a un dispositivo de memoria que a un dispositivo para volver a conectar el hilo.

Para que la próxima vez no tenga que explicarlo todo desde cero ni esforzarme por recuperar el criterio, sino que pueda dar el siguiente paso directamente desde el criterio al que ya había llegado.