📁 Anatomía de un workspace portátil
AGENTS.md, context/, tasks/, handoffs/. El módulo anterior dijo que la capa duradera es Markdown común dentro del proyecto. Este módulo muestra exactamente qué archivos son, qué va en cada uno, quién los lee y en qué orden. Es el árbol que el kit instala con init-core.sh y que los mega-prompts mandan construir. Los nombres son convención: nada de esto se carga solo, y vas a ver cómo resolverlo.
📄 README.md vs AGENTS.md: humano vs agente
Un workspace portátil empieza con dos archivos en la raíz, y es fácil confundirlos. El README.md es para personas: onboarding humano, cómo ejecutar, cómo probar, qué hay en cada carpeta. El AGENTS.md es para agentes: instrucciones concisas, reglas estables y, en la parte superior, un orden de lectura explícito que le dice al agente qué archivos abrir antes de actuar.
Este es el árbol completo que propone el kit. Vas a reconocer cada carpeta a lo largo de este módulo:
meu-projeto/
├── README.md # onboarding humano
├── AGENTS.md # instrucciones + orden de lectura (Codex, Gemini, GLM)
├── CLAUDE.md # "@AGENTS.md" + residuo específico de Claude
├── context/
│ ├── overview.md # qué es, hechos verificados, preferencias, hipótesis
│ ├── current-state.md # qué funciona y qué está pendiente
│ ├── sources.md # de dónde vino cada información + regla de refresh
│ └── decisions/ # una decisión aceptada por archivo
├── tasks/
│ └── current.md # objetivo, responsable, criterio de listo, próxima acción
├── handoffs/
│ └── latest.md # continuación para la próxima sesión
├── .agents/
│ └── skills/ # skills canónicas del proyecto
└── scripts/
└── check.sh # verificación mínima
La caja grande es el proyecto. En la primera línea, los archivos de entrada: README para personas, AGENTS.md para agentes, y el CLAUDE.md punteado porque solo importa el AGENTS.md. En la segunda línea, las cinco carpetas portátiles que el resto del módulo explica.
¿Nuevo aquí? "README" es el archivo que todo repositorio muestra en la página inicial; está escrito para una persona que llega sin contexto. "AGENTS.md" es una convención adoptada por Codex, Gemini y otros: un archivo de instrucciones que el agente lee al iniciar en el proyecto. Los dos pueden decir cosas parecidas, pero el README explica y el AGENTS.md ordena.
✓ Va en el AGENTS.md
- ✓Orden de lectura: "lee 1) este archivo, 2) context/overview.md, 3) current-state, 4) tasks/current.md, 5) handoffs/latest.md".
- ✓Reglas estables: autor del commit, versionado, dónde están las keys, qué nunca hacer.
- ✓Tabla de responsables: quién actualiza cada archivo y cuándo.
✗ No va en el AGENTS.md
- ✗Tutorial de instalación y prosa larga: eso es README.
- ✗Estado actual y tarea en curso: cambian en cada sesión, tienen archivo propio.
- ✗Cualquier cosa específica de un runtime (plugin, hook, menú interactivo): eso es residuo del CLAUDE.md.
Conceptos clave
Onboarding humano. Explica.
Instrucciones concisas para agentes. Ordena.
Lista explícita al inicio del AGENTS.md.
Primera línea del CLAUDE.md: importa lo portátil.
🧭 context/overview.md y current-state.md
La carpeta context/ es el conocimiento duradero del proyecto. Los dos primeros archivos responden a preguntas diferentes. El overview.md responde "¿qué es esto?": qué hace el proyecto, para quién, los hechos verificados (cada uno con fuente y fecha), las preferencias del dueño y las hipótesis aún no confirmadas. Cambia despacio. El current-state.md responde "¿cómo está ahora?": qué funciona, qué está roto o pendiente, qué cambió desde el overview. Cambia en cada sesión.
¿Nuevo aquí? "Overview" es la visión general estable. "Current state" (estado actual) es la fotografía del momento. Separarlos evita el error clásico de un solo archivo que mezcla "el proyecto es X" con "hoy el build está roto": el agente no sabe qué sigue siendo válido. Un hecho verificado es el que tiene fuente y fecha al lado; sin eso, es hipótesis.
overview.md
# Overview
- ID: overview | Alcance: proyecto
- Fuente: | Fecha de observación:
- Estado: borrador | Revisar en:
## Qué es
## Para quién
## Hechos verificados (con fuente y fecha)
## Preferencias (del dueño del proyecto)
## Hipótesis (no verificadas)
Encabezado con ID, alcance, fuente, fecha y estado. Es lo que permite decir si el archivo sigue siendo válido.
current-state.md
# Estado actual — AAAA-MM-DD
- Última sesión:
- Qué funciona:
- Qué está roto / pendiente:
- Hechos que cambiaron desde el overview:
Corto y fechado. Si un hecho de aquí se estabiliza, sube al overview; si un hecho del overview cambia, el current-state avisa.
📊 Ejemplo real: el overview del propio kit (2026-09-13)
- •Hecho verificado: "Codex CLI 0.154.0 no tiene comando import; el import 'de un clic' es de la app de escritorio."
- •Hecho verificado: "Claude Code 2.1.270 con 116 skills; Codex con 27."
- •Hipótesis: "La clasificación heurística de 71 skills como reutilizables es correcta en la mayoría; necesita muestreo."
- •Fíjate: el hecho tiene versión y fecha; la hipótesis dice qué falta para convertirse en hecho.
Conceptos clave
"¿Qué es esto?" Estable, con hechos fechados.
"¿Cómo está ahora?" Cambia en cada sesión.
Tiene fuente y fecha. Sin eso es hipótesis.
ID, alcance, fuente, fecha, estado, revisar en.
🔗 context/sources.md y context/decisions/
Dos archivos que casi nadie crea y que resuelven el problema más común de contexto: "¿cuál de las varias versiones de esta información es la correcta?" El sources.md es una tabla de de dónde vino cada cosa: ruta o URL, tipo (archivo local, export fechado o conexión viva), fecha, alcance y la regla de refresh. La carpeta decisions/ guarda una decisión aceptada por archivo, con contexto, la decisión en sí y las consecuencias.
sources.md del kit, tal como está hoy
| ID | Fuente | Tipo | Fecha | Alcance | Refresh |
|---|---|---|---|---|---|
| S1 | docs/migrar-claude-para-codex...md | export local | 2026-09-13 | filosofía | manual |
| S3 | docs/mega-prompts.pdf | export local | 2026-09-13 | prompts A/B | manual |
| S4 | relatorios/auditoria-*.md | generado por script | cada ronda | máquina local | ejecutar script |
| S5 | wifi/DIAGNOSTICO-CLAUDE-CODEX...md | diagnóstico | 2026-09-14 | máquina local | ejecutar doctor/audit |
Cuando dos informaciones entran en conflicto, miras la tabla: cuál tiene la fuente más confiable y la regla de refresh más reciente. No cuál tiene el timestamp mayor.
¿Nuevo aquí? "Sources" (fuentes) es el registro de procedencia: sin él, un hecho es solo una frase suelta. "Decisions" (decisiones) son registros cortos y fechados de lo que se decidió y por qué; el patrón viene de los ADRs, "architecture decision records", usados en ingeniería. "Export fechado" es una copia de un documento externo tomada en una fecha; "conexión viva" es cuando el agente va a buscar al sistema original cada vez.
✓ Una buena decisión en decisions/
- ✓Nombre fechado:
2026-09-13-docs-fora-do-git.md. - ✓Estado explícito: propuesta, aceptada o revocada.
- ✓Contexto, decisión y consecuencias en tres bloques cortos.
- ✓Nunca se borra: si cambia, una nueva decisión la revoca.
✗ Lo que no funciona
- ✗Decisión enterrada en medio de un chat de 300 turnos.
- ✗Editar la decisión antigua en el mismo lugar: se pierde el historial de por qué cambió.
- ✗Sin estado: el agente no sabe si todavía vale o si es solo una idea.
- ✗Fuente sin fecha: imposible saber si envejeció.
Conceptos clave
Tabla de procedencia con regla de refresh.
Una decisión fechada por archivo, con estado.
El conflicto se resuelve por la fuente, no por la fecha mayor.
El historial de decisiones es parte del contexto.
🎯 tasks/current.md: dueño y criterio de terminado
El texto original observa que mucha gente habla de memoria y de handoff, pero se olvida del trabajo actual. El tasks/current.md es eso: qué estamos haciendo ahora, quién es responsable y cuál es el criterio de terminado. Hace que el agente entienda no solo el historial, sino lo que tiene que pasar en esta sesión. Y es el archivo que la pregunta 1 del readback ("¿cuál es el objetivo y el criterio de aceptación?") va a buscar.
Este es el tasks/current.md real del kit, el día en que se escribió este curso. Fíjate en que cada línea responde a una pregunta que un agente nuevo haría:
# Tarea actual
- Objetivo: validar el piloto — skill `session-handoff` portada a Codex
vía polyskill y readback pasando en los dos runtimes.
- Dueño: Nei (decide piloto y skills); el agente ejecuta.
- Criterio de terminado: `scripts/readback-test.sh . both` genera respuestas que
citan AGENTS.md/tasks/handoffs en ambos; `scripts/sync-skills.sh drift`
sin DRIFT.
- Próxima acción concreta: Fase 0 del plan en
`~/projetos/wifi/DIAGNOSTICO-CLAUDE-CODEX-2026-09-14.md` —
`scripts/adapt-instructions.sh ~/.claude`, revisar, guardar
`~/.codex/AGENTS.md`, readback en `~/projetos/wifi`.
- Bloqueos: ninguno (publicación ya hecha; docs/ sigue fuera del git).
¿Nuevo aquí? "Criterio de terminado" (o criterio de aceptación) es la frase que permite decir, sin discusión, si la tarea se acabó. Un buen criterio es verificable: "el comando X genera la salida Y". Un mal criterio es opinión: "está bien". "Dueño" es quien decide; el agente ejecuta, pero no cambia el objetivo por su cuenta. "Próxima acción concreta" es el primer comando o edición, no una intención.
El humano define
Objetivo, dueño y criterio de terminado los escribe quien manda en el proyecto. El agente puede proponer, no decidir.
El agente marca
Durante la sesión, el agente actualiza "próxima acción" y "bloqueos" a medida que avanza, y registra lo que ejecutó.
Terminado solo con evidencia
La tarea se cierra cuando el criterio se ejecutó y el resultado está en el handoff. "Debería funcionar" no cierra nada.
Conceptos clave
El trabajo de ahora, no el historial.
Quien decide objetivo y criterio.
Verificable por comando, no por opinión.
El primer comando, con ruta.
🔁 handoffs/latest.md: la continuación
El handoff es el archivo que cierra una sesión y abre la siguiente. El texto original describe el flujo: sesión → /handoff → Markdown → /prime → nueva sesión. El comando de handoff analiza la sesión buscando decisiones tomadas, tareas inconclusas, próximos pasos y rutas de archivo, y guarda todo en Markdown. Un archivo llamado latest.md apunta siempre al más reciente. El /prime lee ese contexto de vuelta. Así no tienes que buscar información en archivos JSONL, y el resumen viaja a cualquier proveedor.
Lee de izquierda a derecha: la sesión nueva abre el AGENTS.md, que manda leer los cuatro siguientes en orden, y llega al handoff, destacado, desde donde continúa. La flecha punteada de vuelta es el ciclo: al cerrar, se escribe un handoff nuevo.
📝 Las siete secciones de la plantilla de handoff del kit
lo que cubrió esta sesión
apunta a tasks/current.md
lo que está confirmado, con commit
rutas, no descripciones vagas
pasó / falló / no ejecutado
lo que solo el dueño decide
el comando que la próxima sesión ejecuta primero
💡 Consejo práctico
Un buen handoff preserva las fallas no resueltas y no afirma que los cambios sin commit "están disponibles" en otro lugar. Cuando Claude hizo el readback del propio kit, señaló exactamente eso: el handoff decía "commit inicial" mientras seis archivos estaban editados sin commit. Se corrigió el handoff, no la regla.
Conceptos clave
Siempre el más reciente; la próxima sesión empieza aquí.
Escribir al cerrar, leer al abrir.
Claude escribe, Codex retoma, y viceversa.
El resumen estructurado reemplaza la relectura del log en bruto.
🧩 .agents/skills/, scripts/ y la regla de la convención
Las dos últimas carpetas guardan capacidad, no conocimiento. .agents/skills/ es donde viven las skills canónicas del proyecto (Codex ya busca ahí; Claude recibe una copia generada). scripts/ guarda comandos reproducibles, como el check.sh que verifica si los archivos obligatorios existen y no están vacíos. Y aquí viene el aviso más importante del módulo, directo del Prompt B: esos nombres son convenciones; dile explícitamente a cada agente qué leer. No des por hecho que los cargan solos.
¿Nuevo aquí? "Auto-load" (carga automática) es cuando el runtime lee un archivo sin que nadie lo pida. Claude Code lo hace con CLAUDE.md; Codex, con AGENTS.md. Nada más. Una carpeta llamada context/ es bonita, pero ningún agente la abre por su cuenta. "Convención" es un nombre acordado entre humanos; se convierte en comportamiento solo cuando el AGENTS.md manda leerla.
✓ Se carga solo
- ✓
CLAUDE.mden Claude Code (global y del proyecto). - ✓
AGENTS.mden Codex (y en Gemini). - ✓Skills en
~/.claude/skills,~/.codex/skills,.agents/skills/: descubiertas por nombre.
✗ No se carga solo
- ✗
context/,tasks/,handoffs/: solo si el AGENTS.md manda leerlas. - ✗
README.md: el agente puede ni siquiera abrirlo. - ✗Cualquier carpeta bonita tipo
brain/,knowledge/,memory/sin instrucción explícita.
⚠️ El error a evitar
Armar el árbol completo, sentirse orgulloso de la estructura y nunca probar si el agente lo usa. El Prompt B es explícito: un directorio generado no es prueba de que un agente lo lea. La prueba es el readback (módulo 2.5): sesión nueva, cinco preguntas, y las respuestas citando AGENTS.md, tasks/current.md y handoffs/latest.md.
🔬 Cómo lo resuelve el kit
- •El
AGENTS.mdde la plantilla abre con la frase: "Orden de lectura para cualquier agente: 1) este archivo, 2) context/overview.md, 3) context/current-state.md, 4) tasks/current.md, 5) handoffs/latest.md. Estos nombres son convención de este repo, no se cargan automáticamente: léelos." - •El
scripts/check.shverifica que los siete archivos obligatorios existan y no estén vacíos:[ok]o[FALTA]. - •El
readback-test.shprueba que el agente leyó, y no solo que el archivo existe.
Conceptos clave
Skills canónicas del proyecto; Codex ya busca aquí.
Verificación mínima: los archivos existen y no están vacíos.
Nombre acordado; se vuelve comportamiento solo por instrucción.
Solo CLAUDE.md y AGENTS.md. El resto, el AGENTS.md manda leerlo.
Autoevaluación (opcional): creaste context/overview.md y tasks/current.md en un proyecto. ¿Codex los va a leer al iniciar?
🎯 Resumen del módulo
Próximo módulo:
1.5 — Dueños de la información: hecho, preferencia, hipótesis, decisión