KX-P01
limpieza-outie
Limpieza completa en una pasada para archivos que van hacia afuera/publicación. Spec escrita heredando el detalle calibrado de las herramientas atómicas. Sin correr todavía bajo el formato combinado.
Catálogo, convenciones, arquitectura.
Fuente en la bóveda:01 - matriz/Mapa de Skills.md Las skills del sistema: cómo se escribe una, dónde vive, cómo se decide si algo merece ser skill, y cuándo una skill se parte en dos. Una skill es una pieza de tipo skill en el estado del sistema.
No entra acá el contenido de cada skill (eso está en su SKILL.md) ni el pipeline completo que la usa (eso es Mapa de Flujos.md).
Limpieza completa en una pasada para archivos que van hacia afuera/publicación. Spec escrita heredando el detalle calibrado de las herramientas atómicas. Sin correr todavía bajo el formato combinado.
Corre después de limpieza-innie: subtítulos, banderas, frontmatter de cuadrantes y personas. Scaffolding listo, catálogos de banderas/cuadrantes/personas todavía vacíos. Sin corridas de prueba.
Referencias académicas interdisciplinarias ancladas al texto. Spec formal calibrada por conversación. Sin correr todavía bajo esta spec exacta sobre un ensayo real.
Publica un módulo como par de páginas Astro (textual + mapa visual), cruzadas por anchors, con la tarjeta del hub actualizada. Un solo caso construido hasta ahora (00 · módulo base), sin calibrar sobre un segundo.
Limpieza completa en una pasada para archivos hacia adentro/self-archivo. Ya corrida bajo el formato combinado. Se dispara automático para stream journals clase a/c.
Batch runner manual: procesa todos los raw de una fecha en una corrida, ruteando por clase, con reporte consolidado de palabras dudosas al final.
Procesa treats lingüísticos de los batches Treats & Quotes y los publica como entradas formales. Se encadena automático con procesar-quotes al final.
Convierte candidatos a quote en entradas formales dentro de hyperlynkx-page/src/content/quotes/. Se invoca sola o encadenada desde procesar-linguistic-treats.
Nace el 26.08.01 de fusionar destilar-sesion-kx con KX-P20 (nunca escrita): en la practica, extraer e implementar nunca corrieron separados. Procesa un system journal del kx system factory module de punta a punta: extrae candidatos, pregunta lo genuinamente ambiguo antes de comprometerse (absorbe el rol de KX-P20), reconcilia contra el estado actual, escribe en la Matriz (fuente), las colecciones (indice) y el patch notes (log), implementa en la misma corrida, y cierra el system journal. Nunca compara contra system journals anteriores, nunca resuelve una contradiccion sola. Hereda el historial de calibracion de destilar-sesion-kx (dos corridas reales, KX-S05 y KX-S06). Primera corrida como skill fusionada el 26.08.01 sobre KX-S07: los dos pasos nuevos (preguntar antes de comprometerse, implementar en la misma corrida) funcionaron. Desde el 26.08.02 (KX-T62) suma el Paso 8b, sincronizar la pagina: un npm run build al final, que via prebuild regenera kx-eventos, kx-areas y kx-jornadas desde la boveda. Se corre siempre que la corrida haya tocado la boveda, aunque no se haya tocado hyperlynkx-page: escribir en el patch notes o en la Matriz ES un cambio de la pagina. Tambien documenta los campos que se olvidan: area en tareas, fechaInicio/fechaFin al cambiar estado, y los campos de kx-workflows. Renombrada el 26.08.02 de procesar-sesion-autopoiesis, junto con el modulo de sesiones (hoy stream journals) y el de ciclo de implementacion (hoy jornada de implementacion).
La skill de cierre de la jornada de implementacion, decidida el 26.08.01 como una sola skill con dos resultados (no dos skills separadas). Terminado: doble revisado de que todo lo implementado esta en la Matriz, el patch notes y las colecciones, mas los dos campos que mas se olvidan (fechaFin al pasar a finalizado, area en tareas nuevas). Pausado o abandonado: registra que se hizo, que no, el proposito inicial, y que hace falta para retomar sin reconstruir el contexto de memoria. No fuerza terminado si encuentra huecos, prefiere pausado. Desde el 26.08.02 (KX-T62) SI deja la pagina al dia: corre npm run build al cerrar, que via prebuild regenera kx-eventos, kx-areas y kx-jornadas desde la boveda. El chequeo concreto es que la jornada cerrada deje de aparecer como activa en el hub. Primera corrida real el 26.08.01 sobre KX-I01: resultado terminado, doble revisado sin huecos. Segunda corrida el 26.08.02 sobre KX-I02, primera con el Paso 4 (sincronizar la pagina) ya incorporado: resultado terminado, doble revisado de diecinueve objetos, dos sumados a produjo que faltaban, un cabo de fecha anotado sin bloquear el cierre por ser politica ya establecida (no inventar fechaFin sin evidencia real). Renombrada el 26.08.02 de cerrar-ciclo-implementacion, junto con el resto del concepto (ciclo -> jornada de implementacion).
Herramienta atómica de limpieza mecánica. Retirada como skill invocable, absorbida dentro de limpieza-innie/limpieza-outie. Referencia histórica en deprecated/.
Herramienta atómica de limpieza estructural/semántica (variante formal). Retirada como skill invocable, absorbida dentro de limpieza-outie. Referencia histórica en deprecated/.
Variante informal de la limpieza estructural. Retirada como skill invocable, absorbida dentro de limpieza-innie. Referencia histórica en deprecated/.
Nunca llegó a tener SKILL.md propio. El 26.08.01, al escribirla, se decidió fusionarla con destilar-sesion-kx en vez de crearla aparte: en la práctica (KX-S05, KX-S06) extraer e implementar nunca corrieron separados. Su rol (leer Atlas y tareas, preguntar antes de comprometerse, implementar) vive ahora en KX-P16 (procesar-sesion-autopoiesis). Este id queda como referencia histórica, no se reusa.
.claude/skills/{nombre}/SKILL.md. Hay dos niveles y la diferencia importa:ground up kx vault/.claude/skills/): las que solo tocan archivos de la bóveda. Se cargan cuando la sesión trabaja adentro de la bóveda..claude/skills/ en la raíz): las que escriben en proyectos/hyperlynkx-page/. Tienen que estar arriba porque la bóveda y la página son hermanas, no anidadas.SKILL.md: frontmatter con name y description, y después el cuerpo. La description es lo único que se lee para decidir si la skill se dispara, así que lleva los disparadores textuales de Teo tal como los dice. El cuerpo va: input y output, el proceso paso a paso, gotchas ya pisados, "qué NO hace", y "estado" al final.description..claude/skills/deprecated/, no se borran. Sirven de referencia histórica.SKILL.md dice si está calibrada con corridas reales o si sigue siendo la mejor hipótesis. No se borra ni se maquilla: es la diferencia entre confiar en una skill y confiar de más.Revierte la decisión de acá abajo, y no porque estuviera mal: porque su premisa dejó de ser cierta. Decía que las skills que escriben en la página tenían que vivir en el .claude/skills/ de la raíz del workspace «porque la bóveda y la página son hermanas, no anidadas».
Ese día la página se mudó adentro de la bóveda. Dejaron de ser hermanas, y con eso el motivo entero de la separación se evaporó. Las once skills viven ahora en .claude/skills/, en la raíz de la bóveda, sin distinción de nivel.
Lo que se gana no es solo orden. La separación obligaba a decidir, antes de escribir una skill, si iba a tocar la página o no; y esa pregunta se contestaba mal seguido, porque casi cualquier skill del sistema termina escribiendo en alguna colección.
Lo que queda como vocabulario muerto: varios SKILL.md todavía dicen «nivel bóveda» o «nivel workspace», y la convención de ubicación de más arriba también. Es prosa que sobrevive a una estructura que ya no existe, anotada acá para que la próxima corrida no la lea como si describiera algo real.
Se evaluaron dos arquitecturas para procesar una sesión de sistema, y Teo cerró la decisión en la misma sesión sin pedir análisis previo.
| | Qué hace | Por qué se evaluó | |---|---|---| | **A, descartada** | Escribe un documento de plan estructurado en una subcarpeta `Planes de Sesiones/`, y después Teo abre otro chat y lo ejecuta | Deja el plan como artefacto revisable y reusable | | **B, elegida** | Sin archivo intermedio: la skill lee la sesión, planifica, pregunta e implementa en la misma corrida | Menos fricción, y menos archivos |
Los dos argumentos que decidieron: la fricción, porque grabar y decir "corré la skill" es todo lo que Teo quiere tener que hacer; y uno más fino y más importante, que la IA lea los pensamientos crudos en vez de un plan derivado de ellos. Si el archivo de plan existe, la implementación se hace contra el resumen y no contra lo dicho, y ahí se pierde exactamente lo que la sesión larga tenía de valioso.
Consecuencia registrada: la subcarpeta agente/01 - sistema/Sesiones/Planes de Sesiones/ que se propuso a mitad de la sesión queda cancelada, no pendiente. Y no hay dos skills separadas (una que estructura, otra que implementa): es una sola.
Confirmado el mismo día, más tarde: esta decisión predijo lo que terminó pasando también con destilar-sesion-kx y KX-P20, que se fusionaron por el mismo motivo (ver la entrada de procesar-system-journal arriba).
De A sobrevivió, por un rato, la idea de una property planificada para saber cuáles sesiones ya se habían procesado. El 26.08.01, en la misma fecha, Teo la descartó también: en vez de agregar un cuarto valor al lifecycle, lo simplificó a dos (sin-procesar / procesada). Ver Mapa de Instancias.md.
destilar-sesion-kx (hoy procesar-system-journal), publicar-modulo-kx y procesar-quotes vivían en el .claude/skills/ de la raíz del workspace, no en el de la bóveda, porque escriben en proyectos/hyperlynkx-page/src/content/. Las de limpieza y estructura se quedaban a nivel bóveda.
Se conserva porque explica por qué hubo dos carpetas de skills durante tres semanas, y porque el vocabulario que dejó sigue apareciendo en los SKILL.md.
Cuando existe un documento de diseño, el SKILL.md lleva la instrucción ejecutable y linkea al documento para el porqué. No se copia el razonamiento adentro de la skill. Aplicaba entre destilar-sesion-kx y Plan de Andamio - Estructura del Kx Core Module.md; hoy es procesar-system-journal la que linkea a ese documento y también a Plan de Jornada de Implementacion.md.
procesar-context-journal (KX-T74), la skill que le falta al agente. Procesa los context journals de agente/00 - teo/02 - context journals/, reparte el material entre el core y las dimensiones, y reorganiza la estructura de dimensiones misma a medida que entra material. Ese segundo trabajo es la mitad del punto y no un efecto secundario: el andamio del 26.08.15 es una hipótesis que se espera que la skill corrija. Sin construir; hasta que exista, los context journals se acumulan sin procesar, y eso es el plan.KX-T25: arquitectura de skills, una sola o varias por pipeline. La fusión de procesar-system-journal es el primer caso real resuelto, pero la pregunta general (para otros pipelines) sigue abierta.KX-T79: el escalón que le falta al procesamiento de stream journals. Lo que hay hoy (limpieza-innie, limpieza-outie, estructura-innie) es procesamiento sintáctico: negrita, párrafos, subtítulos. Teo marcó el 26.08.15 que falta el paso siguiente, el que hace algo con el contenido: publicar un HTML, volcarlo al contexto del agente, y armar una meta bitácora de journals, eventos y días. Sin forma todavía, y él mismo lo dejó para después.KX-T35: skills por párrafo, sin especificar.KX-T34: naming de las carpetas de skills nuevas.KX-T21: skill de revisión holística.KX-T41: paquetes skill paper y condenser.