MÓDULO 1.4

📁 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.

6
Temas
~30
Minutos
Básico
Nivel
Teoría
Tipo
1

📄 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
meu-projeto/ README.md para personas AGENTS.md para agentes · orden de lectura CLAUDE.md @AGENTS.md + residuo context/overview · state · sources · decisions tasks/current.md handoffs/latest.md .agents/skills/skills canónicas scripts/check.sh todo dentro del proyecto · Markdown común · nada depende de un plugin

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

README.md

Onboarding humano. Explica.

AGENTS.md

Instrucciones concisas para agentes. Ordena.

Orden de lectura

Lista explícita al inicio del AGENTS.md.

@AGENTS.md

Primera línea del CLAUDE.md: importa lo portátil.

2

🧭 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

overview.md

"¿Qué es esto?" Estable, con hechos fechados.

current-state.md

"¿Cómo está ahora?" Cambia en cada sesión.

Hecho verificado

Tiene fuente y fecha. Sin eso es hipótesis.

Encabezado de nota

ID, alcance, fuente, fecha, estado, revisar en.

3

🔗 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

IDFuenteTipoFechaAlcanceRefresh
S1docs/migrar-claude-para-codex...mdexport local2026-09-13filosofíamanual
S3docs/mega-prompts.pdfexport local2026-09-13prompts A/Bmanual
S4relatorios/auditoria-*.mdgenerado por scriptcada rondamáquina localejecutar script
S5wifi/DIAGNOSTICO-CLAUDE-CODEX...mddiagnóstico2026-09-14máquina localejecutar 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

sources.md

Tabla de procedencia con regla de refresh.

decisions/

Una decisión fechada por archivo, con estado.

La procedencia vence al timestamp

El conflicto se resuelve por la fuente, no por la fecha mayor.

Revocar, no borrar

El historial de decisiones es parte del contexto.

4

🎯 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.

1

El humano define

Objetivo, dueño y criterio de terminado los escribe quien manda en el proyecto. El agente puede proponer, no decidir.

2

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ó.

3

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

tasks/current.md

El trabajo de ahora, no el historial.

Dueño

Quien decide objetivo y criterio.

Criterio de terminado

Verificable por comando, no por opinión.

Próxima acción concreta

El primer comando, con ruta.

5

🔁 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.

1 · AGENTS.md reglas + orden 2 · overview.md qué es 3 · current-state cómo está 4 · tasks/current qué hacer 5 · handoffs/latest desde dónde continuar fin de la sesión: nuevo handoff → la próxima sesión vuelve a empezar por el AGENTS.md

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

Proyecto y alcance
lo que cubrió esta sesión
Objetivo actual
apunta a tasks/current.md
Estado aceptado
lo que está confirmado, con commit
Archivos modificados
rutas, no descripciones vagas
Checks ejecutados y resultado
pasó / falló / no ejecutado
Preguntas abiertas
lo que solo el dueño decide
Próxima acción exacta
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

handoffs/latest.md

Siempre el más reciente; la próxima sesión empieza aquí.

/handoff y /prime

Escribir al cerrar, leer al abrir.

Viaja entre proveedores

Claude escribe, Codex retoma, y viceversa.

Sin JSONL

El resumen estructurado reemplaza la relectura del log en bruto.

6

🧩 .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.md en Claude Code (global y del proyecto).
  • AGENTS.md en 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.md de 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.sh verifica que los siete archivos obligatorios existan y no estén vacíos: [ok] o [FALTA].
  • El readback-test.sh prueba que el agente leyó, y no solo que el archivo existe.

Conceptos clave

.agents/skills/

Skills canónicas del proyecto; Codex ya busca aquí.

scripts/check.sh

Verificación mínima: los archivos existen y no están vacíos.

Convención

Nombre acordado; se vuelve comportamiento solo por instrucción.

Auto-load

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

README vs AGENTS.md — uno explica para personas, el otro ordena para agentes, con el orden de lectura al inicio.
context/ — overview (qué es, con hechos fechados), current-state (cómo está), sources (de dónde vino) y decisions (qué se decidió, nunca se borra).
tasks/current.md — objetivo, dueño, criterio de terminado verificable y próxima acción concreta.
handoffs/latest.md — cierra la sesión y abre la siguiente en cualquier proveedor.
Convención no es auto-load — solo CLAUDE.md y AGENTS.md se cargan solos; el resto el AGENTS.md manda leerlo, y el readback lo prueba.

Próximo módulo:

1.5 — Dueños de la información: hecho, preferencia, hipótesis, decisión