Compétence de Génération d'Images

Génère ou modifie des images pour le projet actuel (par exemple, éléments de site web, éléments de jeu, maquettes UI, maquettes de produit, wireframes, conception de logo, images photoréalistes ou infographies).

Modes et règles de haut niveau

Cette compétence dispose de exactement deux modes de haut niveau :

Mode outil intégré par défaut (préféré) : outil image_gen intégré pour la génération et la modification d'images normales. Ne nécessite pas OPENAI_API_KEY.
Mode CLI de secours (explicite uniquement) : CLI scripts/image_gen.py. À utiliser uniquement si l'utilisateur demande explicitement le chemin CLI. Nécessite OPENAI_API_KEY.

Dans le secours CLI explicite uniquement, le CLI expose trois sous-commandes :

generate
edit
generate-batch

Règles :

Utilisez l'outil image_gen intégré par défaut pour toutes les demandes normales de génération et de modification d'images.
Ne basculez jamais vers le secours CLI automatiquement.
Si l'outil intégré échoue ou n'est pas disponible, informez l'utilisateur que le secours CLI existe et qu'il nécessite OPENAI_API_KEY. Procédez uniquement si l'utilisateur demande explicitement ce secours.
Si l'utilisateur demande explicitement le mode CLI, utilisez le flux de travail scripts/image_gen.py fourni. Ne créez pas de lanceurs SDK ponctuels.
Ne modifiez jamais scripts/image_gen.py. Si quelque chose manque, demandez à l'utilisateur avant de faire quoi que ce soit d'autre.

Politique de chemin d'accès de sauvegarde intégré :

En mode outil intégré, Codex enregistre les images générées sous $CODEX_HOME/* par défaut.
Ne décrivez pas ou ne vous fiez pas au temp du système d'exploitation comme destination intégrée par défaut.
Ne décrivez pas ou ne vous fiez pas à un argument de chemin de destination (le cas échéant) sur l'outil image_gen intégré. Si un emplacement spécifique est nécessaire, générez d'abord, puis déplacez ou copiez la sortie sélectionnée de $CODEX_HOME/generated_images/....
Précédence du chemin de sauvegarde en mode intégré :
1. Si l'utilisateur nomme une destination, déplacez ou copiez la sortie sélectionnée là-bas.
2. Si l'image est destinée au projet actuel, déplacez ou copiez l'image finale sélectionnée dans l'espace de travail avant de terminer.
3. Si l'image est seulement pour un aperçu ou un brainstorming, affichez-la en ligne ; le fichier sous-jacent peut rester au chemin par défaut $CODEX_HOME/*.
Ne laissez jamais un élément référencé par le projet uniquement au chemin par défaut $CODEX_HOME/*.
N'écrasez pas un élément existant sauf si l'utilisateur a explicitement demandé un remplacement ; sinon, créez un nom de fichier versionnée tel que hero-v2.png ou item-icon-edited.png.

Les conseils de prompt partagés pour les deux modes se trouvent dans references/prompting.md et references/sample-prompts.md.

Docs/ressources de secours uniquement pour le mode CLI :

references/cli.md
references/image-api.md
references/codex-network.md
scripts/image_gen.py

Quand l'utiliser

Générer une nouvelle image (concept art, photo de produit, couverture, hero de site web)
Générer une nouvelle image en utilisant une ou plusieurs images de référence pour le style, la composition ou l'ambiance
Modifier une image existante (inpainting, transformations d'éclairage ou météorologiques, remplacement d'arrière-plan, suppression d'objets, composition, arrière-plan transparent)
Produire de nombreux éléments ou variantes pour une tâche

Quand ne pas l'utiliser

Extension ou correspondance d'un ensemble d'icônes SVG/vectoriel existant, d'un système de logo ou d'une bibliothèque d'illustrations dans le dépôt
Création de formes simples, de diagrammes, de wireframes ou d'icônes mieux produits directement en SVG, HTML/CSS ou canvas
Modification d'un petit élément local au projet quand le fichier source existe déjà dans un format natif modifiable
Toute tâche où l'utilisateur veut clairement une sortie déterministe native au code plutôt qu'une bitmap générée

Arbre de décision

Posez-vous deux questions distinctes :

Intention : s'agit-il d'une nouvelle image ou d'une modification d'une image existante ?
Stratégie d'exécution : s'agit-il d'un seul élément ou de nombreux éléments/variantes ?

Intention :

Si l'utilisateur souhaite modifier une image existante en préservant certaines parties, traitez la demande comme une modification.
Si l'utilisateur fournit des images uniquement comme références pour le style, la composition, l'ambiance ou les conseils de sujet, traitez la demande comme une génération.
Si l'utilisateur ne fournit aucune image, traitez la demande comme une génération.

Sémantique de modification intégrée :

Le mode de modification intégré s'applique aux images déjà visibles dans le contexte de la conversation, telles que les images jointes ou les images générées plus tôt dans le thread.
Si l'utilisateur souhaite modifier un fichier image local avec l'outil intégré, chargez-le d'abord avec l'outil intégré view_image pour que l'image soit visible dans le contexte de la conversation, puis procédez au flux de modification intégré.
Ne promettez pas de modification arbitraire du chemin du système de fichiers à travers l'outil intégré.
Si un fichier local a toujours besoin du contrôle du chemin du fichier direct, de masques ou d'autres paramètres explicites au CLI uniquement, utilisez le secours CLI explicite uniquement si l'utilisateur le demande.
Pour les modifications, préservez les invariants de manière agressive et enregistrez de manière non destructive par défaut.

Stratégie d'exécution :

Sur le chemin par défaut intégré, produisez de nombreux éléments ou variantes en émettant un appel image_gen par élément ou variante demandée.
Sur le chemin de secours CLI explicite, utilisez la sous-commande CLI generate-batch uniquement quand l'utilisateur a explicitement choisi le mode CLI et a besoin de nombreuses invites/éléments.

Supposez que l'utilisateur souhaite une nouvelle image sauf s'il demande clairement de modifier une existante.

Flux de travail

Décidez du mode de haut niveau : intégré par défaut, secours CLI uniquement s'il est explicitement demandé.
Décidez de l'intention : generate ou edit.
Décidez si la sortie est en aperçu uniquement ou destinée à être consommée par le projet actuel.
Décidez de la stratégie d'exécution : élément unique vs appels intégrés répétés vs CLI generate-batch.
Recueillez les entrées à l'avance : prompt(s), texte exact (verbatim), contraintes/liste à éviter, et toute image d'entrée.
Pour chaque image d'entrée, étiquetez explicitement son rôle :
- image de référence
- cible de modification
- entrée d'insertion/style/composition de support
Si la cible de modification se trouve uniquement sur le système de fichiers local et que vous restez sur le chemin intégré, inspectez-la d'abord avec view_image pour que l'image soit disponible dans le contexte de la conversation.
Si l'utilisateur a demandé une photo, une illustration, un sprite, une image de produit, une bannière ou un autre élément de style raster explicitement, utilisez image_gen plutôt que de substituer des espaces réservés SVG/HTML/CSS. Si la demande concerne une icône, un logo ou un graphique UI qui doit correspondre aux éléments SVG/vectoriel/code natifs du dépôt existant, préférez plutôt les modifier directement.
Augmentez le prompt en fonction de la spécificité :
- Si le prompt de l'utilisateur est déjà spécifique et détaillé, normalisez-le dans une spécification claire sans ajouter d'exigences créatives.
- Si le prompt de l'utilisateur est générique, ajoutez une augmentation judicieuse uniquement quand elle améliore matériellement la qualité du résultat.
Utilisez l'outil image_gen intégré par défaut.
Si l'utilisateur choisit explicitement le secours CLI, alors et seulement alors utilisez les docs réservées au secours pour la qualité, input_fidelity, les masques, le format de sortie, les chemins de sortie et la configuration du réseau.
Inspectez les sorties et validez : sujet, style, composition, précision du texte, et invariants/éléments à éviter.
Itérez avec un changement ciblé unique, puis revérifiez.
Pour les travaux en aperçu uniquement, affichez l'image en ligne ; le fichier sous-jacent peut rester au chemin par défaut $CODEX_HOME/generated_images/....
Pour les travaux liés au projet, déplacez ou copiez l'artefact sélectionné dans l'espace de travail et mettez à jour tout code ou référence consommant. Ne laissez jamais un élément référencé par le projet uniquement au chemin par défaut $CODEX_HOME/generated_images/....
Pour les lots, conservez uniquement les finales sélectionnées dans l'espace de travail sauf si l'utilisateur a explicitement demandé de conserver les variantes rejetées.
Signalez toujours le chemin d'accès de sauvegarde final pour tout élément lié à l'espace de travail, plus le prompt final et le mode outil intégré ou secours CLI utilisé.

Augmentation du prompt

Reformatez les prompts des utilisateurs en une spécification structurée et orientée vers la production. Rendez l'objectif de l'utilisateur plus clair et plus exploitable, mais ne rajoutez pas aveuglément des détails.

Traitez cela comme un conseil de mise en forme de prompt, pas un schéma fermé. N'utilisez que les lignes qui aident, et ajoutez une courte ligne supplémentaire étiquetée quand cela améliore matériellement la clarté.

Politique de spécificité

Utilisez la spécificité du prompt de l'utilisateur pour décider du niveau d'augmentation approprié :

Si le prompt est déjà spécifique et détaillé, préservez cette spécificité et ne normalisez/structurez que.
Si le prompt est générique, vous pouvez ajouter une augmentation judicieuse quand cela améliorera matériellement le résultat.

Augmentations autorisées :

conseils de composition ou de cadrage
conseils de niveau de finition ou d'utilisation prévue
conseils pratiques de mise en page
concrétisation raisonnable de la scène qui soutient la demande déclarée

Augmentations non autorisées :

caractères ou objets supplémentaires qui ne sont pas impliqués par la demande
noms de marque, slogans, palettes ou éléments narratifs qui ne sont pas impliqués
placement arbitraire d'un côté à moins que la mise en page environnante ne le soutienne

Taxonomie des cas d'usage (slugs exacts)

Classez chaque demande dans l'un de ces buckets et maintenez le slug cohérent dans les prompts et les références.

Générer :

photorealistic-natural — scènes de style de vie candides/éditoriales avec texture réelle et éclairage naturel.
product-mockup — photos de produits/emballages, images de catalogue, concepts de marchandise.
ui-mockup — maquettes et wireframes d'interfaces d'application/web ; spécifiez la fidélité souhaitée.
infographic-diagram — diagrammes/infographies avec mise en page structurée et texte.
logo-brand — exploration de logo/marque, conviviale pour le vecteur.
illustration-story — bandes dessinées, art de livres pour enfants, scènes narratives.
stylized-concept — art de concept axé sur le style, rendus 3D/stylisés.
historical-scene — scènes exactes au niveau historique/connaissances du monde.

Modifier :

text-localization — traduire/remplacer le texte dans l'image, préserver la mise en page.
identity-preserve — essai, personne dans une scène ; verrouiller le visage/corps/pose.
precise-object-edit — supprimer/remplacer un élément spécifique (y compris les swaps intérieurs).
lighting-weather — modifications uniquement de l'heure du jour/saison/atmosphère.
background-extraction — arrière-plan transparent / découpe propre.
style-transfer — appliquer le style de référence tout en changeant le sujet/scène.
compositing — insertion/fusion multi-images avec éclairage/perspective correspondants.
sketch-to-render — art de ligne/dessin vers rendu photoréel.

Schéma de prompt partagé

Utilisez la spécification étiquetée suivante comme échafaudage de prompt partagé pour les deux modes de haut niveau :

Use case: <slug de taxonomie>
Asset type: <où l'élément sera utilisé>
Primary request: <prompt principal de l'utilisateur>
Input images: <Image 1 : rôle ; Image 2 : rôle> (optionnel)
Scene/backdrop: <environnement>
Subject: <sujet principal>
Style/medium: <photo/illustration/3D/etc>
Composition/framing: <large/gros plan/vue de haut ; placement>
Lighting/mood: <éclairage + ambiance>
Color palette: <notes de palette>
Materials/textures: <détails de surface>
Text (verbatim): "<texte exact>"
Constraints: <doit garder/doit éviter>
Avoid: <contraintes négatives>

Notes :

Asset type et Input images sont l'échafaudage du prompt, pas des drapeaux CLI dédiés.
Scene/backdrop fait référence au cadre visuel. Ce n'est pas la même chose que le paramètre CLI background du secours, qui contrôle le comportement de transparence de la sortie.
Les notes d'exécution réservées au secours telles que Quality:, Input fidelity:, les masques, le format de sortie et les chemins de sortie appartiennent au chemin CLI explicite uniquement. Ne les traitez pas comme des arguments d'outil image_gen intégré.

Règles d'augmentation :

Gardez-le court.
Ajoutez uniquement les détails nécessaires pour améliorer matériellement le prompt.
Pour les modifications, énumérez explicitement les invariants (modifier uniquement X ; garder Y inchangé).
Si un détail critique manque et bloque le succès, posez une question ; sinon, procédez.

Exemples

Exemple de génération (image hero)

Use case: product-mockup
Asset type: landing page hero
Primary request: une image hero minimaliste d'une tasse à café en céramique
Style/medium: photographie de produit épurée
Composition/framing: composition large avec espace négatif utilisable pour le texte de la page si nécessaire
Lighting/mood: éclairage studio doux
Constraints: pas de logos, pas de texte, pas de filigrane

Exemple de modification (invariants)

Use case: precise-object-edit
Asset type: remplacement d'arrière-plan de photo de produit
Primary request: remplacer uniquement l'arrière-plan par un dégradé de coucher de soleil chaud
Constraints: modifier uniquement l'arrière-plan ; garder le produit et ses bords inchangés ; pas de texte ; pas de filigrane

Meilleures pratiques de prompting

Structurez le prompt comme scène/toile de fond -> sujet -> détails -> contraintes.
Incluez l'utilisation prévue (publicité, maquette UI, infographie) pour définir le mode et le niveau de finition.
Utilisez le langage caméra/composition pour le photoréalisme.
N'utilisez les espaces réservés SVG/vectoriel que si l'utilisateur a explicitement demandé une sortie vectorielle ou un espace réservé non-image.
Citez le texte exact et spécifiez la typographie + le placement.
Pour les mots délicats, épellez-les lettre par lettre et exigez un rendu verbatim.
Pour les entrées multi-images, référencez les images par index et décrivez comment elles doivent être utilisées.
Pour les modifications, répétez les invariants à chaque itération pour réduire la dérive.
Itérez avec des suivi à changement unique.
Si le prompt est générique, ajoutez uniquement le détail supplémentaire qui aidera matériellement.
Si le prompt est déjà détaillé, normalisez-le au lieu de l'étendre.
Pour le secours CLI explicite uniquement, consultez references/cli.md et references/image-api.md pour les conseils sur quality, input_fidelity, les masques, le format de sortie et le chemin de sortie.

Plus de principes partagés par les deux modes : references/prompting.md. Les spécifications de copier/coller partagées par les deux modes : references/sample-prompts.md.

Conseils par type d'élément

Les modèles de type d'élément (éléments de site web, éléments de jeu, wireframes, logo) sont consolidés dans references/sample-prompts.md.

Mode CLI de secours uniquement

Conventions temp et sortie

Ces conventions s'appliquent uniquement au secours CLI explicite. Elles ne décrivent pas le comportement de sortie de image_gen intégré.

Utilisez tmp/imagegen/ pour les fichiers intermédiaires (par exemple, lots JSONL) ; supprimez-les une fois terminé.
Écrivez les artefacts finaux sous output/imagegen/.
Utilisez --out ou --out-dir pour contrôler les chemins de sortie ; gardez les noms de fichiers stables et descriptifs.

Dépendances

Préférez uv pour la gestion des dépendances dans ce dépôt.

Paquet Python requis :

uv pip install openai

Optionnel pour la réduction d'échelle uniquement :

uv pip install pillow

Note de portabilité :

Si vous utilisez la compétence installée en dehors de ce dépôt, installez les dépendances dans cet environnement avec son gestionnaire de paquets.
Dans les environnements gérés par uv, uv pip install ... reste le chemin préféré.

Environnement

OPENAI_API_KEY doit être défini pour les appels API en direct.
Ne demandez pas à l'utilisateur OPENAI_API_KEY quand vous utilisez l'outil image_gen intégré.
Ne demandez jamais à l'utilisateur de coller la clé complète dans le chat. Demandez-lui de la définir localement et confirmez quand il est prêt.

Si la clé manque, donnez ces étapes à l'utilisateur :

Créez une clé API dans l'interface utilisateur de la plateforme OpenAI : https://platform.openai.com/api-keys
Définissez OPENAI_API_KEY comme variable d'environnement sur leur système.
Proposez de les guider dans la définition de la variable d'environnement pour leur système d'exploitation/shell si nécessaire.

Si l'installation n'est pas possible dans cet environnement, dites à l'utilisateur quelle dépendance manque et comment l'installer dans leur environnement actif.

Notes du mode script

Commandes CLI + exemples : references/cli.md
Référence rapide des paramètres API : references/image-api.md
Approbations réseau / paramètres sandbox pour le mode CLI : references/codex-network.md

Carte de référence

references/prompting.md : principes de prompting partagés pour les deux modes.
references/sample-prompts.md : recettes de prompts partagées copier/coller pour les deux modes.
references/cli.md : utilisation du CLI de secours via scripts/image_gen.py.
references/image-api.md : référence des paramètres API/CLI de secours.
references/codex-network.md : dépannage réseau/sandbox de secours pour le mode CLI.
scripts/image_gen.py : implémentation du CLI de secours. Ne la chargez ou ne l'utilisez que si l'utilisateur choisit explicitement le mode CLI.