Migrer vers Codex

Autonomie

Continuez jusqu'à ce que la migration sélectionnée soit complètement terminée : exécutez le migrateur, inspectez le rapport, corrigez les instructions/compétences/agents/configuration MCP migrés de Codex, et réexécutez les vérifications sans vous arrêter pour demander une confirmation pour l'étape suivante. Si l'utilisateur a sélectionné une cible, ne demandez pas avant de créer, modifier, remplacer ou supprimer des artefacts Codex générés dans cette cible (AGENTS.md, .codex/, .agents/, ou ~/.codex/). Conservez les entrées de configuration Codex existantes non liées dans .codex/config.toml ou ~/.codex/config.toml, telles que notify, projects, marketplaces, ou serveurs MCP non liés ; ne posez de questions à leur sujet que s'ils échouent la validation ou entrent directement en conflit avec la migration. Ne modifiez pas les fichiers Claude Code source (.claude/, ~/.claude/, .mcp.json, ou .claude.json), le code de projet non lié, les secrets, ou un autre référentiel.

Ordre de migration

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

Commencez par utiliser l'outil de liste TODO/tâches intégré à Codex. Ne créez pas MIGRATION_TODOS.md ou aucun fichier TODO à moins que l'utilisateur ne le demande explicitement. L'entrée de liste TODO a un tableau plan dont chaque élément a step et status ; utilisez les statuts pending, in_progress, et completed. Rendez les TODOs spécifiques aux artefacts sélectionnés. Utilisez des étiquettes source → cible Codex littérales, par exemple :
- Inspectez .claude/commands → compétences/prompts Codex
- Inspectez .claude/agents → .codex/agents
- Inspectez .mcp.json → serveurs MCP .codex/config.toml
- Inspectez les hooks .claude/settings.json → .codex/hooks.json
- Migrez les artefacts sélectionnés sûrs → fichiers Codex
- Validez le .codex/config.toml généré
- Validez le .codex/agents généré
- Rapportez les artefacts migrés et les éléments nécessitant un examen manuel
Lisez references/differences.md (et actualisez la documentation Codex si sa date Docs last checked est ancienne).
Scannez et inspectez avant d'écrire :
- --scan-only répertorie les surfaces source actives et inactives.
- --plan imprime les chemins d'artefacts Codex intermédiaires et les lignes de rapport.
- --doctor résume la disponibilité, le travail d'examen manuel et les risques de validation.
Convertissez les surfaces dans le même ordre que le CLI :
- instructions : CLAUDE.md / AGENTS.md vers AGENTS.md
- plugins : rapportez les arbres de plugins Claude et les places de marché comme travail de migration manuel
- hooks : réécrivez les hooks Claude supportés dans .codex/hooks.json et activez [features].codex_hooks = true
- compétences et commandes : écrivez les compétences Codex sous .agents/skills/
- config : écrivez .codex/config.toml à partir des paramètres de modèle/sandbox Claude et des serveurs MCP, y compris personality = "friendly" lors de la génération de config
- sous-agents : écrivez les agents personnalisés Codex sous .codex/agents/
Exécutez un essai à blanc, puis écrivez la cible sélectionnée. Utilisez --replace uniquement quand les compétences ou agents générés orphelins doivent être supprimés.
Inspectez la sortie du terminal et .codex/migrate-to-codex-report.txt après les exécutions réelles.
Passez en revue 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 de rapport uniquement pour les plugins.
Exécutez --validate-target contre chaque cible après les modifications.
Réexécutez les vérifications et --dry-run après les modifications.

Retournez le rapport de migration final sous forme d'un tableau markdown par portée qui a des lignes. Les tableaux couvrent uniquement les travaux de migration de suivi non natifs que vous avez effectués, tels que les compétences créées à partir de commandes slash, les sous-agents, les serveurs MCP, les hooks, les notes de plugins non supportés/locaux et les avertissements d'examen manuel. Incluez les lignes d'importation natives programmatiques pour config, instructions, compétences ou plugins supportés uniquement si vous les avez personnellement migrés dans cette exécution de suivi.

Si une seule portée a des lignes, restituez uniquement le tableau sans en-tête. Si plusieurs portées ont des lignes, affichez un en-tête avant chaque tableau. Utilisez **User Config** pour les lignes de portée utilisateur. Pour les lignes de portée de projet, utilisez le nom du dossier de projet réel comme en-tête, par exemple **northstar-support-portal** ; n'utilisez pas Current Project comme en-tête. N'ajoutez pas de prose avant ou après la sortie du tableau.

Utilisez exactement ces colonnes :

northstar-support-portal

Status	Item	Notes
`Added`	`Slash command` pr-review	Converti en une compétence Codex
`Added`	`Subagent` release-lead	Ajouté en tant que sous-agent Codex
`Check before using`	`Hook` PreToolUse	Converti, mais certains comportements du hook Claude diffèrent dans Codex
`Not Added`	`Hook` Notification	Codex n'a pas d'équivalent de hook de notification
`Not Added`	`Plugin` team-macros	Le plugin nécessite une configuration manuelle

Status doit être Added, Check before using, ou Not Added. Utilisez Added quand un artefact destiné à Codex a été créé ou modifié et ne nécessite aucun examen particulier. Utilisez Check before using quand un artefact destiné à Codex a été créé ou modifié mais la migration a changé la sémantique, le comportement déduit, les règles d'outil conservées comme conseils, ou le comportement non supporté supprimé. Utilisez Not Added quand un artefact source a été détecté mais aucun artefact destiné à Codex n'a été créé. Item combine le type d'artefact et le nom d'élément concret en une seule cellule. Le type d'artefact doit être au singulier : Skill, Slash command, Subagent, MCP, Hook, ou Plugin. Enrobez le type d'artefact dans du code en ligne ; écrivez le nom de l'élément en texte brut après. Notes est toujours obligatoire ; ne la laissez jamais vide. Gardez les notes courtes, simples et littérales. Évitez les termes d'implémentation interne tels que l'expansion du runtime. Préférez les expressions comme Converti en une compétence Codex, Ajouté en tant que sous-agent Codex, Ajouté à la configuration Codex, Converti en un hook Codex, Converti, mais certains comportements du hook Claude diffèrent dans Codex, Codex n'a pas d'équivalent de hook de notification, Le plugin nécessite une configuration manuelle, ou La place de marché des plugins nécessite une configuration manuelle.

Boucle d'auto-correction

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

Exécutez --plan ou --doctor.
Exécutez la migration avec --dry-run.
Exécutez la migration pour de vrai.
Corrigez chaque bloc ## MANUAL MIGRATION REQUIRED généré et chaque ligne de rapport manual_fix_required ou skipped qui peut être résolu à l'intérieur des artefacts Codex.
Exécutez --validate-target.
Réexécutez le migrateur et le validateur jusqu'à ce que le rapport et le validateur n'aient aucun correctif d'artefact généré exploitable restant.

Ne modifiez pas les fichiers Claude Code source, le code de projet non lié, les secrets, ou un autre référentiel au cours de cette boucle. Si une ligne de rapport nécessite des modifications du fournisseur source ou un jugement produit, laissez l'artefact Codex généré avec des conseils manuels clairs au lieu de modifier la source.

Commandes

Choisissez la commande du migrateur.

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

Inspectez 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écutez un essai à blanc, puis exécutez 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écutez le validateur post-migration contre chaque cible après les modifications.

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

Exécutez $MIGRATE_TO_CODEX --help pour les drapeaux (--scan-only, --plan, --doctor, --validate-target, valeurs par défaut, etc.). Les tableaux détaillés et plus de liens sont dans references/differences.md.