Faire de Codex, Claude Code et Cursor une seule équipe en ligne de commande

Codex, Claude Code et Cursor peuvent modifier des dépôts, exécuter des commandes et suivre les instructions d’un projet dans les limites des capacités et autorisations qui leur sont configurées. Cet article teste un contrat opérationnel fondé sur des fichiers ; il n’affirme ni que toutes les équipes ont besoin de trois agents ni que ce contrat efface les différences propres à chaque outil.

Cet article montre comment le faire avec des fichiers et des CLI que vous avez déjà :

• Instructions de projet partagées dans AGENTS.md
• Pont vers Claude via CLAUDE.md, qui importe @AGENTS.md
• Instructions de base Cursor plus .cursor/rules optionnelles
• Document Markdown structuré pour la transmission entre les rôles
• Exécutions CLI non interactives pour conception, revue et implémentation

Aucune plateforme de gestion de projet sur mesure n’est nécessaire. Si vous souhaitez ensuite partager un backlog entre les agents, associez cette méthode à la gestion de projet multi-agents avec Linear. Ici, Git et Markdown servent de moyens de coordination.

Documentation des produits revérifiée le 4 août 2026 à partir d’AGENTS.md, du guide AGENTS.md d’OpenAI Codex, du mode non interactif de Codex, de la documentation de Claude Code sur la mémoire, de la référence de la CLI Claude Code et de la documentation de la CLI Cursor. Le flux complet de transmission entre les trois clients n’a pas été exécuté de bout en bout pendant cette revue ; validez les commandes et les autorisations avec des versions de clients figées avant de vous appuyer sur cette méthode.

La forme de l’équipe

Une spécialisation de départ fiable :

Ces rôles sont des conventions, pas des limites imposées par les fournisseurs. Chaque outil peut concevoir, examiner ou implémenter. La spécialisation crée une frontière claire entre les livrables : un agent rédige un plan, un autre le met à l’épreuve et un troisième n’implémente que ce qui a résisté à la revue.

Instructions partagées : une seule source de vérité

Utiliser AGENTS.md comme base portable

AGENTS.md est le format d’instructions commun à plusieurs outils, placé sous l’égide de l’Agentic AI Foundation. Codex le lit nativement. Cursor prend en charge un fichier AGENTS.md à la racine comme ensemble partagé d’instructions de projet, aux côtés de .cursor/rules. Gardez-le concis et opérationnel :

# 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 documentation Codex d’OpenAI décrit la découverte des fichiers depuis la racine du projet jusqu’au répertoire de travail : les fichiers les plus proches sont prioritaires, AGENTS.override.md est facultatif et la taille totale est limitée par défaut à 32 Kio, sauf augmentation explicite. Gardez le fichier racine concis et placez les règles propres aux paquets dans des fichiers AGENTS.md imbriqués.

Pont Claude Code avec CLAUDE.md

Claude Code lit CLAUDE.md, pas AGENTS.md. La recommandation officielle consiste à importer le fichier partagé :

@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 lien symbolique (ln -s AGENTS.md CLAUDE.md) convient aussi si vous n’avez pas besoin d’instructions propres à Claude. Sous Windows, préférez l’import @AGENTS.md.

Confirmez le chargement avec /context de Claude et vérifiez Memory files.

Garder les règles spécifiques à Cursor étroites

Cursor peut utiliser le fichier AGENTS.md à la racine pour les conventions communes. Réservez .cursor/rules/*.mdc aux besoins propres à Cursor, par exemple des règles dont le périmètre est défini par un motif de fichiers. Ne maintenez pas trois encyclopédies divergentes.

Le fichier de transmission est la conversation entre coéquipiers

Créez un répertoire :

mkdir -p docs/handoffs

Utilisez un fichier par unité de travail :

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

Voici des états qui fonctionnent bien, avec des retours possibles plutôt qu’une progression forcée à sens unique :

1. design
2. design-review — les constats bloquants renvoient à design ; une revue sans blocage fait passer à implement
3. implement
4. impl-review — les constats bloquants font passer à fixes ; une revue sans blocage fait passer à done
5. fixes — l’agent d’implémentation résout les constats, puis revient à impl-review
6. done
7. blocked-human

Toutes les tâches ne visitent pas fixes. Un impl-review propre peut aller directement à done.

Chaque exécution en ligne de commande commence par lire le fichier et se termine par la mise à jour de l’état, de l’agent responsable et du journal des décisions. C’est toute la couche d’orchestration.

Exemple : après un cycle conception → revue

Voici un extrait de transmission après une conception par Codex et une revue par Claude :

- 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

Ce document constitue la référence que Cursor doit suivre. L’historique de la conversation est facultatif ; le fichier est obligatoire.

Installer et invoquer chaque CLI

Les procédures d’installation évoluent ; consultez la documentation à jour de chaque fournisseur. Le point important ici est le mode d’appel non interactif.

Codex : passe de conception

Le mode non interactif de Codex est codex exec. Par défaut, il s’exécute dans un environnement isolé en lecture seule. Une tâche de conception qui met à jour le fichier de transmission a besoin d’une autorisation d’écriture dans l’espace de travail :

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
)"

Utilisez codex interactif seulement quand vous voulez diriger la conception en direct. Pour les scripts et les exécutions séquencées, préférez codex exec.

Claude Code : étape de revue

Le mode non interactif de Claude Code peut examiner et mettre à jour le fichier de transmission, mais uniquement si les paramètres d’autorisation permettent les écritures dans ce worktree. Gardez un périmètre étroit :

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 votre mode d’autorisation Claude ne permet pas d’écrire des fichiers de façon non interactive, exécutez la revue en lecture seule et faites insérer la section Review dans le fichier de transmission par une personne ou un script. Préférez --permission-mode acceptEdits, ou une liste explicite d’autorisations, pour les mises à jour dans un worktree jetable. N’utilisez pas --dangerously-skip-permissions dans un véritable répertoire de travail.

Contrôles Claude Code utiles pour les exécutions scriptées (voir référence CLI) :

• -p / --print pour l’exécution non interactive
• --max-turns pour borner les boucles
• --max-budget-usd pour borner les dépenses
• --output-format json|text|stream-json pour l’automatisation
• --permission-mode acceptEdits lorsque la revue doit écrire le fichier de transmission dans un worktree au périmètre limité

N’utilisez pas --dangerously-skip-permissions à la légère dans des répertoires de production.

Cursor : étape d’implémentation

Pour la CLI Cursor (agent), utilisez de préférence le worktree dédié indiqué dans le fichier de transmission ; n’implémentez pas depuis le répertoire de travail 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
)"

Options importantes de la CLI Cursor :

• -p / --print — mode non interactif qui dispose déjà des outils d’écriture et du shell
• --force / --yolo — approuve automatiquement les commandes shell, sauf refus explicite ; à réserver aux environnements isolés jetables, pas comme valeur par défaut pour modifier du code
• --sandbox enabled|disabled — règle l’isolation de l’exécution ; préférez enabled lorsque vous implémentez avec --trust
• --trust — marque l’espace de travail comme fiable pour l’automatisation
• -w / --worktree [name] — crée un répertoire de travail isolé sous ~/.cursor/worktrees/<repo>/ ; ce chemin diffère de celui d’un git worktree add manuel. Si vous l’utilisez, mettez à jour les champs Branch et Worktree de la transmission.
• --mode plan ou --mode ask — planification ou lecture seule
• --output-format text|json|stream-json

Pour les exécutions Cursor limitées à la revue, préférez les modes ask ou plan, ou ajoutez une instruction explicite « do not edit ». Un git worktree add manuel permet de faire correspondre le chemin indiqué dans la transmission au répertoire de l’agent d’implémentation.

Consultez aussi le guide de Cursor sur la CLI sans interface pour les flux scriptés.

Répartition des fichiers d’instructions pour éviter les doublons

Si une règle compte pour chaque agent, conservez une seule version canonique portable et n’utilisez que les ponts requis par chaque outil. Les règles propres à un outil restent locales. Dupliquer une politique crée plusieurs points de mise à jour et augmente le risque de dérive ; un test devrait vérifier que chaque outil charge bien le jeu de règles prévu.

Exemple de pipeline complet

Partez d’un dépôt propre et d’une fonctionnalité encore non implémentée.

1. Créer un worktree isolé

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

Initialisez le fichier de transmission avec les sections Goal, Non-goals et Verification. Enregistrez cette structure dans un commit si l’équipe souhaite rendre le contrat visible dans les PR.

2. Codex conçoit

Codex écrit la section Design : fichiers, interfaces, tests, risques. Le statut devient design-review.

Un véritable livrable de conception doit adopter une forme comparable :

## 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 examine la conception

Le prompt de revue exige des constats Blocking et Non-blocking ; une conception vague est donc renvoyée pour correction. Exemple :

Bloquant :
1. Aucune décision de mise en page mobile pour les cartes d'offres empilées.
2. Le design n'indique pas la commande de vérification (à ajouter dans les sections Design et Verification).
Non bloquant :
- Envisager d'extraire les données des offres dans une constante.

L’état revient à design ou passe à implement uniquement après la résolution des éléments bloquants dans la section Design.

4. Cursor implémente

Cursor n’implémente que le design approuvé. Il exécute :

pnpm test:e2e --grep "pricing"

Il enregistre le résultat, ouvre ou prépare une PR et passe à impl-review.

5. Claude examine l’implémentation

Une seconde exécution de Claude compare le diff au document de transmission, pas à un idéal nouvellement inventé. Les constats bloquants font passer l’état à fixes avec cursor comme responsable. Une revue sans blocage fait passer à done en vue d’une fusion par une personne.

6. Une personne effectue la fusion

La responsabilité des branches protégées reste humaine. Les agents peuvent agir comme des développeurs juniors rapides, mais pas comme responsables des mises en production.

Orchestration shell sans plateforme

Un simple séquenceur suffit :

#!/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

Cette orchestration est volontairement simple, donc facile à diagnostiquer. Limitez les environnements isolés et les autorisations au strict nécessaire pour chaque étape : la conception et la revue ne devraient pas exiger un large accès au système.

Modes de défaillance

Les options non interactives qui approuvent automatiquement les modifications ou les autorisations sont des outils pratiques pour des environnements isolés et des worktrees au périmètre strictement limité. Elles ne constituent pas un modèle de contrôle d’accès en production.

Ce qu’il ne faut pas encore automatiser

• Fusionner vers des branches protégées
• Déploiements en production
• Rotation de secrets
• Migrations de schéma sans plan revu par un humain
• Tout flux dans lequel le fichier de transmission lui-même provient d’un contributeur externe non fiable et n’a pas été assaini

Kit de démarrage pratique

1. Ajoutez à la racine un fichier AGENTS.md contenant les commandes, les règles de modification et le protocole multi-agents.
2. Ajoutez un CLAUDE.md contenant @AGENTS.md.
3. Ajoutez docs/handoffs/_template.md.
4. Choisissez une petite fonctionnalité.
5. Exécutez conception → revue → implémentation → revue une fois à la main.
6. Ensuite seulement, automatisez l’enchaînement des états au moyen d’un script shell.

Si les mêmes agents doivent récupérer des tâches dans un backlog commun à l’entreprise, ajoutez Linear MCP et le modèle d’états pour la prise en charge et la revue décrit dans la gestion de projet multi-agents avec Linear. Le document Markdown de transmission reste utile comme journal technique associé à chaque ticket.

Le standard est le contrat

Les capacités de Codex, Claude Code et Cursor se recoupent déjà. Ces outils deviennent une équipe lorsque vous cessez de leur demander abstraitement de « travailler ensemble » et leur imposez un contrat visible :

• instructions partagées
• rôle explicite par exécution
• document Markdown de transmission avec état
• worktrees isolés
• invocations CLI bornées
• responsabilité humaine pour la fusion et la mise en production

Cela suffit pour faire fonctionner sérieusement une équipe locale d’agents avec les outils actuels, et pour repérer rapidement le moment où elle commence à improviser au lieu de suivre une démarche d’ingénierie.