PROYECTO 3.1

🚀 Proyecto 1: migrar tu primer proyecto real

Hasta aquí entendiste la filosofía (Ruta 1) y practicaste cada script por separado (Ruta 2). Ahora toca la Fase 0 y la Fase 2 del plan de verdad: darle a Codex una base global, elegir un proyecto que Codex hoy abre "a ciegas", hacer la limpieza del CLAUDE.md, ejecutar los cinco scripts en orden y comprobarlo con readback en los dos runtimes. Al final, un handoff que cualquiera de los dos puede retomar.

6
Temas
~40
Minutos
Intermedio
Nivel
Proyecto
Tipo

🎯 El proyecto en una pantalla

ObjetivoUn proyecto real tuyo pasa a ser leído por igual por Claude Code y por Codex CLI, y Codex gana una base global de instrucciones.
Terminas con~/.codex/AGENTS.md, un proyecto con AGENTS.md compacto + context/ + tasks/ + handoffs/, dos informes de readback y un handoff.
Criterio de aceptaciónUna sesión nueva en cada runtime responde las 5 preguntas citando AGENTS.md, tasks/current.md y handoffs/latest.md. La configuración de Claude sigue funcionando.
1

🎯 Elegir el piloto

El diagnóstico del 2026-09-14 encontró 13 proyectos marcados como trusted en Codex que no tienen AGENTS.md. Eso significa que Codex entra en ellos sin ninguna instrucción: cada sesión empieza desde cero. Son los candidatos naturales a piloto, porque la ganancia es inmediata y medible. Aquí aplica la regla del Prompt B: el piloto más pequeño que conserve una tarea representativa. No empieces por el más grande; empieza por el que más usas.

Fase 0 · base global ~/.codex/AGENTS.md + MCP Fase 1 · skill piloto session-handoff (Ruta 2) Fase 2 · 13 proyectos trusted sin AGENTS.md Fases 3–6 próximos proyectos ESTE PROYECTO ESTE PROYECTO

Léela como una escalera: los peldaños con brillo son los que sube este proyecto. La Fase 0 le da a Codex una base global; la Fase 2 aplica el núcleo portátil a uno de los 13 proyectos que hoy abre sin instrucciones. La Fase 1 (skill piloto) ya la hiciste en la Ruta 2.

📊 Los 13 candidatos, por orden de uso

Orden sugerido por el diagnóstico, del más usado al menos usado. Cuantas más sesiones recibe el proyecto, antes se amortiza el AGENTS.md.

wifi portal inemapro-mono timesmkt2 timesmkt3 inemacert promoavatar2 skool-roast imkt4 iccmonit ATIA claude-session-kit agentes-fronteiros

✓ Un buen piloto

  • Lo abres cada semana, en los dos runtimes.
  • Tiene un CLAUDE.md que ya dice algo útil (reglas, rutas, autor de commit).
  • Tiene una tarea representativa clara: "publicar en el portal", "ejecutar el backup", "generar el informe".
  • Working tree limpia en el momento de empezar.

✗ Un mal piloto

  • El CLAUDE.md más grande de la máquina (ruflo, 1.391 líneas) solo porque "es el más completo".
  • Un proyecto que otra sesión está editando ahora (las ediciones se pisan, ya pasó en el portal).
  • Un proyecto de cliente mezclado con conocimiento personal (eso es el Proyecto 5).
  • Un proyecto que nadie abre hace meses: sin uso, sin evidencia.

Sugerencia concreta: empieza por wifi. Es el hub de monitoreo, tiene su propio CLAUDE.md, recibe sesiones casi todos los días y ya guarda el diagnóstico de este curso. Si prefieres algo más pequeño y aislado, skool-roast o iccmonit.

Conceptos clave

Trusted sin AGENTS.md

Codex confía en la carpeta pero no recibe ninguna instrucción de ella.

Piloto mínimo

El que preserva una tarea real con el mínimo de archivos.

Tarea representativa

El flujo que tiene que seguir funcionando después de la migración.

Un dueño por repo

Dos sesiones en el mismo repo corrompen la working tree.

2

🌐 Base global: ~/.codex/AGENTS.md

Esta es la Fase 0. Claude tiene un ~/.claude/CLAUDE.md global de 72 líneas con reglas que valen para todos los proyectos: cuenta de autor por repo, dónde están las API keys, versionado, modelo de imagen por defecto. Codex no tiene nada equivalente: el archivo ~/.codex/AGENTS.md no existe. Derivar uno del otro es el paso más barato de toda la migración, y es lo que hace que Codex deje de ignorar reglas que consideras obvias.

1

Generar las propuestas

El script lee el CLAUDE.md global y separa lo portátil del residuo de Claude, sin tocar el original.

2

Revisar los dos archivos

Lees AGENTS.proposto.md y CLAUDE.proposto.md. Nada entra sin que lo revises tú.

3

Grabar en Codex y activar el import en Claude

Lo portátil se convierte en ~/.codex/AGENTS.md. El CLAUDE.md global pasa a empezar con @AGENTS.md apuntando a una copia local.

Objetivo: crear el ~/.codex/AGENTS.md a partir del CLAUDE.md global, con revisión humana en medio.

# 1. generar las propuestas (no sobrescribe nada)
cd ~/projetos/agente-claude-codex
scripts/adapt-instructions.sh ~/.claude
# salida esperada: ~/.claude/AGENTS.proposto.md (71 líneas) y ~/.claude/CLAUDE.proposto.md (7 líneas)

# 2. revisar (abre los dos, corrige lo que el grep hizo mal)
less ~/.claude/AGENTS.proposto.md
less ~/.claude/CLAUDE.proposto.md

# 3. grabar: lo portátil va a Codex Y queda junto al CLAUDE.md para ser importado
cp ~/.claude/AGENTS.proposto.md ~/.codex/AGENTS.md
cp ~/.claude/AGENTS.proposto.md ~/.claude/AGENTS.md
cp ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak-$(date +%Y%m%d)   # backup antes de reemplazar
cp ~/.claude/CLAUDE.proposto.md ~/.claude/CLAUDE.md
rm ~/.claude/*.proposto.md

Cómo verificar: head -1 ~/.claude/CLAUDE.md muestra @AGENTS.md; wc -l ~/.codex/AGENTS.md da alrededor de 71.

⚠️ La trampa del rename

El script cambia toda mención a CLAUDE.md por AGENTS.md en la parte portátil. Tu CLAUDE.md global habla de otros proyectos ("ver el CLAUDE.md de él", "cada proyecto puede tener su propio CLAUDE.md"). Esas frases también se renombran, y el sentido cambia. En la revisión del paso 2, busca AGENTS.md dele y devuelve el nombre correcto donde sea referencia a otro proyecto.

Prueba de 30 segundos: después de guardar, ejecuta codex exec "¿Qué cuenta de autor debo usar en un commit para un repo de la cuenta inematds? Cita la fuente." desde ~. Si responde inematds <inematds@gmail.com> citando el AGENTS.md, la Fase 0 pasó.

Conceptos clave

Instrucción global

Reglas que valen en cualquier carpeta: autor, keys, versionado.

@AGENTS.md

Claude importa lo portátil; el residuo queda solo en el CLAUDE.md.

.proposto.md

Salida del script que espera revisión; nunca se aplica sola.

Backup fechado

Antes de reemplazar el original, una copia con la fecha en el nombre.

3

🧹 Limpieza: un CLAUDE.md inflado se convierte en AGENTS.md compacto + context/

La newsletter insiste: la mayor parte de la migración es limpieza. El diagnóstico encontró CLAUDE.md de 1.391 líneas (ruflo), 542 (rAgentic-cs), 427 (timesmkt2), 401 (ruview). Un archivo de ese tamaño no es instrucción, es un depósito: reglas mezcladas con historial, decisiones antiguas, runbooks y "lessons" que ya se volvieron código. Migrar eso en crudo solo transporta ruido a Codex. La regla es: AGENTS.md tiene solo instrucción estable; el resto va al lugar que tiene dueño.

CLAUDE.md 1.391 líneas AGENTS.md · ~60 líneas context/overview.md context/decisions/ context/sources.md CLAUDE.md (residuo) @AGENTS.md + 5 líneas

El archivo inflado de la izquierda se abre en abanico: las reglas estables quedan en el AGENTS.md compacto; hechos, decisiones y runbooks van a context/, cada uno con dueño. El CLAUDE.md queda pequeño, importando el AGENTS.md.

✓ Se queda en el AGENTS.md

  • Orden de lectura (AGENTS → context/overview → tasks/current → handoffs/latest).
  • Reglas de git: remote, autor, "publicar = push".
  • Cómo ejecutar, probar y reiniciar (3 a 5 comandos).
  • Prohibiciones estrictas: "nunca generar medios pagos sin confirmar".

✗ Sale del AGENTS.md (y va a…)

  • Historial de fases y qué se hizo cuándo → context/current-state.md y CHANGELOG.
  • "Lessons" y correcciones puntuales → FALHAS.md (una línea por falla).
  • Decisiones de arquitectura con contexto → context/decisions/AAAA-MM-DD-*.md.
  • Runbooks largos, URLs, de dónde vienen las credenciales → context/sources.md.

Objetivo: medir el CLAUDE.md del piloto y separar lo que es instrucción de lo que es depósito, antes de ejecutar el adaptador.

P=~/projetos/<seu-piloto>
wc -l $P/CLAUDE.md
# encabezados: el mapa de lo que hay adentro
grep -nE '^#{1,3} ' $P/CLAUDE.md
# candidatos a salir: historial, lessons, decisiones, fechas
grep -cniE 'lesson|corrigido em|decidi|fase [0-9]|20[0-9]{2}-[0-9]{2}' $P/CLAUDE.md

Cómo verificar: si el segundo grep devuelve decenas de líneas, tienes un depósito. Meta después de la limpieza: AGENTS.md por debajo de 100 líneas, y cada sección eliminada con un destino nombrado en context/.

No borres, mueve. La limpieza no es eliminar. Es sacar del archivo que todo agente lee al arrancar y ponerlo en el archivo que el agente lee solo cuando lo necesita. El contenido sigue en el repo, versionado; solo cambia de capa.

Conceptos clave

Depósito vs instrucción

Instrucción es lo que cambia el comportamiento hoy; depósito es lo que explica el pasado.

Briefing de arranque

Lo que el agente lee siempre tiene que ser corto; el resto se recupera bajo demanda.

Destino nombrado

Toda sección eliminada recibe un archivo con dueño en context/.

Mover, no borrar

La limpieza es un cambio de capa, no una pérdida de información.

4

🛠️ Los cinco scripts en orden

En la Trilha 2 ejecutaste cada script por separado. Aquí se ejecutan en secuencia sobre el piloto, y el orden importa: primero el diagnóstico (solo lectura), después las instrucciones, luego el núcleo, después las skills y la prueba al final. Cada paso es reversible: nada en ~/.claude se borra, el adaptador guarda .proposto.md, el núcleo no sobrescribe y el install hace un backup al lado.

1

doctor.sh + audit.sh

Confirma que los dos runtimes están listos y genera el informe de inventario. Si ya lo ejecutaste hoy, sáltalo.

2

adapt-instructions.sh en el piloto

Genera los .proposto.md del proyecto. Aplicas la limpieza del tema 3 en la revisión y renombras.

3

init-core.sh

Copia la plantilla sin sobrescribir. Completa context/overview.md y tasks/current.md con la tarea representativa.

4

sync-skills.sh (solo si el piloto usa una skill propia)

La mayoría de los proyectos usa skills globales. Si el piloto tiene .claude/skills/ local, impórtala e instálala en ambos.

5

readback-test.sh

La prueba. Tema 5.

Objetivo: aplicar el kit completo en el piloto, en una sesión, sin sobrescribir nada.

K=~/projetos/agente-claude-codex
P=~/projetos/<seu-piloto>
cd $K

# 1. diagnóstico (solo lectura)
scripts/doctor.sh && scripts/audit.sh

# 2. instrucciones: genera *.proposto.md junto al CLAUDE.md del piloto
scripts/adapt-instructions.sh $P
#    ... revisar + limpieza (tema 3) ...
mv $P/AGENTS.proposto.md $P/AGENTS.md
cp $P/CLAUDE.md $P/CLAUDE.md.bak-$(date +%Y%m%d) && mv $P/CLAUDE.proposto.md $P/CLAUDE.md

# 3. núcleo portátil (lista [criado] y [mantido])
scripts/init-core.sh $P
#    completar: $P/context/overview.md, $P/tasks/current.md

# 4. solo si hay una skill local en el piloto
ls $P/.claude/skills 2>/dev/null

# 5. verificación mínima del núcleo
bash $P/scripts/check.sh

Cómo verificar: check.sh imprime [ok] para los 7 archivos obligatorios. head -1 $P/CLAUDE.md muestra @AGENTS.md. El .bak existe.

📋 Qué completar en tasks/current.md

  • Objetivo: la tarea representativa, en una frase. Ej.: "publicar el ítem X en el portal".
  • Responsable: tú. El agente ejecuta.
  • Criterio de terminado: algo verificable. "El push entró en origin" es verificable; "quedó bien" no lo es.
  • Próxima acción concreta: el primer comando o archivo a tocar.

Conceptos clave

El orden importa

Diagnóstico → instrucciones → núcleo → skills → prueba.

Reversible

Cada paso deja el original o un backup al lado.

[criado] / [mantido]

El init-core dice lo que hizo; nunca sobrescribe.

check.sh

Siete archivos obligatorios, no vacíos. Es el mínimo, no la prueba.

5

✅ Readback en los dos runtimes

Que el archivo exista no es prueba. La prueba es una sesión nueva, en cada runtime, respondiendo cinco preguntas sin depender de una conversación anterior: cuál es el objetivo y el criterio de terminado, una regla importante con su archivo de origen, la última decisión aceptada, la próxima acción concreta, y conflictos o accesos faltantes. El script ejecuta claude -p y codex exec dentro del piloto y guarda el texto en bruto. El veredicto es tuyo, leyendo.

Objetivo: obtener las dos respuestas y juzgar si citan los archivos correctos.

cd ~/projetos/agente-claude-codex
scripts/readback-test.sh ~/projetos/<seu-piloto> both
# guarda: relatorios/readback-claude-AAAA-MM-DD.md y readback-codex-AAAA-MM-DD.md

# qué buscar en las respuestas
grep -cE 'AGENTS.md|tasks/current|handoffs/latest|context/' relatorios/readback-*-$(date +%F).md

Cómo verificar: las dos respuestas citan AGENTS.md, tasks/current.md y handoffs/latest.md, y la "próxima acción" coincide con lo que escribiste en tasks/current.md. Si un runtime responde de memoria genérica sin citar ningún archivo, falló.

✓ Respuesta que pasa

  • "Objetivo: publicar X. Criterio: push en origin. Fuente: tasks/current.md."
  • "Regla: autor inematds. Fuente exacta: AGENTS.md, sección Git."
  • Separa lo que dicen los archivos de lo que él infiere.
  • Señala una inconsistencia real entre dos archivos, si la hay.

✗ Respuesta que falla

  • "El objetivo parece ser mejorar el proyecto" (sin fuente).
  • Cita el CLAUDE.md antiguo en lugar del AGENTS.md (el import no funcionó).
  • "No pude leer los archivos" (sandbox: ver abajo).
  • Inventa una "última decisión" que no está en context/decisions/.

⚠️ La falla real que ya ocurrió

En la primera ronda del readback en el propio kit, Codex respondió "no pude leer los archivos: bwrap: loopback: Failed RTM_NEWADDR". El script forzaba -s read-only, y en esta máquina AppArmor restringe los user namespaces, así que el sandbox bwrap de Codex no arranca. La corrección mínima: quitar el flag y respetar el sandbox_mode de ~/.codex/config.toml. Está registrado en FALHAS.md como prompt | infra. Si ves ese error, el problema es el sandbox, no tu AGENTS.md.

Aprovecha lo que devuelve el readback. En la segunda ronda, Codex leyó todo y señaló tres inconsistencias reales en el kit: handoff ausente, una suma errónea en el informe y una frase contradictoria. Un buen readback no solo pasa: audita. Corrige lo que encuentre antes de darlo por terminado.

Conceptos clave

Sesión nueva

Sin historial de conversación; solo lo que está en los archivos.

Citar la fuente

Una respuesta sin ruta de archivo no cuenta como evidencia.

Sandbox vs contenido

"No lo leí" puede ser infra; distínguelo antes de tocar los archivos.

El readback audita

Las inconsistencias que señala son trabajo para ti, no ruido.

6

🏁 Aceptación, handoff, riesgos y rollback

El proyecto termina cuando los criterios de aceptación están marcados con evidencia, no cuando "parece listo". Y termina con un handoff: el próximo agente, en cualquier runtime, necesita saber qué se hizo, qué se verificó y cuál es la próxima acción exacta. Sin eso, la semana que viene empieza de cero otra vez y vuelves a depender de los JSONL.

Criterios de aceptación (márcalos con evidencia)

  • ~/.codex/AGENTS.md existe y codex exec en ~ cita la regla de autor. Evidencia: salida del comando.
  • El piloto tiene AGENTS.md con menos de 100 líneas, CLAUDE.md que empieza con @AGENTS.md, y context/, tasks/, handoffs/ completos. Evidencia: check.sh.
  • El readback pasó en los dos runtimes. Evidencia: los dos archivos en relatorios/.
  • La tarea representativa sigue funcionando en Claude. Evidencia: se ejecutó una vez después de la migración.
  • Todo commiteado y en origin. Evidencia: git status -sb limpio.

Objetivo: cerrar con handoff y commit, en un solo bloque.

P=~/projetos/<seu-piloto>
cd $P
# handoff: completa las secciones de la plantilla (qué cambió, checks ejecutados y resultado, próxima acción exacta)
$EDITOR handoffs/latest.md
# el piloto ahora usa el núcleo: registra en tasks/current.md que la aceptación pasó
$EDITOR tasks/current.md

git add AGENTS.md CLAUDE.md context tasks handoffs scripts
git -c user.name=inematds -c user.email=inematds@gmail.com commit -m "workspace portátil: AGENTS.md + núcleo (context/tasks/handoffs); readback aprobado en Claude y Codex"
git push
git status -sb | head -1   # esperado: ## main...origin/main

Cómo verificar: abre mañana una sesión nueva en Codex dentro del piloto y pide "lee handoffs/latest.md y dime la próxima acción". Si responde la misma frase que escribiste, el ciclo se cerró.

⚠️ Riesgos de este proyecto

  • Renombrado a ciegas de referencias a CLAUDE.md de otros proyectos (tema 2).
  • Limpieza que borra en lugar de mover (tema 3).
  • Otra sesión editando el mismo repo durante la migración.
  • Cada readback en Codex consume cuota de OpenAI; ejecútalo por proyecto, no en bucle.

↩️ Rollback en un comando

  • CLAUDE.md del piloto: mv CLAUDE.md.bak-AAAAMMDD CLAUDE.md.
  • CLAUDE.md global: mismo patrón en ~/.claude/.
  • Base de Codex: rm ~/.codex/AGENTS.md vuelve al estado anterior (nada).
  • Núcleo: git checkout -- . antes del commit, o git revert después.

Conceptos clave

Aceptación con evidencia

Cada criterio apunta a un archivo o a la salida de un comando.

Handoff

El resumen estructurado que cualquier runtime retoma.

Publicar = push

El trabajo termina cuando entra en origin.

Rollback definido

Antes de empezar, ya sabes cómo deshacer cada paso.

Autoevaluación (opcional): el readback de Codex respondió "no pude leer los archivos: bwrap RTM_NEWADDR". ¿Qué haces primero?

🎯 Resumen del proyecto

Piloto pequeño y en uso — uno de los 13 trusted sin AGENTS.md, con una tarea representativa clara.
Fase 0~/.codex/AGENTS.md derivado del CLAUDE.md global, con revisión y respaldo.
Limpieza — instrucción estable en AGENTS.md; hechos, decisiones y runbooks en context/, movidos y no borrados.
Prueba y handoff — readback en los dos runtimes con fuente citada, aceptación con evidencia, push al origin.

Próximo proyecto:

3.2 — MCP y hooks entre Claude y Codex: las herramientas viajan, los eventos no