Introduction

Si Codex utilise régulièrement la même API, la même source de journaux, le même export de boîte de réception, la même base de données locale ou le même script d’équipe, donnez-lui une commande dédiée. Codex pourra l’exécuter depuis n’importe quel dossier, examiner et filtrer ses résultats, puis la combiner avec git, gh, rg, des tests et les scripts du dépôt.

Ajoutez un skill qui précise quand Codex doit utiliser la CLI, quelle commande exécuter en premier, comment limiter le volume des résultats, où retrouver les fichiers téléchargés et quelles commandes d’écriture nécessitent une approbation.

Dans ce workflow, $cli-creator aide Codex à créer la commande. $skill-creator l’aide à enregistrer un skill réutilisable, comme $ci-logs, que Codex pourra appeler par son nom lors de futures tâches.

Mode d’emploi

Définissez ce que la CLI doit faire

Commencez par définir ce que vous voulez que Codex fasse avant de choisir une technologie. Une bonne CLI transforme une opération récurrente en une commande que Codex peut exécuter depuis n’importe quel dépôt : lire, rechercher, télécharger, exporter, préparer un brouillon, envoyer un fichier, vérifier périodiquement un état ou écrire des données en toute sécurité.

Fournissez la documentation, les fichiers ou les commandes

Donnez à Codex une source concrète sur laquelle s’appuyer : de la documentation, une spécification OpenAPI, une commande curl dont vous avez masqué les données sensibles, le chemin d’un export ou d’une base de données, un dossier de journaux ou un script existant. Si vous souhaitez que la CLI reprenne des conventions familières, collez un court extrait de la sortie de --help pour gh, kubectl ou un outil de votre équipe.

Si la commande nécessite une authentification, indiquez à Codex le nom de la variable d’environnement, le chemin du fichier de configuration ou la procédure de connexion à prendre en charge. Renseignez vous-même le secret dans votre shell ou votre fichier de configuration. Ne collez aucun secret dans la discussion. Demandez à Codex de faire en sorte que la vérification de la configuration de la CLI échoue avec un message clair si les informations d’authentification manquent.

Demandez à Codex de créer la CLI et le skill

Utilisez le prompt de départ proposé sur cette page. Précisez la source sur laquelle Codex doit s’appuyer et la première tâche que la CLI doit permettre d’accomplir.

Avant d’écrire le code, Codex doit vous présenter les commandes envisagées et vous demander uniquement les précisions indispensables à leur mise en œuvre.

Vérifiez que la commande fonctionne depuis n’importe quel dossier

Codex doit poursuivre les tests après avoir exécuté cargo run, python path/to/script.py ou une commande d’un paquet qui n’a pas été installé. Demandez-lui de tester la commande installée depuis un autre dépôt ou un dossier temporaire, dans les conditions où il l’utilisera lors d’une future tâche.

Testez la CLI comme le ferait un agent lors d’une future tâche

Si Codex renvoie un énorme bloc de JSON, demandez-lui de limiter le contenu de la réponse par défaut et d’ajouter une option pour exporter les données complètes dans un fichier. S’il oublie quelles commandes nécessitent une approbation, demandez-lui de mettre à jour le skill associé avant de le réutiliser pour une autre tâche.

Réutilisez le skill

Lorsque vous aurez de nouveau besoin de la CLI, appelez le skill au lieu de coller une nouvelle fois la documentation :

Pour une tâche récurrente, testez le skill une fois dans une discussion, puis demandez à Codex de planifier depuis cette discussion une tâche qui appellera le skill avec le même prompt.