How to share context across Claude Code, Codex, Cursor and OpenCode

Using four agents does not require maintaining four versions of the truth. The problem starts when each tool receives a different prompt, stores decisions in a different place and leaves incompatible evidence.

The answer is not copying everything everywhere. It is separating layers with clear owners.

The four layers

1. Repository rules

Architecture, commands, security limits and the definition of “done”. They should live close to the code and travel with the repository.

An AGENTS.md file at the root sets the common contract. Deeper files refine instructions for a folder without duplicating the whole document.

2. Reusable team judgment

A rule explains what to respect. A skill explains how to execute a class of task well: what to read, which steps to follow, which errors to avoid and how to verify.

That judgment belongs to the team. It is reviewed in pull requests and versioned in git.

3. Personal memory

Developer preferences, communication habits or context that crosses repositories. This layer stays local on the developer's machine and should not end up in the team's git history.

Confusing personal memory with shared knowledge creates two risks: leaking private information or hiding critical decisions on one computer.

4. Execution evidence

Tests, builds, screenshots, logs and the task result contract. This layer makes it possible to review whether two agents actually applied the same standard.

A minimal topology

local personal memory
        │
        ▼
AGENTS.md ── shared rules
        │
        ├── skills/ ── versioned team judgment
        │
        └── verify ── evidence for every run
             ▲
             │
 Claude Code · Codex · Cursor · OpenCode

Each tool keeps its interface and model. The repository keeps authority.

Avoid copy-based synchronization

Manually copying rules into tool-specific files looks fast. Then a command, path or restriction changes and four incompatible contracts appear.

Use one canonical document and generate adapters only when a tool needs one. The adapter should stay small and make its source explicit.

Route before loading

Sharing context does not mean injecting the entire repository into every prompt. It means locating the relevant subgraph first:

1. classify the task: UI, API, domain, release or diagnosis;
2. query the file and dependency map;
3. load the nearby rules;
4. activate the skills that cover different axes;
5. drop to exact lines only when needed.

That routing reduces noise and prevents a frontend guide from contaminating a data migration.

Define who can change what

A shared architecture needs governance:

• each developer controls personal memory;
• the team reviews project rules;
• skills have an owner and a version;
• verify is not skipped for convenience;
• secrets never enter a versioned layer.

An agent can propose a new rule. It should not turn an inference into team policy without review.

Compatibility test

The check is not “all four tools open the repo”. Use one small but demanding task:

1. ask each agent to identify the same rule;
2. require the same verification path;
3. compare opened files, decision and result;
4. record any tool-specific adapter;
5. fix the shared source, not four prompts.

Limit

Products change their instruction formats. This architecture avoids depending on only one, but it still needs adapters maintained and tested against real versions.

Portability does not mean identical behavior. It means everyone starts from the same standard and leaves comparable evidence.

Usar cuatro agentes no obliga a mantener cuatro versiones de la verdad. El problema empieza cuando cada herramienta recibe un prompt distinto, guarda sus decisiones en un lugar distinto y deja evidencia incompatible.

La salida no es copiar todo a todas partes. Es separar capas con propietarios claros.

Las cuatro capas

1. Reglas del repositorio

Arquitectura, comandos, límites de seguridad y definición de “terminado”. Deben vivir cerca del código y viajar con el repositorio.

Un archivo AGENTS.md en la raíz fija el contrato común. Los archivos más profundos afinan instrucciones para una carpeta sin duplicar el documento entero.

2. Criterio reutilizable del equipo

Una regla explica qué respetar. Una skill explica cómo ejecutar bien una clase de tarea: qué leer, qué pasos seguir, qué errores evitar y cómo verificar.

Ese criterio sí pertenece al equipo. Se revisa en pull request y se versiona en git.

3. Memoria personal

Preferencias del desarrollador, hábitos de comunicación o contexto que atraviesa repositorios. Esa capa vive local en su máquina y no debe terminar en el git del equipo.

Confundir memoria personal con conocimiento compartido produce dos riesgos: filtrar información privada o esconder decisiones críticas en una computadora.

4. Evidencia de ejecución

Tests, builds, capturas, logs y el contrato de resultado de la tarea. Es la capa que permite revisar si dos agentes aplicaron realmente el mismo criterio.

Una topología mínima

<pre class="astro-code github-dark" style="background-color:#24292e;color:#e1e4e8; overflow-x: auto;" tabindex="0" data-language="text"><code><span class="line"><span>memoria personal local</span></span> <span class="line"><span> │</span></span> <span class="line"><span> ▼</span></span> <span class="line"><span>AGENTS.md ── reglas comunes</span></span> <span class="line"><span> │</span></span> <span class="line"><span> ├── skills/ ── criterio del equipo versionado</span></span> <span class="line"><span> │</span></span> <span class="line"><span> └── verify ── evidencia de cada ejecución</span></span> <span class="line"><span> ▲</span></span> <span class="line"><span> │</span></span> <span class="line"><span> Claude Code · Codex · Cursor · OpenCode</span></span></code></pre>

Cada herramienta conserva su interfaz y su modelo. El repositorio conserva la autoridad.

Evita la sincronización por copia

Copiar manualmente reglas entre archivos específicos de herramientas parece rápido. Luego cambia un comando, una ruta o una restricción y aparecen cuatro contratos incompatibles.

Usa un documento canónico y genera adaptadores solo cuando una herramienta lo necesite. El adaptador debe ser pequeño y dejar claro cuál es la fuente.

Enruta antes de cargar

Compartir contexto no significa inyectar todo el repositorio en cada prompt. Significa localizar primero el subgrafo relevante:

1. clasifica la tarea: UI, API, dominio, release o diagnóstico;
2. consulta el mapa de archivos y dependencias;
3. carga las reglas cercanas;
4. activa las skills que cubren ejes distintos;
5. baja a líneas exactas solo cuando haga falta.

Ese routing reduce ruido y evita que una guía de frontend contamine una migración de datos.

Define quién puede cambiar qué

Una arquitectura compartida necesita gobernanza:

• la memoria personal la controla cada developer;
• las reglas del proyecto las revisa el equipo;
• las skills tienen dueño y versión;
• el verify no se omite por conveniencia;
• los secretos nunca entran en ninguna capa versionada.

El agente puede proponer una nueva regla. No debería convertir una inferencia en política del equipo sin revisión.

Prueba de compatibilidad

El chequeo no es “las cuatro herramientas abren el repo”. Usa una tarea pequeña y exigente:

1. pide a cada agente identificar la misma regla;
2. exige la misma ruta de verificación;
3. compara archivos abiertos, decisión y resultado;
4. registra cualquier adaptador específico;
5. corrige la fuente común, no cuatro prompts.

Límite

Los productos cambian sus formatos de instrucciones. Esta arquitectura evita depender de uno solo, pero necesita mantener adaptadores y probarlos contra versiones reales.

La portabilidad no significa comportamiento idéntico. Significa que todos parten del mismo criterio y dejan evidencia comparable.