Flux de travail Codex et Antigravity

Le but de cette configuration est simple : confier les travaux transversaux à l’agent le plus robuste, garder l’éditeur réactif et ne maintenir chaque règle durable qu’à un seul endroit.

Répartition des rôles

Outil	Usage recommandé
Codex	Implémentations multi-fichiers, tests, revues, refactorisations et tâches où la justesse prime sur la latence
CLI Antigravity	Second point d’entrée pour travailler avec un agent dans le terminal
IDE Antigravity	Édition, navigation, complétion, interactions avec le navigateur et productions visuelles proches du code

Codex utilise actuellement gpt-5.6-sol avec un niveau de raisonnement élevé. Ce choix privilégie volontairement la fiabilité ; un mode plus rapide ne se justifie que lorsque le coût d’une erreur est réellement faible.

Commandes quotidiennes

cx                         # lancer Codex dans le dépôt courant
agy                        # conserver la CLI Antigravity d’origine
agy-ide                    # ouvrir l’IDE Antigravity dans le dossier courant
agy-ide /path/to/repo      # ouvrir un dépôt précis
agent-init                 # prévisualiser le socle commun pour agents
agent-init --apply         # l’appliquer après examen du plan
ws                         # utiliser le raccourci vers les espaces de travail

agy reste volontairement inchangé. La commande distincte agy-ide évite toute ambiguïté et rend explicite le dossier à ouvrir.

Une seule source pour les règles communes

Les règles personnelles par défaut se trouvent ici :

$HOME/.config/agent-guidance/AGENTS.md

Le fichier global AGENTS.md de Codex et le fichier global GEMINI.md d’Antigravity sont des liens symboliques vers cette source. Une modification met donc les deux outils à jour. L’initialiseur de projets réutilisable suit le même principe :

$HOME/Projects/agent-toolkit
├── lié depuis $HOME/.codex/skills/agent-toolkit
└── lié depuis $HOME/.gemini/config/skills/agent-toolkit

Il ne faut pas copier les mêmes instructions dans deux arborescences de configuration. Les comportements propres à un outil restent dans sa configuration ; les règles réellement partagées restent dans la source commune.

Un contrat par dépôt

Exécuter agent-init depuis un dépôt Git, examiner d’abord le dry run, puis choisir de l’appliquer. L’outil peut ajouter :

• AGENTS.md, contrat canonique du projet ;
• .agents/rules/project-guidance.md, pont d’Antigravity vers AGENTS.md ;
• arch.md, .editorconfig et .gitattributes ;
• des exclusions sûres pour l’état des agents, les secrets, les caches et les sorties générées ;
• une configuration zsh facultative pour VS Code sous WSL.

Les commandes, limites d’architecture et critères d’achèvement propres au projet appartiennent à son AGENTS.md. Les règles globales doivent rester brèves et portables.

Limite entre commodité et sécurité

Cette instance WSL est privée, mono-utilisateur et volontairement employée avec root. Les opérations courantes et réversibles dans le dépôt demandé — édition, tests, build et inspection Git locale — peuvent être effectuées directement.

Une confirmation explicite reste nécessaire avant une modification récursive destructive, un force push, une publication externe, une intervention dans un dépôt sans rapport, l’exposition de secrets ou de données privées ignorées, une modification des montages Windows ou de larges répertoires système. La commodité est la règle dans l’espace actif ; le périmètre reste la limite.

Travail parallèle avec plusieurs agents

Deux agents ne doivent pas modifier simultanément le même checkout. Attribuer aux tâches indépendantes des worktrees et des branches distincts :

git worktree add ../project-codex -b agent/codex-task
git worktree add ../project-agy -b agent/agy-task

Chaque branche peut ensuite être relue et intégrée normalement. Les worktrees rendent la responsabilité visible et évitent les écrasements silencieux.

Publier une suite sur ce site

La demande « mets ceci sur mon site personnel » déclenche une compétence de gestion du site dont la source unique reste dans le dépôt du site. Quel que soit le dossier courant, Codex et Antigravity découvrent cette même source par des liens symboliques :

$HOME/my-website/.agents/skills/docusaurus-site-management
├── lié depuis $HOME/.codex/skills/docusaurus-site-management
└── lié depuis $HOME/.gemini/config/skills/docusaurus-site-management

L’agent doit ensuite :

1. ouvrir $HOME/my-website et examiner son état Git et ses règles d’architecture ;
2. rechercher une note existante avant d’en créer une ;
3. choisir entre mettre à jour une note, compléter le Build Log ou créer un guide ciblé ;
4. retirer les détails privés ou propres à une seule machine et préférer les chemins fondés sur $HOME ;
5. publier des versions chinoise, anglaise et française correspondantes ;
6. contrôler la fraîcheur des langues, puis adapter la validation au risque : un simple Markdown peut s’arrêter là, tandis qu’un changement d’interface ou de structure justifie un build et une vérification dans le navigateur.

Cette demande autorise les modifications locales du site et leur validation. Le push ou le déploiement demeure une action distincte à demander explicitement.

Récupération

Les instantanés de configuration contiennent la source commune des règles et un bundle Git de l’agent toolkit. Ils excluent volontairement les clés privées, les fichiers de secrets du shell et les projets. Restaurer d’abord la source, puis recréer les liens au lieu de sauvegarder plusieurs copies.

L’historique de l’environnement se trouve dans le journal de construction.