Migrer vers Codex

Autonomie

Continuer jusqu'à ce que la migration sélectionnée soit complètement terminée : exécuter le migrator, inspecter le rapport, corriger les instructions/skills/agents/config MCP migrés dans Codex, et relancer les vérifications sans s'arrêter pour demander une confirmation à chaque étape. Si l'utilisateur a sélectionné une cible, ne pas demander avant de créer, modifier, remplacer ou supprimer des artefacts Codex générés dans cette cible (AGENTS.md, .codex/, .agents/, ou ~/.codex/). Préserver les entrées de configuration Codex existantes non liées dans .codex/config.toml ou ~/.codex/config.toml, telles que notify, projects, marketplaces, ou des serveurs MCP non liés ; ne pas les interroger sauf s'ils échouent la validation ou entrent directement en conflit avec la migration. Ne pas modifier les fichiers Claude Code source (.claude/, ~/.claude/, .mcp.json, ou .claude.json), le code de projet non lié, les secrets, ou un autre repository.

Ordre de migration

Exécuter la migration dans cet ordre pour chaque source globale ou de projet sélectionnée :

1. Commencer par utiliser l'outil de liste TODO/tâches intégré à Codex. Ne pas créer MIGRATION_TODOS.md ou aucun fichier TODO à moins que l'utilisateur ne le demande explicitement. L'entrée de la liste TODO possède un tableau plan dont les éléments ont chacun step et status ; utiliser les statuts pending, in_progress, et completed. Rendre les TODOs spécifiques aux artefacts sélectionnés. Avant de terminer, mettre à jour la liste TODO de sorte que chaque étape terminée soit marquée completed et qu'aucune étape ne reste in_progress. Utiliser les libellés source → cible Codex littéraux, par exemple :

   • Inspecter .claude/commands → skills/prompts Codex
   • Inspecter .claude/agents → .codex/agents
   • Inspecter .mcp.json → serveurs MCP .codex/config.toml
   • Inspecter les hooks .claude/settings.json → .codex/hooks.json
   • Migrer les artefacts sélectionnés sûrs → fichiers Codex
   • Valider .codex/config.toml généré
   • Valider .codex/agents généré
   • Rapporter les artefacts migrés et les éléments nécessitant un examen manuel

2. Lire references/differences.md (et actualiser la documentation Codex si sa date « Docs last checked » est ancienne).

3. Analyser et inspecter avant d'écrire :

   • --scan-only énumère les surfaces source actives et inactives.
   • --plan affiche les chemins d'artefacts Codex préparés et les lignes du rapport.
   • --doctor résume la préparation, le travail d'examen manuel et les risques de validation.

4. Convertir les surfaces dans le même ordre que le CLI :

   • instructions : CLAUDE.md / AGENTS.md vers AGENTS.md
   • plugins : rapporter les arbres de plugins Claude et les marketplaces comme travail de migration manuel
   • hooks : réécrire les hooks Claude pris en charge dans .codex/hooks.json et activer [features].codex_hooks = true
   • skills et commands : écrire les skills Codex sous .agents/skills/
   • config : écrire .codex/config.toml à partir des paramètres de modèle/sandbox Claude et des serveurs MCP, en incluant personality = "friendly" quand la config est générée
   • subagents : écrire les agents personnalisés Codex sous .codex/agents/

5. Exécution de test, puis écrire la cible sélectionnée. Utiliser --replace uniquement quand les skills ou agents générés orphelins doivent être supprimés.

6. Inspecter la sortie du terminal et .codex/migrate-to-codex-report.txt après les exécutions réelles.

7. Examiner les artefacts générés dans cet ordre : AGENTS.md, .agents/skills/, .codex/config.toml, .codex/hooks.json, .codex/agents/, puis les éléments plugins en rapport uniquement.

8. Exécuter --validate-target contre chaque cible après les modifications.

9. Relancer les vérifications et --dry-run après les modifications.

10. Retourner le rapport de migration final sous forme d'un tableau markdown par scope qui possède des lignes. Les tableaux couvrent uniquement le travail de migration de suivi non natif que vous avez effectué, tel que les skills créés à partir de commandes slash, les subagents, les serveurs MCP, les hooks, les notes de plugins non pris en charge/locaux, et les avertissements d'examen manuel. Inclure les lignes d'import natif programmatique pour config, instructions, skills, ou plugins pris en charge uniquement si vous les avez personnellement migrés lors de cette exécution de suivi.

    Si une seule portée possède des lignes, afficher uniquement le tableau sans titre. Si plusieurs portées possèdent des lignes, afficher un titre avant chaque tableau. Utiliser **User Config** pour les lignes de portée utilisateur. Pour les lignes de portée projet, utiliser le nom de dossier de projet réel comme titre, par exemple **northstar-support-portal** ; ne pas utiliser Current Project comme titre. Ne pas ajouter de prose avant ou après la sortie du tableau.

    Utiliser exactement ces colonnes :

    northstar-support-portal

    Status	Item	Notes
    Added	Slash command pr-review	Converted into a Codex skill
    Added	Subagent release-lead	Added as a Codex subagent
    Check before using	Hook PreToolUse	Converted, but some Claude hook behavior differs in Codex
    Not Added	Hook Notification	Codex does not have an equivalent notification hook
    Not Added	Plugin team-macros	Plugin needs manual setup

    Status doit être Added, Check before using, ou Not Added. Utiliser Added quand un artefact orienté Codex a été créé ou modifié et ne nécessite aucun examen spécial. Utiliser Check before using quand un artefact orienté Codex a été créé ou modifié mais la migration a modifié la sémantique, le comportement inféré, préservé les règles d'outil comme orientation, ou supprimé le comportement non pris en charge. Utiliser Not Added quand un artefact source a été détecté mais aucun artefact orienté Codex n'a été créé. Item combine le type d'artefact et le nom d'élément concret dans une seule cellule. Le type d'artefact doit être singulier : Skill, Slash command, Subagent, MCP, Hook, ou Plugin. Entourer le type d'artefact de code inline ; écrire le nom de l'élément en texte brut après. Notes est toujours requis ; ne jamais le laisser vide. Garder les notes courtes, simples et littérales. Éviter les termes de mise en œuvre interne tels que l'expansion du runtime. Préférer les phrases comme Converted into a Codex skill, Added as a Codex subagent, Added to Codex config, Converted into a Codex hook, Converted, but some Claude hook behavior differs in Codex, Codex does not have an equivalent notification hook, Plugin needs manual setup, ou Plugin marketplace needs manual setup.

Boucle d'auto-correction

Continuer la boucle jusqu'à ce que la migration sélectionnée soit complète :

1. Exécuter --plan ou --doctor.
2. Exécuter la migration avec --dry-run.
3. Exécuter la migration pour de vrai.
4. Corriger tous les blocs ## MANUAL MIGRATION REQUIRED générés et toutes les lignes du rapport manual_fix_required ou skipped qui peuvent être résolues à l'intérieur des artefacts Codex.
5. Exécuter --validate-target.
6. Relancer le migrator et le validateur jusqu'à ce que le rapport et le validateur n'aient aucune correction d'artefact généré exploitable à gauche.

Ne pas modifier les fichiers Claude Code source, le code de projet non lié, les secrets, ou un autre repository lors de cette boucle. Si une ligne du rapport nécessite des modifications du fournisseur source ou un jugement de produit, laisser l'artefact Codex généré avec des directives manuelles claires au lieu de modifier la source.

Commandes

Choisir la commande du migrator.

   MIGRATE_TO_CODEX='python3 .codex/skills/migrate-to-codex/scripts/migrate-to-codex.py'

Inspecter la migration avant d'écrire.

   $MIGRATE_TO_CODEX --source ~/.claude/ --scan-only
   $MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/ --plan
   $MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/ --doctor

Exécution de test, puis lancer sans --dry-run, pour global et projet.

   $MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/ --dry-run
   $MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/
   $MIGRATE_TO_CODEX --source ./.claude/ --target ./.codex/ --dry-run
   $MIGRATE_TO_CODEX --source ./.claude/ --target ./.codex/

Exécuter le validateur post-migration contre chaque cible après les modifications.

   $MIGRATE_TO_CODEX --validate-target ~/.codex/
   $MIGRATE_TO_CODEX --validate-target ./.codex/

Exécuter $MIGRATE_TO_CODEX --help pour les flags (--scan-only, --plan, --doctor, --validate-target, les défauts, etc.). Les tableaux approfondis et plus de liens se trouvent dans references/differences.md.