illuminatedworm/terrarium-tavern

Constructeur d'Applications Front-End

Utilisez cette compétence pour créer des applications front-end soignées, des tableaux de bord, des jeux, des sites web créatifs, des sections hero, des refontes et toute autre UI visuellement pilotée. Agissez d'abord en tant que designer front-end sénior, puis en tant qu'ingénieur implémentant un cahier des charges de design approuvé.

Standard de Base

Les deux priorités de cette compétence surpassent tout le reste :

1. Créez d'abord suffisamment de concepts de design générés par image, de haute qualité : propres, aérés, distinctifs, complets, lisibles, spécifiques à chaque section si nécessaire, et non répétitifs par défaut.
2. Ne vous arrêtez pas tant que le design accepté et l'implémentation dans le navigateur ne correspondent pas à 10/10. Continuez à corriger les écarts visuels, d'interaction, de responsive, d'assets et de typographie jusqu'à ce qu'une comparaison view_image soit validée par une agence.

Règles Strictes

1. Utilisez Image Gen pour le concept visuel, sauf si l'utilisateur refuse explicitement ou si la tâche est une petite correction UI dans un système de design existant.
2. Concevez l'ensemble de la surface demandée avant de coder. Pour une page entière, une application, un tableau de bord, un jeu ou une interface produit, un en-tête ou un concept hero ne suffit pas. Pour les sites multi-sections et les longues pages d'atterrissage, privilégiez des concepts coordonnés section par section, plus une vue d'ensemble optionnelle pour le rythme, plutôt qu'une grande image qui perd les détails. Pour les applications, tableaux de bord, jeux ou surfaces produits compactes, générez d'abord l'écran principal complet ainsi que tous les états, responsives ou concepts d'assets nécessaires.
3. Dans Codex, par défaut, pour les sites multi-sections, générez une capture d'écran Image Gen fraîche, grande et lisible par section majeure. Si la demande comporte 1 à 10 sections, attendez-vous à environ 1 à 10 images de section principales. Générez des captures d'écran supplémentaires de sections/détails chaque fois que le texte, les boutons, l'anatomie des cartes, la typographie, l'espacement ou les couleurs sont trop petits pour être extraits. Ne recadrez pas et ne zoomez pas une ancienne image pleine page comme référence principale ; régénérez une image de section ou de détail autonome qui préserve le même système de design.
4. En mode Plan, générez d'abord le design, puis utilisez request_user_input pour obtenir l'approbation du design avant de planifier les détails d'implémentation.
5. Une fois accepté, le concept est un cahier des charges de design de production. Aucune liberté créative pendant l'implémentation : ne réinterprétez pas la mise en page, le contenu visible, la hiérarchie, le modèle de conteneur, le style, l'imagerie, la densité ou les sections, sauf si l'utilisateur l'approuve ou qu'un blocage concret l'exige. Les heuristiques de design générales ne remplacent jamais le concept accepté.
6. La barre de complétion est une implémentation fidèle validée par l'agence : une fidélité 10/10 au cahier des charges accepté, plus un code de qualité production. Si l'UI rendue dans le navigateur recevrait des commentaires de revue de design, continuez à la corriger.
7. Avant de coder, construisez un petit système de design à partir de l'image acceptée : tokens, typographie, familles de composants, variantes, espacement, traitement des icônes et règles de conteneur. Incluez à la fois la typographie de contenu et la typographie chrome UI pour les outils, éditeurs et tableaux de bord. Implémentez à partir de ce système pour que les éléments répétés restent cohérents.
8. Pour les nouvelles UI d'applications complexes telles que les tableaux de bord, outils d'administration, éditeurs, outils de données lourdes et surfaces produits multi-panneaux, par défaut, utilisez React + Vite, sauf si l'utilisateur spécifie un autre framework, que le dépôt existant en dicte un, ou que la tâche est explicitement un livrable fichier unique/statique.
9. Les étiquettes hero (eyebrow, kicker, pretitle, badge, ou pill) au-dessus du titre principal sont interdites par défaut. Utilisez-en une uniquement si l'utilisateur l'a explicitement demandée ou si le design accepté/de référence en contient déjà une.
10. Vérifiez d'abord dans l'extension Navigateur / navigateur intégré. Utilisez Playwright Chromium uniquement lorsque le Navigateur/IAB est indisponible ou peu fiable, et indiquez la raison du repli.
11. La remise finale est bloquée jusqu'à ce que vous utilisiez view_image à la fois sur le concept accepté et sur la dernière capture d'écran du navigateur. Cela ne peut pas être sauté ou remplacé par une simple inspection du navigateur. Jugez la paire directement : celle-ci est-elle une implémentation fidèle validée par une agence, et une excellente agence de design hautement qualifiée signerait-elle cette implémentation exacte du design accepté ? Si non, continuez à corriger.
12. Supprimez les artefacts QA temporaires avant la remise, sauf si l'utilisateur ou la tâche demande explicitement de les conserver.

Coordination avec les Autres Compétences Installées

Cette compétence possède le concept visuel et l'implémentation front-end fidèle. Utilisez les autres compétences installées lorsque l'application a besoin de capacités en dehors du design front-end. La configuration du fournisseur ne doit pas bloquer le concept Image Gen, le travail UI statique ou la revue de design qui n'utilise pas un comportement basé sur un fournisseur, mais l'implémentation et la vérification d'un comportement basé sur un fournisseur doivent se coordonner via la compétence installée pour cette capacité. Évitez les instructions de configuration factices lorsqu'une autre compétence installée couvre cette configuration.

Pour la sortie générée par IA/modèle, utilisez openai-developers:openai-platform-api-key lorsque c'est disponible, sauf si l'utilisateur nomme un autre fournisseur ou dit explicitement de ne pas utiliser OpenAI. Lorsque cette compétence est disponible, utilisez toujours son flux d'identification au lieu de clés factices, de variables d'environnement factices ou d'instructions manuelles de configuration de clé API.

Workflow Image Gen

Lisez et suivez la compétence @imagegen installée. Pour les conseils spécifiques aux briefs de sites web, utilisez references/imagegen-website-concepts.md.

Avant d'appeler Image Gen :

• Copiez les exigences concrètes de l'utilisateur dans le brief : but du produit/page, public, sections ou états requis, workflow, contenu fourni, étiquettes de navigation, étiquettes CTA, champs de données, médias requis, besoins responsives et contraintes d'implémentation.
• Demandez la surface complète demandée : page entière, écran d'application, tableau de bord, écran de jeu ou ensemble coordonné de sections/états. Si le livrable est plus qu'un hero, dites que le concept doit inclure les sections aval, les états ou la continuation responsive. Si le nombre de sections est connu ou implicite, nommez chaque section/état qui nécessite sa propre capture d'écran de concept.
• Répétez les contraintes d'implémentation : texte et contrôles UI natifs du code, assets produit/arrière-plan entièrement rendus avec leur propre texte et marque le cas échéant, assets séparables, familles de composants réutilisables, modèle de conteneur intentionnel, pas de grilles de cartes par défaut, pas de sourcils/kickers/badges/pills hero inventés, et implémentation pratique HTML/CSS/component.
• Préservez l'architecture d'information du contenu, des captures d'écran ou des applications existantes de l'utilisateur. Ne laissez pas Image Gen inventer des sections non liées, des métriques factices, de nouvelles revendications produit, des tableaux de bord supplémentaires, une nouvelle navigation ou une histoire produit différente.
• Pour les sites web multi-sections ou les longues pages d'atterrissage, par défaut, générez une image de concept coordonnée par section majeure. Utilisez une vue d'ensemble optionnelle uniquement pour la structure et le rythme ; ne vous fiez jamais à un grand tableau compressé qui rend le texte, les détails des boutons, la structure des cartes, l'espacement ou la typographie difficiles à analyser.
• Pour les applications denses, tableaux de bord, éditeurs, surfaces produit et sections complexes, générez des concepts d'état ou de détail séparés pour les zones qui deviendraient illisibles dans une seule image plein écran : tableaux, barres latérales, inspecteurs, modaux, barres d'outils, graphiques, formulaires, cartes, blocs de tarification, témoignages ou modules médias.
• Si une capture d'écran de concept est trop petite, floue, recadrée, encombrée ou ambiguë pour l'implémentation, générez une nouvelle capture d'écran de section/état/détail autonome avant de coder. Conservez la même palette, l'ambiance typographique, la famille de composants, le traitement des assets, la densité et l'ordre des sections. Ne recadrez, ne découpez, ne zoomez et ne réutilisez pas une petite partie d'une image antérieure comme source de vérité.
• Pour les jeux, planifiez un passage d'assets Image Gen dédié en plus du concept : sprites de personnage/état transparents ou feuille de sprites, tuiles de terrain/plateforme, objets de collection, dangers, objets d'objectifs/de points de contrôle, accessoires et 2-3 couches de parallaxe/fond lorsque l'environnement a de la profondeur. Le texte HUD, le score, les contrôles, la physique et les collisions restent natifs du code.

Rejetez ou itérez sur les concepts qui sont header-only pour une demande de surface complète, encombrés, génériques, répétitifs, sous-spécifiés, illisibles, trop décorés, hors spécifications avec des sourcils/kickers/badges/pills hero non explicitement demandés ou présents dans la référence, ou non pratiques à implémenter fidèlement.

Barre de Qualité de Design

Le concept doit ressembler à une maquette produit professionnelle réalisée par un designer produit sénior :

• Une idée créative claire ou un point de vue visuel.
• Un premier viewport fort avec une offre claire, un signal produit et une action principale.
• Un rythme de page entier : les sections, états, transitions et vues mobiles semblent conçus comme un seul système, sans piles de cartes répétitives ou formules de section répétées.
• Un flux cohérent de section à section : connectez les sections avec un espacement partagé, une palette, un rythme typographique, un traitement des médias et des transitions subtiles, sans inventer de nouveaux composants UI majeurs.
• Une excellente typographie : hiérarchie claire, échelle, poids, hauteur de ligne, traitement des étiquettes et texte de contrôle/chrome qui ne revient jamais à la taille par défaut du navigateur.
• Un espace blanc intentionnel et une densité ; pas de cartes de remplissage, d'étiquettes hero eyebrow/kicker, de pills, de badges, de métriques factices ou de rangées d'icônes, sauf si explicitement demandés ou présents dans le design accepté.
• Plus simple par défaut : utilisez moins d'éléments visuels, plus forts, au lieu de remplir la page d'illustrations, d'iconographie, de widgets décoratifs ou de chrome UI complexe.
• Un système visuel cohérent : palette, espacement, rayon, bordures, ombres, dégradés, style d'icône, imagerie et géométrie des composants.
• La fidélité des icônes compte lorsque des icônes sont présentes. Faites correspondre la métaphore des icônes, l'épaisseur du trait, le style de remplissage, la forme des coins, la taille, la couleur, l'alignement et l'espacement du design accepté, au lieu d'échanger avec des icônes génériques voisines.
• La fidélité des couleurs est obligatoire. Faites correspondre les couleurs réelles d'arrière-plan, de surface, de texte, de bordure, d'ombre et d'accent du design accepté ; si le design utilise un fond blanc, utilisez du blanc plutôt que du crème, ivoire, beige, gris chaud ou tout autre substitut blanc adouci.
• Le traitement des médias hero doit correspondre au design accepté. Si l'image hero n'a pas de superposition de couleur ou de teinte dans le concept, l'implémentation ne doit pas en ajouter. Utilisez des fondus de bord, des masques ou des dégradés d'arrière-plan uniquement pour fondre les bords de l'image dans la page ; ne lavez pas l'image avec une superposition de couleur.
• Des assets générés de haute qualité pour les logos, marques, imageries hero, rendus produit, scènes d'arrière-plan, illustrations, textures, affiches, avatars, états vides et sprites/tuiles/couches d'arrière-plan de jeu. Les assets produit/arrière-plan doivent être entièrement rendus avec une marque cohérente et un texte dans l'image lorsque ce texte appartient à l'asset.
• Un mouvement intentionnel qui clarifie la hiérarchie, révèle un état ou rend le produit tangible.
• Un contenu spécifique et non générique lorsque l'utilisateur n'a pas fourni de contenu exact.

Par défaut, privilégiez une créativité propre, aérée et de bon goût à 7/10 : suffisamment distinctive pour sembler conçue, suffisamment retenue pour être construite, et non répétitive. Interprétez « propre » comme édité et lisible, pas vide ou stérile.

Directions Visuelles par Défaut

Utilisez ces valeurs par défaut lorsque l'utilisateur n'a pas donné de direction artistique plus forte. Adaptez-les au type de produit au lieu de forcer chaque application dans un style de site marketing.

• Base : environ 7/10 de créativité, densité faible à moyenne, espacement généreux, clarté d'implémentation élevée, haute discipline typographique et moments menés par l'image lorsque le domaine bénéficie de visuels réels.
• Avant de générer des concepts, choisissez une direction visuelle cohérente : un paradigme thématique, un caractère d'arrière-plan, un caractère typographique, une architecture de hero ou d'écran principal, un rythme de section/application, 2 à 4 motifs de composants signature et 1 à 2 signaux de mouvement. Engagez-vous sur la combinaison pour que le design semble intentionnel plutôt qu'un modèle générique.
• Hero ou premier viewport : gardez un point focal évident, un titre court et lisible ou une tâche principale, un texte de support retenu, une action principale visible et suffisamment d'espace négatif pour fonctionner sur un petit ordinateur portable. Ne surchargez pas l'ouverture avec des statistiques, des chips, des badges, des contrôles factices ou des mini-panneaux concurrents.
• Simplicité de l'en-tête : par défaut, une marque propre, une navigation essentielle et une action ou un contrôle principal. Évitez une navigation lourde en icônes, des boutons supplémentaires, des barres de recherche, des widgets d'état, des contrôles segmentés, des illustrations décoratives ou un chrome produit dense dans l'en-tête, sauf si l'utilisateur le demande explicitement ou que le workflow produit l'exige.
• Économie visuelle : préférez un ou deux moments d'image ou d'illustration de haute qualité à de nombreux petits visuels décoratifs. Utilisez l'iconographie uniquement lorsqu'elle clarifie la navigation, les contrôles ou le sens du produit.
• Discipline des conteneurs : évitez les cartes imbriquées, les grands enveloppes arrondies autour de chaque section, les grilles bento/cartes par défaut et les tableaux de bord sur-encadrés, sauf si le concept ou le type de produit en a vraiment besoin. Préférez les mises en page ouvertes, les bandes, les rails, les listes, les tableaux, les toiles ou un seul geste de cadrage intentionnel.
• Rythme des sections : les longues pages doivent varier la densité, le rapport image-texte, l'alignement, l'échelle, l'espace blanc et le tempo visuel tout en conservant un système de marque cohérent. Ne répétez pas le même bloc centré ou la formule texte à gauche/carte à droite sur toute la page.
• Continuité des sections : lorsque plusieurs concepts de section doivent devenir une seule page, utilisez du tissu conjonctif du système de design existant : gouttières, bandes, alignement, typographie répétée, cadres médias récurrents, rythme de couleur et petits changements d'espacement de transition. N'inventez pas de nouveaux carrousels majeurs, accordéons, cartes de tarification, tableaux de bord, formulaires, systèmes de navigation, grilles de fonctionnalités ou autres familles de composants, sauf si l'utilisateur les a demandés ou que les concepts acceptés les montrent.
• Cadrage des médias : l'imagerie générée doit généralement se trouver dans des cadres clairs et faciles à implémenter, avec des ratios d'aspect stables, une logique de recadrage cohérente, un rayon, des ombres et un espacement. Évitez les tailles d'image aléatoires ou le chaos de collage, sauf si l'utilisateur demande explicitement cette direction.
• Contraintes UI : les petites étiquettes, les pills utilitaires, les marqueurs pseudo-système, les métriques factices et le jargon de tableau de bord décoratif sont autorisés uniquement lorsqu'ils clarifient le produit. S'ils sont simplement du remplissage visuel, supprimez-les avant l'acceptation.

Mode Révision de Concept

À utiliser uniquement lorsque l'utilisateur demande à générer des concepts d'abord, à examiner des options ou à attendre l'approbation.

• Générez et montrez le concept.
• Itérez jusqu'à ce que l'utilisateur approuve.
• N'implémentez pas pendant que l'utilisateur examine encore.
• Une fois approuvé, traitez le concept comme le cahier des charges actif

… [tronqué pour la traduction]