akenoowww/art-direct-imagegen

Art-Direct ImageGen

Créez l'idée visuelle avant de demander à imagegen de la rendre. Gardez le problème précis et l'espace de solution ouvert.

Le principe fondamental est coque radicale, sémantique conservatrice :

• verrouillez le contenu, la fonction, les tâches utilisateur, les états requis et le texte critique ;
• guidez la sensation, la tension, la hiérarchie et une thèse conceptuelle ;
• laissez ouverts la composition, le système visuel, la géométrie, les nuances de palette, le caractère typographique et les détails de support, sauf si le concept en dépend vraiment.

Ne transformez pas une demande de créativité en une spécification de rendu plus longue.

Gardez deux artefacts séparés tout au long du flux de travail :

• contrat global : l'inventaire complet du contenu, des fonctions, des actions, des états et de la copie exacte fournis dans l'ensemble des livrables ;
• brief de sortie courante : uniquement ce qui doit être visible dans l'actif ou l'état en cours de génération.

Ne collez jamais le contrat global dans une invite imagegen.

Charger les références pertinentes

• Lisez references/concept-planning.md pour toute demande originale, esthétique ou à fort jugement.
• Lisez également references/flow-architecture.md pour les interfaces utilisateur, les informations denses, les multiples écrans, les modales, les tiroirs, les onglets ou les états connexes.
• Lisez references/prompt-compilation.md immédiatement avant de préparer les invites pour imagegen.
• Lisez references/evaluation.md avant de juger les résultats générés ou de décider comment itérer.

Choisir le flux de travail

Utilisez le flux de travail complet de direction artistique lorsque l'utilisateur demande de l'interprétation, de l'originalité, un redesign conceptuel, du goût, de la mémorabilité, une nouvelle direction visuelle ou plusieurs sorties connectées.

Utilisez directement la compétence système imagegen lorsque l'utilisateur a déjà fixé le résultat souhaité et n'a besoin que d'exécution, comme changer un objet, tout préserver sauf une modification nommée, extraire un arrière-plan ou rendre un actif étroitement spécifié.

Si l'utilisateur fournit une image, étiquetez son rôle avant la planification :

• référence fonctionnelle/de contenu : préservez les tâches, les informations, les actions et les états, mais pas la mise en page ni le style ;
• référence de style : empruntez des qualités visuelles nommées, pas le contenu ni la composition ;
• cible d'édition : préservez tout sauf les modifications explicitement autorisées ;
• ancrage du système visuel : maintenez le langage établi cohérent sur les sorties ultérieures.

Ne traitez jamais silencieusement une référence fonctionnelle comme une cible d'édition.

Flux de travail

1. Extraire le contrat global

Séparez la demande en quatre couches :

• VERROU : fonctions exactes, contenu, tâches utilisateur, plateforme, actions requises, états, faits de marque et texte littéral.
• GUIDE : sensation souhaitée, hiérarchie, tension visuelle, posture du produit et qualité qui doit rester mémorable.
• LIBRE : composition, regroupement, rythme spatial, nuances de palette, caractère typographique, langage matériel, arrière-plan, symboles personnalisés et détails de support.
• INTERDIT : fonctionnalités ou copies inventées, affordances trompeuses, clichés connus, décoration hors de propos et interdictions explicites de l'utilisateur.

Ne promouvez pas la mise en page source, les limites de carte actuelles, les formes de composants ou les limites de page dans VERROU sauf si l'utilisateur les exige explicitement.

Préservez l'importance sémantique et la signification du flux de travail, pas la hiérarchie visuelle de la source. Enregistrez les actions, déclencheurs, surfaces ouvertes et états système séparément. N'inférez jamais un état, une confirmation ou une surface ouverte non pris en charge à partir d'une étiquette d'action ou de déclencheur seule.

Pour les interfaces denses, inventorier chaque bloc de contenu et état significatif avant d'idéer. L'ensemble complet des informations doit survivre à travers l'ensemble de sorties, pas sur chaque sortie et pas nécessairement sur le premier écran.

2. Interrompre la réponse évidente

Avant de choisir une direction visuelle, nommez en privé l'achèvement prévisible le plus proche spécifique au support et mettez-le en quarantaine : une composition standard, un traitement de surface à la mode, un symbolisme générique, un archétype de mise en page familier ou une étiquette de style collée sur une structure inchangée.

N'utilisez pas une liste d'interdiction comme substitut à un concept. Un concept explique ce qui organise le travail ; les interdictions ne suppriment que les modes d'échec.

3. Diverge par mécanisme

Développez au moins trois candidats conceptuels sémantiquement différents pour une demande créative substantielle. Ils doivent différer par la logique d'organisation, pas simplement par la palette, la police ou la décoration.

Pour chaque candidat, définissez uniquement :

1. une thèse d'une phrase ;
2. la sensation visée ;
3. le principal geste structurel ou compositionnel ;
4. comment la fonction/contenu requis vit à l'intérieur ;
5. pourquoi ce n'est pas un modèle transférable ;
6. son risque le plus fort d'utilisabilité ou de cohérence ;
7. ce qui reste intentionnellement libre pour le moteur de rendu.

N'exposez pas toute la liste interne sauf si la comparaison profite à l'utilisateur. Le but est la pression de sélection, pas un portfolio.

4. Sélectionner dialectiquement

Appliquez un court passage thèse/antithèse/synthèse à chaque candidat sérieux :

• Thèse : pourquoi le concept est mémorable et adapté à cette tâche spécifique.
• Antithèse : comment il pourrait devenir décoratif, confus, dérivé ou impossible à implémenter.
• Synthèse : si la faiblesse peut être supprimée sans tuer le concept.

Rejetez d'abord les candidats qui perdent du contenu, de la fonction, de la lisibilité, de la découvrabilité ou de l'implémentabilité. Parmi les survivants, choisissez la direction avec le point de vue le plus clair et la résistance au transfert la plus forte. Ne faites pas la moyenne et ne fusionnez pas tous les candidats en un style fourre-tout.

5. Planifier l'ensemble de sorties

Pour un actif indépendant unique, passez à la fiche concept.

Pour une interface utilisateur dense ou des états connectés :

1. classifiez les informations comme primaires, secondaires ou contextuelles ;
2. choisissez le défilement, les onglets, le tiroir, la modale ou l'écran séparé selon la signification de l'interaction ;
3. mappez chaque élément source vers une destination ;
4. définissez le manifeste de sortie minimum ;
5. assurez-vous que chaque surface cachée a un déclencheur découvrable dans un état antérieur ;
6. générez chaque écran ou état requis avec un appel imagegen séparé ;
7. utilisez la première sortie acceptée comme ancrage du système visuel pour les sorties ultérieures.

Ne demandez pas plusieurs écrans finaux sous forme d'un collage sauf si l'utilisateur veut explicitement un tableau de comparaison. Voir references/flow-architecture.md.

Ne traitez pas la visibilité source comme une priorité sémantique. Un formulaire complet, une provenance ou un historique détaillé, et un long contenu de support ne sont pas primaires simplement parce que la source les a affichés à côté de la tâche centrale. Ne gardez que les informations requises immédiatement ou comparées simultanément sur la sortie 1.

Avant la compilation du prompt, marquez chaque élément de l'inventaire comme MAINTENANT, AILLEURS ou NON PRIS EN CHARGE pour la sortie courante. Ne continuez pas tant qu'un élément n'a pas de destination.

Utilisez NON PRIS EN CHARGE uniquement pour le contenu, les données, les résultats ou le comportement absents. Un nouvel onglet, tiroir, modale, région extensible ou continuation de défilement qui ne fait que relocaliser le contenu fourni, ne crée pas de nouvelles données ou résultats et a un point d'entrée découvrable est une architecture de l'information plutôt qu'une fonction de produit inventée. Introduisez et rendez cet état séparément lorsque la densité l'exige.

Rejetez le plan de sortie avant génération lorsqu'il combine une seule fenêtre, un long texte principal, des formulaires complets ou des détails contextuels, une typographie lisible et un espace négatif généreux. Divisez plutôt l'ensemble de sorties. Un état décrit comme par défaut, fermé ou non ouvert ne doit pas montrer simultanément le contenu intérieur de ses surfaces fermées.

Exigez plusieurs sorties lorsque le contenu principal long entre en compétition avec un formulaire indépendant complet et des régions de support détaillées. Ne dérogez pas à cela parce que le canevas d'origine est grand ou techniquement lisible.

6. Distiller une fiche concept

Avant d'écrire le prompt du moteur de rendu, figez uniquement :

• la thèse conceptuelle d'une phrase ;
• la sensation visée et la tension visuelle ;
• un geste signature et au maximum deux gestes de support ;
• la liste VERROU ;
• une courte liste INTERDIT ;
• la sortie/l'état en cours de rendu maintenant.

Si la fiche contient des coordonnées exactes, un arbre de composants complet, de nombreuses valeurs de couleur, chaque rayon de coin ou des instructions pour chaque élément secondaire, il s'agit probablement d'une spécification de mise en page plutôt que d'une direction artistique. Supprimez les détails qui ne portent pas le concept ou ne protègent pas la fonctionnalité.

Gardez le geste signature dans la planification. Traduisez-le d'un niveau vers le haut pour le moteur de rendu : décrivez la relation organisatrice, le résultat perceptif ou la tension, pas sa direction exacte, sa position, son nombre, sa forme ou sa topologie, sauf si l'utilisateur a explicitement fixé cette géométrie.

7. Compiler les invites par actif

Préparez une invite pour chaque actif ou état distinct. Incluez uniquement le rôle de la source, l'objectif de sortie courante, l'intention conceptuelle non géométrique, les verrous de sortie courante, la latitude créative et les quelques éléments à éviter qui comptent.

Ne collez pas tout le raisonnement de découverte, la carte de couverture, les concepts rejetés ou la liste globale des verrous dans l'invite. Ne demandez pas au moteur de rendu de littéraliser chaque indication. Mettez uniquement le texte court critique requis dans cette sortie dans l'invite ; gardez la copie longue dans la référence source, la carte de couverture ou la couche d'implémentation. Répartissez-la sur les sorties plutôt que de forcer une densité illisible.

Échouez la compilation du prompt et revenez à la planification des sorties lorsque :

• l'invite décrit plus d'un état ou inclut du contenu AILLEURS ;
• l'invite dit de préserver chaque élément fourni dans une sortie au lieu de nommer le sous-ensemble de sortie courante ;
• l'invite porte un long catalogue d'étiquettes ou de régions de contenu qui auraient dû être distribuées ;
• la latitude créative est déclarée après que la composition ou la topologie a déjà été fixée ;
• une demande pour une seule fenêtre exige également toute la copie longue, tous les formulaires complets et une lisibilité spacieuse ;
• la liste d'évitement devient un catalogue anti-style générique ;
• l'actif est appelé livrable ou prêt pour la production plutôt qu'une direction visuelle haute fidélité.

Utilisez les recettes dans references/prompt-compilation.md.

8. Invoquer le flux de travail d'image système

Suivez la compétence imagegen système installée pour le choix de l'outil, la gestion des images d'entrée, les chemins de sauvegarde, la transparence et la livraison. Utilisez l'outil de génération d'images intégré par défaut.

Pour plusieurs sorties distinctes, émettez un appel par actif ou état. Après avoir accepté la première sortie, fournissez-la comme référence du système visuel pour les sorties ultérieures tout en répétant les invariants critiques.

9. Critiquer l'image réelle

Jugez la sortie, pas l'élégance du prompt. Appliquez references/evaluation.md.

Utilisez deux types d'itération :

• Échec local : faites un changement ciblé, reformulez les invariants et préservez le concept accepté.
• Échec structurel ou générique : revenez à la ramification conceptuelle ou à l'architecture des sorties. N'ajoutez pas plus d'adjectifs, d'interdictions, de coordonnées, de références de style, de régions nommées ou de topologie à un concept échoué.

Maintenez une liberté créative monotone à travers les tentatives structurelles : un nouveau prompt du moteur de rendu ne doit pas prescrire plus de mise en page, de géométrie, d'orientation, de nombre, de superposition ou de placement que le prompt échoué. Changez plutôt le concept sémantique. Si le même concept donne un résultat transférable ou générique deux fois, jetez-le et sélectionnez un autre candidat issu d'un autre mécanisme de divergence.

Ne sauvez jamais un concept illisible en détaillant son wireframe. Si le concept ne devient visible qu'après que des plans exacts, des zones, des portions exposées, des connecteurs ou un ordre spatial sont prescrits, le concept est inadapté à ce flux de travail. La précision n'est autorisée que pour une édition locale après que le système visuel a déjà passé la porte créative.

Arrêtez-vous lorsque la sortie est fonctionnellement honnête, conceptuellement lisible, cohérente, distinctive et utilisable pour son objectif prévu. Rapportez le concept sélectionné, les sorties générées et l'ensemble final de prompts comme requis par le flux de travail d'image système.

Garde-fous non négociables

• Ne confondez jamais détail et créativité.
• Ne laissez jamais le premier concept plausible gagner sans opposition.
• N'appelez jamais des changements de palette ou des changements d'étiquettes de style des concepts indépendants.
• Pour les sorties interactives, ne cachez jamais les informations primaires uniquement pour rendre un écran plus propre.
• N'inventez jamais de contenu, de métriques, d'états ou de contrôles pour remplir une composition.
• Ne rendez jamais chaque élément inhabituel ; concentrez l'originalité dans un geste décisif au niveau du système.
• Pour les sorties interactives denses, ne forcez jamais toutes les informations dans une seule fenêtre simplement parce que la source utilisait une page.
• Ne montrez jamais le contenu d'une surface fermée dans un état par défaut ou non ouvert.
• Ne laissez jamais un prompt du moteur de rendu porter l'inventaire complet du contenu global.
• Ne classifiez jamais chaque bloc source visible comme primaire sans prouver une dépendance de tâche simultanée.
• N'appelez jamais une relocalisation de présentation uniquement une fonction inventée.
• Ne revendiquez jamais une liberté créative après avoir prescrit la composition complète.
• Ne faites jamais une tentative structurelle plus spécifique géométriquement que le prompt échoué.
• Ne gardez jamais le même concept après deux échecs structurels génériques.
• Traitez les images d'interface utilisateur générées comme une direction visuelle, pas une preuve d'implémentation, jusqu'à ce qu'elles soient construites et testées.
• Pour les sorties bitmap contenant du texte, ne promettez jamais un texte long parfait. Répartissez le contenu, vérifiez les étiquettes critiques et préservez la copie exacte dans les artefacts d'implémentation lorsque la fidélité compte.