Haz que Codex, Claude Code y Cursor trabajen como un solo equipo CLI

Codex, Claude Code y Cursor pueden editar repositorios, ejecutar comandos y seguir instrucciones de proyecto dentro de las capacidades y los permisos que tengan configurados. Este artículo pone a prueba un contrato operativo basado en archivos; no afirma que todos los equipos necesiten tres agentes ni que el contrato elimine el comportamiento propio de cada herramienta.

Este artículo muestra cómo hacerlo con archivos y CLIs que ya tienes:

• Instrucciones de proyecto compartidas en AGENTS.md
• Puente de Claude vía CLAUDE.md importando @AGENTS.md
• Instrucciones base de Cursor más .cursor/rules opcionales
• Markdown de transferencia tipado entre roles
• Ejecuciones CLI no interactivas para diseño, revisión e implementación

No se requiere aquí una plataforma de gestión de proyectos personalizada. Si más adelante quieres un backlog compartido entre agentes, combínalo con Gestión de proyectos multiagente con Linear. Aquí el medio de coordinación es git más markdown.

Documentación de producto verificada de nuevo el 2026-08-04 frente a AGENTS.md, la guía AGENTS.md de OpenAI Codex, el modo no interactivo de Codex, la documentación de memoria de Claude Code, la referencia CLI de Claude Code y la documentación CLI de Cursor. En esta revisión no se ejecutó de extremo a extremo la transferencia completa entre los tres clientes; valida los comandos y los permisos con versiones fijadas de los clientes antes de depender de este flujo de trabajo.

La forma del equipo

Una especialización inicial fiable:

Estos roles son convenciones, no limitaciones del proveedor. Cada herramienta puede diseñar, revisar o implementar. La especialización ayuda porque fuerza un límite de artefacto: un agente escribe un plan, otro lo ataca, un tercero implementa solo lo que sobrevivió a la revisión.

Instrucciones compartidas: una fuente de verdad

Usa AGENTS.md como línea base portable

AGENTS.md es el formato de instrucciones multiherramienta administrado bajo la Agentic AI Foundation. Codex lo lee de forma nativa. Cursor admite un AGENTS.md raíz como guía de proyecto compartida (junto a .cursor/rules). Mantenlo corto y operativo:

# AGENTS.md

## Commands
- Install: `pnpm install`
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`

## Patch rules
- One behavior change per branch
- Prefer existing helpers over new dependencies
- Do not edit secrets or `.env*` files
- Do not merge to main

## Multi-agent protocol
- Read `docs/handoffs/` before starting
- Write status back into the active handoff file
- Designer, reviewer, and implementer must be different runs
- Stop for auth, payments, production infra, or data deletion

La documentación de Codex de OpenAI describe el descubrimiento desde la raíz del proyecto hasta el directorio de trabajo, en el que los archivos más cercanos tienen precedencia, AGENTS.override.md opcional y un presupuesto de tamaño combinado predeterminado (32 KiB a menos que se eleve). Mantén el archivo raíz ajustado; pon reglas específicas de paquete en archivos AGENTS.md anidados.

Conecta Claude Code con CLAUDE.md

Claude Code lee CLAUDE.md, no AGENTS.md. La guía oficial es importar el archivo compartido:

@AGENTS.md

## Claude Code
- Prefer plan mode before edits on `src/billing/` and auth code
- For review jobs, do not implement unless the handoff status is `implement` or `fixes`

Un enlace simbólico (ln -s AGENTS.md CLAUDE.md) también funciona cuando no necesitas extras específicos de Claude. En Windows, prefiere la importación @AGENTS.md.

Confirma la carga con /context de Claude y revisa Memory files.

Mantén acotadas las reglas específicas de Cursor

Cursor puede usar AGENTS.md raíz para convenciones compartidas. Usa .cursor/rules/*.mdc solo para necesidades exclusivas de Cursor, como reglas con alcance glob. No mantengas tres enciclopedias divergentes.

El archivo de transferencia es la conversación entre compañeros de equipo

Crea un directorio:

mkdir -p docs/handoffs

Usa un archivo por unidad de trabajo:

docs/handoffs/2026-07-29-pricing-section.md

# Handoff: pricing section

- ID: pricing-section
- Status: design
- Owner now: codex
- Next owner: claude
- Branch: codex/design-pricing-section
- Worktree: ../app-pricing-section

## Goal
Implement the marketing pricing section using existing Section/PlanCard patterns.

## Non-goals
Billing, coupons, seat math.

## Design
(Codex fills this)

## Review
(Claude fills this)

## Implementation notes
(Cursor fills this)

## Verification
- Command: `pnpm test:e2e --grep "pricing"`
- Last result:

## Decision log
- 2026-07-29 Codex: drafted component boundaries

Valores de estado que funcionan bien (con bucles, no un avance en una sola dirección):

1. design
2. design-review — hallazgos bloqueantes vuelven a design; revisión limpia avanza a implement
3. implement
4. impl-review — hallazgos bloqueantes van a fixes; revisión limpia establece done
5. fixes — el implementador resuelve hallazgos, luego vuelve a impl-review
6. done
7. blocked-human

No todas las tareas pasan por fixes. Un impl-review limpio puede ir directo a done.

Cada ejecución CLI empieza leyendo el archivo y termina actualizando estado, propietario y registro de decisiones. Esa es toda la capa de orquestación.

Ejemplo: después de un ciclo diseño → revisión

Extracto ilustrativo de transferencia después de que Codex diseñó y Claude revisó:

- Status: implement
- Owner now: cursor
- Next owner: claude

## Design
Files: `PricingSection.tsx` (new), reuse `PlanCard.tsx`
CTA must track clicks with `trackEvent()` + `getCtaClickProps()` from `src/lib/analytics.ts`
Mobile: stacked below `md`, three columns from `md` up
Plan IDs: `starter`, `pro`, `business`
Test: `pnpm test:e2e --grep "pricing"`

## Review
Blocking: none remaining (breakpoint + plan IDs resolved in Design above)
Non-blocking:
- Extract plan constants later if CMS arrives.

## Decision log
- 2026-07-29 Codex: initial component boundaries
- 2026-07-29 Claude: requested breakpoint + explicit plan IDs
- 2026-07-29 Codex: updated Design; Claude cleared blocking items → implement

Ese artefacto es lo que Cursor debe obedecer. El historial de chat es opcional. El archivo es obligatorio.

Instala e invoca cada CLI

Las rutas de instalación exactas cambian; usa la documentación de instalación actual de cada proveedor. Lo que importa es el patrón de invocación no interactiva.

Codex: pasada de diseño

El modo no interactivo de Codex es codex exec. Por defecto se ejecuta en un sandbox de solo lectura. Un trabajo de diseño que actualiza el archivo de transferencia necesita permiso de escritura en el workspace:

cd ../app-pricing-section
codex exec --sandbox workspace-write "$(cat <<'EOF'
Read AGENTS.md and docs/handoffs/2026-07-29-pricing-section.md.
Status is design. Produce the Design section only:
- proposed files
- component/API boundaries
- test plan
- risks
- open questions
Do not implement application code.
Set status to design-review and next owner to claude.
Append a Decision log entry.
EOF
)"

Usa codex interactivo solo cuando quieras dirigir el diseño en vivo. Para scripts y ejecuciones secuenciadas, prefiere codex exec.

Claude Code: pasada de revisión

El modo print de Claude Code puede revisar y actualizar el archivo de transferencia, pero solo si tu configuración de permisos permite escrituras en ese worktree. Mantén el alcance acotado:

cd ../app-pricing-section
claude -p --permission-mode acceptEdits --max-turns 30 --max-budget-usd 5 --output-format text "$(cat <<'EOF'
Read AGENTS.md / CLAUDE.md and docs/handoffs/2026-07-29-pricing-section.md.
You are the reviewer. Do not implement application code.
Challenge the Design section for missing edge cases, local-architecture mismatches, weak tests, and security issues.
Write findings into the Review section as Blocking vs Non-blocking.
If blocking findings exist, set status to design and next owner to codex.
Otherwise set status to implement and next owner to cursor.
Append a Decision log entry.
EOF
)"

Si tu modo de permisos de Claude no puede escribir archivos de forma no interactiva, ejecuta la revisión en solo lectura y haz que una persona o script pegue la sección Review en el archivo de transferencia. Prefiere --permission-mode acceptEdits (o una lista de permitidos en la configuración) para actualizaciones del archivo de transferencia en un worktree desechable. No recurras a --dangerously-skip-permissions en un checkout real.

Controles útiles de Claude Code para ejecuciones con scripts (ver referencia CLI):

• -p / --print para finalización no interactiva
• --max-turns para acotar bucles
• --max-budget-usd para acotar gasto
• --output-format json|text|stream-json para automatización
• --permission-mode acceptEdits cuando la revisión debe escribir el archivo de transferencia en un worktree acotado

No uses --dangerously-skip-permissions de forma casual en checkouts de producción.

Cursor: pasada de implementación

Cursor CLI (agent). Prefiere el mismo worktree dedicado que registra el archivo de transferencia — no implementes desde el checkout principal:

cd ../app-pricing-section
agent -p --trust --sandbox enabled --output-format text "$(cat <<'EOF'
Read AGENTS.md and docs/handoffs/2026-07-29-pricing-section.md.
Status must be implement or fixes.
Implement only the approved Design, respecting Review blocking resolutions.
Keep the patch small. Add or update tests from the Verification section.
Run the verification command and record the result in the handoff file.
Set status to impl-review and next owner to claude.
Do not merge.
EOF
)"

Opciones importantes de la CLI de Cursor:

• -p / --print — no interactivo; ya tiene acceso a herramientas de escritura y shell
• --force / --yolo — auto-aprueba comandos shell a menos que se denieguen; usa solo en sandboxes desechables, no como predeterminado para escribir código
• --sandbox enabled|disabled — modo sandbox para la ejecución; prefiere enabled al implementar con --trust
• --trust — confía en el workspace en automatización
• -w / --worktree [name] — checkout aislado bajo ~/.cursor/worktrees/<repo>/ (ruta distinta de un git worktree add manual; si lo usas, actualiza los campos Branch/Worktree de la transferencia para que coincidan)
• --mode plan o --mode ask — planificación o solo lectura
• --output-format text|json|stream-json

Para ejecuciones de Cursor solo de revisión, prefiere modos ask/plan o una instrucción explícita de «no editar». Prefiere git worktree add manual para que la ruta en la transferencia coincida con el checkout del implementador.

Consulta también la guía de CLI headless de Cursor para flujos con scripts.

Mapa de archivos de instrucciones (evita verdad duplicada)

Si una regla importa para todos los agentes, mantén una única versión canónica y portable y usa solo los puentes que cada herramienta requiera. Las reglas específicas de una herramienta se quedan en local. Duplicar la política crea varios puntos de actualización y aumenta el riesgo de deriva; conviene que una prueba verifique que cada herramienta carga el conjunto de reglas previsto.

Ejemplo de pipeline completo

Asume un repo limpio y una funcionalidad vacía.

1. Crea un worktree aislado

git fetch origin main
git worktree add -b feat/pricing-section ../app-pricing-section origin/main
cd ../app-pricing-section
mkdir -p docs/handoffs

Inicializa el archivo de transferencia con Goal, Non-goals y Verification. Haz commit del andamiaje si tu equipo quiere el contrato visible en los PRs.

2. Codex diseña

Codex escribe la sección Design: archivos, interfaces, pruebas, riesgos. El estado pasa a design-review.

La salida de diseño real debería tener esta forma:

## Design
Files:
- `src/components/marketing/PricingSection.tsx` (new)
- `src/components/marketing/PlanCard.tsx` (reuse)
- `tests/e2e/marketing-pricing.spec.ts` (new)

Boundaries:
- PricingSection owns layout and plan list
- PlanCard remains presentational
- CTA links use existing `trackEvent()` + `getCtaClickProps()` helpers

Test plan:
- three plans visible
- CTA hrefs resolve
- analytics helper called once per click

Risks:
- hardcoding plan IDs out of sync with CMS

3. Claude revisa el diseño

El prompt de revisión requiere hallazgos Blocking/Non-blocking, así que los diseños vagos vuelven bloqueados. Ejemplo:

Bloqueantes:
1. No hay una decisión de maquetación móvil para las tarjetas de plan apiladas.
2. El diseño no indica el comando de verificación (añádelo en Design y en Verification).
No bloqueantes:
- Considera extraer los datos de los planes a una constante.

El estado vuelve a design o avanza a implement solo después de resolver los elementos bloqueantes en Design.

4. Cursor implementa

Cursor implementa solo el diseño aprobado. Ejecuta:

pnpm test:e2e --grep "pricing"

Registra el resultado, abre o prepara un PR y establece impl-review.

5. Claude revisa la implementación

La segunda ejecución de Claude revisa el diff frente a la transferencia, no frente a un ideal recién inventado. Los hallazgos bloqueantes envían el estado a fixes con propietario cursor. La revisión limpia establece done para merge humano.

6. La persona hace merge

Las ramas protegidas permanecen en propiedad humana. Los agentes pueden ser perfiles junior rápidos. No deben ser gestores de release.

Orquestación shell sin plataforma

Un secuenciador simple basta:

#!/usr/bin/env bash
set -euo pipefail
ROOT="${1:?worktree path}"
HANDOFF="${2:?handoff file}"
cd "$ROOT"

status() {
  # Prefer the metadata Status field near the top of the handoff file.
  awk '/^- Status:/{print $3; exit}' "$HANDOFF"
}

case "$(status)" in
  design)
    codex exec --sandbox workspace-write "Read AGENTS.md and $HANDOFF. Fill Design only, then set status=design-review and next owner=claude. Do not implement application code."
    ;;
  design-review|impl-review)
    claude -p --permission-mode acceptEdits --max-turns 30 --max-budget-usd 5 --output-format text "Review $HANDOFF per AGENTS.md. Update Review + status only. Do not implement application code."
    ;;
  implement|fixes)
    agent -p --trust --sandbox enabled --output-format text "Status must be implement or fixes. Implement or fix per $HANDOFF and AGENTS.md. Update handoff. Do not merge."
    ;;
  done|blocked-human)
    echo "No agent action for $(status)"
    ;;
  *)
    echo "Unknown status in $HANDOFF" >&2
    exit 1
    ;;
esac

Esto es deliberadamente aburrido. La orquestación aburrida es depurable. Mantén sandboxes y modos de permisos tan ajustados como permita la etapa: diseño y revisión no deberían necesitar acceso amplio al sistema.

Modos de fallo

Las opciones no interactivas que autoaprueban ediciones o permisos son herramientas de conveniencia para sandboxes y worktrees acotados. No son un modelo de control de acceso de producción.

Qué no automatizar aún

• Merge a ramas protegidas
• Despliegues a producción
• Rotación de secretos
• Migraciones de esquema sin un plan revisado por una persona
• Cualquier flujo donde el archivo de transferencia provenga de un remitente externo no fiable sin saneamiento

Kit de inicio práctico

1. Añade AGENTS.md raíz con comandos, reglas de parche y protocolo multiagente.
2. Añade CLAUDE.md conteniendo @AGENTS.md.
3. Añade docs/handoffs/_template.md.
4. Elige una funcionalidad pequeña.
5. Ejecuta diseño → revisión → implementación → revisión una vez a mano.
6. Solo entonces envuelve los estados en un secuenciador shell.

Si necesitas que los mismos agentes extraigan tareas de un backlog compartido de la empresa, añade Linear MCP y el modelo de estado claim/review de Gestión de proyectos multiagente con Linear. La transferencia markdown sigue siendo útil como cuaderno técnico por issue.

El estándar es el contrato

Codex, Claude Code y Cursor ya se solapan en capacidad. Se convierten en equipo cuando dejas de pedirles que «trabajen juntos» en abstracto y en su lugar impones un contrato visible:

• instrucciones compartidas
• rol explícito por ejecución
• markdown de transferencia con estado
• worktrees aislados
• invocaciones CLI acotadas
• propiedad humana de merge y release

Eso basta para llevar un equipo local de agentes serio con las herramientas de hoy — y basta para notar rápido cuando el equipo improvisa en lugar de hacer ingeniería.