Communitygithub.com

n0ctx/tavern-aesthetic

Conception front-end immersive de style narrative pour pages et interfaces de type tavern.

Qu'est-ce que tavern-aesthetic ?

Cette compétence permet de produire une interface utilisateur qui se lit comme un artefact issu du monde narratif, et non comme un tableau de bord relooké ou un assemblage générique d'éléments de jeu. Elle couvre la conception visuelle et la méthode d'implémentation, sans dépendre de SillyTavern, de plugins ou de frameworks spécifiques. Le principe central est que chaque choix visible doit être intentionnel et que chaque espace visible respecte le même niveau de qualité. La compétence se base sur des références détaillées (connaissances de conception, flux de travail, sources d'actifs et recherche) pour guider les décisions de conception, du simple composant au système multi-écrans complexe. Elle impose des règles strictes anti-dérive, comme un registre de conception unique et des étapes de validation visuelle par capture d'écran, garantissant la cohérence et la qualité tout au long du projet.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/n0ctx/skills/tree/HEAD/skills/tavern-aesthetic

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Tavern Aesthetic — Conception Front-end Narrative Immersive

Ce que cette compétence produit

Une interface utilisateur fonctionnelle qui se lit comme un artefact issu du monde de l'histoire — pas un tableau de bord relooké ni un tas d'accessoires génériques de HUD de jeu. La barre est la carte front-end polie : un coup d'œil identifie l'œuvre, chaque surface partage une seule direction artistique, les détails sont finis et l'interaction semble naturelle.

La qualité n'égale pas la complexité. La qualité signifie que chaque choix visible est intentionnel et que chaque région visible atteint le même niveau de qualité.

Cette compétence couvre la conception visuelle et la méthode d'implémentation. Elle ne dépend pas de SillyTavern, d'un plugin auxiliaire, de MVU ou d'un framework quelconque. Réutilisez la pile, les composants, les actifs et les modèles d'interaction existants du projet. Si l'utilisateur demande uniquement une conception, ne touchez pas au code.

Références (à lire à la demande, jamais toutes à la fois)

  • references/design-knowledge.md — guide de décision par dimension (identité narrative, couleur, typographie, forme, lumière/matériau, image, mise en page, composants, animation, adaptation) plus tableaux des modes d'échec. Consultez la section correspondant à la décision en cours.
  • references/workflow.md — processus par étapes, portes de validation, méthode de révision, règles de rollback, modèle d'enregistrement de conception. À lire avant toute tâche moyenne ou complexe.
  • references/asset-sources.md — sources et vérifications de licence pour illustrations, textures, icônes, polices. À lire lors de la collecte d'actifs en ligne.
  • references/research.md — preuves et limites derrière cette compétence. Pas nécessaire pour l'exécution.

Niveaux de tâches

Jugez par difficulté de conception, pas par volume de code :

  • Simple : un seul composant, une correction de détail, une petite fonctionnalité dans un langage visuel existant. Réutilisez le langage ; vérifiez par capture d'écran une fois après l'implémentation.
  • Moyen : une seule page/panneau ou une refonte d'un écran existant. Effectuez une brève orientation, construisez d'abord la zone focale, puis complétez la page ; 1 à 2 cycles de révision.
  • Complexe : flux multi-écrans, système gamifié, construction à partir de zéro, nécessite un visuel clé sur mesure, ou l'utilisateur demande une qualité de produit fini. Exécutez les six étapes de workflow.md et tenez un registre de conception.

Règles anti-dérive (contraignantes)

Elles existent parce que l'exécution multi-tours dérive. Suivez-les à la lettre :

  1. Le registre de conception est la source unique de vérité. Pour les tâches moyennes et complexes, créez-le (modèle dans workflow.md) au moment de l'orientation et relisez-le au début de chaque tour/module suivant. Toute nouvelle couleur, rayon, police ou valeur d'animation doit être ajoutée au registre de jetons avant utilisation. Si une valeur n'est pas dans le registre, elle n'est pas autorisée dans le code.
  2. Gelez le registre de jetons après la réussite de l'échantillon de base. Les modules ultérieurs peuvent uniquement réutiliser les jetons enregistrés. De nouveaux jetons nécessitent une note explicite dans le registre expliquant pourquoi l'ensemble existant ne peut pas exprimer le besoin.
  3. Chaque module est comparé par capture d'écran côte à côte avec l'échantillon de base avant de passer à autre chose. Aucune exception ; la comparaison verbale ne suffit pas.
  4. Maximum deux tours de correction par étape. Si cela échoue toujours, revenez en arrière et diagnostiquez selon le tableau de rollback dans workflow.md au lieu d'ajouter d'autres correctifs.
  5. Une seule direction active à la fois. Ne gardez pas de directions alternatives actives entre les tours. Choisissez-en une, enregistrez-la, jetez les autres.

Principes fondamentaux

  1. Concevoir pour l'œuvre, pas pour le genre.
    • Réponse d'abord : quel objet ou système est cette interface dans l'histoire, qui l'a créée, qui la lit, quand.
    • Ensuite, choisissez un point de mémoire qui appartient à cette œuvre spécifique.
    • L'identité visuelle provient de personnages, lieux, époques, factions, événements, accessoires concrets. Les formules de genre (post-apo = radar noir/jaune ; cultivation = vert-encre + or) ne sont que des points de départ et doivent être rendues spécifiques.
    • Auto-test : donnez une demande générique du même genre à un agent — s'il produisait presque la même interface, la direction n'est pas assez spécifique.
    • Comparez quelques directions en interne, livrez exactement une. Ne listez pas d'options à l'utilisateur pour les tâches courantes.
  2. Un concept régit chaque décision de conception.
    • La couleur provient des matériaux et des sources lumineuses ; la typographie des méthodes d'écriture/d'impression ; la forme de l'artisanat ; l'animation des actions physiques de l'objet.
    • Les dimensions connexes sont décidées ensemble, pas séquentiellement (« toutes les couleurs d'abord, puis toutes les polices » est faux).
    • Pour tout élément, vous devez pouvoir indiquer quelle partie du concept il exprime.
  3. L'art concret utilise des actifs d'illustration ; l'art dessiné par code n'est qu'un espace réservé.
    • Personnages, scènes, objets : la version finale utilise des actifs d'illustration. Ordre des sources : actifs de projet existants → génération IA → collection web sous licence.
    • Les scènes, personnages, objets dessinés en CSS/SVG ne sont autorisés que pour la validation de la composition/concept et doivent être remplacés avant la livraison (au plus tard à l'étape de l'échantillon de base pour les tâches complexes). Ils ressemblent à de l'art de programmeur et tirent l'ensemble de l'interface vers le bas.
    • Le code possède l'interface elle-même : mise en page, typographie, bordures, textures, motifs ornementaux, icônes, graphiques abstraits et de données.
  4. L'illustration mène la composition.
    • L'illustration définit le centre de gravité de la mise en page ; le texte et les composants s'organisent autour d'elle. Ne la réduisez jamais à une bannière supérieure ou une vignette de carte.
    • Chaque écran principal doit se lire comme une image : en plissant les yeux, l'écran doit être principalement une illustration, pas des panneaux sombres + des lignes fines + du texte.
    • La présence artistique se poursuit dans les pages fonctionnelles (illustration en calque à faible contraste sous les panneaux, personnage traversant les bords du panneau, scène changeant avec le temps/l'emplacement). « Superbe ouverture, puis pages de formulaire sombres et banales » est l'effondrement de qualité le plus courant.
    • Une image héroïque par écran. Les images secondaires se fondent dans la même image ou forment un ensemble traité uniformément ; ne placez jamais des images de sources différentes dans des boîtes côte à côte.
  5. L'information adopte des formats dans le monde, avec retenue des accessoires.
    • L'information utilise les formats et le vocabulaire natifs du monde (colonnes de registre, mise en page de liste, verbes/noms du monde) et se révèle au rythme narratif.
    • Un support principal pour toute l'interface. Ne donnez pas à chaque module un accessoire simulé CSS différent (notes de ruban, tampons de travers, étiquettes, perles de boulier) — les accessoires empilés semblent bon marché.
    • Limitez les accessoires et ornements, pas les images et la couleur. L'espace libéré des accessoires va à l'illustration et à la typographie, pas aux formulaires textuels sombres.
    • Tout n'est pas « étiquette : valeur » + barre de progression. Les pages de flux (intégration, paramètres) ne sont pas des formulaires ; les options clés peuvent porter des illustrations.
  6. Un seul niveau de qualité uniforme.
    • L'effort peut être inégal : la zone focale reçoit les meilleurs actifs et le plus de détails.
    • Aucune région visible ne peut tomber en dessous du niveau. Tout ce qui est dessiné doit correspondre à la précision globale ; si ce n'est pas possible, remplacez-le par une illustration ou exprimez-le via la typographie ou des graphiques abstraits.
    • Pour réduire les coûts, simplifiez au sein du même langage — ne recourez jamais aux composants par défaut, au style natif du navigateur ou à des images d'espace réservé.
  7. La lecture et l'opération priment.
    • Texte du corps en chinois : ≥14px (15–17 px typique), hauteur de ligne 1.6–1.9, longueur de ligne ~20–40 caractères, contraste du corps ≥4.5:1.
    • L'ambiance est portée par la température de couleur, la lumière, le matériau, l'animation ; le texte et les chiffres restent nets.
    • Pas de petits textes, de faible contraste ou d'anglais insensé comme raccourci « premium ».
    • Les images et textures ne reposent jamais sur du texte de corps ou des cibles de clic.
    • États d'interaction complets, opérables au clavier, adaptés à la largeur cible.
  8. Les valeurs par défaut doivent être choisies, non héritées. Gardez une police, palette, style de bibliothèque de composants ou barre de défilement/anneau de focus par défaut du navigateur seulement si elle est délibérément sélectionnée. Le kit d'interface de jeu IA courant (papier beige + ardoise foncée, tampon rouge de travers, petites étiquettes, nœuds hexagonaux, graphique radar) est aussi une valeur par défaut. Échanger une valeur par défaut tendance contre une autre reste une valeur par défaut.
  9. Retenue technique. Réutilisez le code, les dépendances et les actifs existants. Générez/collectez les actifs selon le plan d'actifs uniquement. Pas de nouvelles dépendances lourdes, pas de pipeline d'actifs, pas de refactorisation du backend.

Flux d'exécution

1. Comprendre la scène

Confirmez : genre ; spécificités du personnage/monde ; ambiance cible ; objectif de la page ; informations et actions principales ; appareil cible ; environnement hôte (par exemple, intégré dans un chat). Examinez le code et les actifs existants. Références utilisateur : extrayez la technique artistique, pas l'image. Procédez sans demander quand il n'y a pas d'ambiguïté critique.

2. Définir la direction (toutes les tâches moyennes et plus)

Écrivez dans le registre de conception :

  • Identité de l'interface : quel objet/système, créé par qui, lu par qui.
  • Point de mémoire : une phrase, doit provenir des spécificités de cette œuvre.
  • Direction artistique : médium, technique de pinceau, direction de la lumière, palette, clarté — une seule description de style partagée, réutilisée textuellement dans chaque demande de génération ultérieure.
  • Liste d'exclusion : les formules de genre et valeurs par défaut que cette œuvre doit éviter.
  • Plan d'actifs : chaque élément d'art concret avec son objectif, son rapport, son recadrage, sa transparence, sa source (existant → IA → web). Vérifiez que les sources existent réellement avant de vous engager ; si ni les actifs IA ni les actifs web sous licence ne peuvent soutenir la direction, dites-le maintenant.

3. Construire

Par niveau de tâche :

  • Simple : implémentez, capture d'écran, corrigez les 1 à 3 pires problèmes, terminé.
  • Moyen : zone focale à pleine qualité → complétez la page → une passe de révision combinée.
  • Complexe : suivez les six étapes dans workflow.md (direction → composition → échantillon de base → extension module par module → polissage → acceptation). Les étapes sont des portes de qualité, pas des points de contrôle de rapport ; progressez en continu. En cas de problèmes systémiques, revenez à l'étape pertinente et refaites uniquement la partie affectée.

Pendant la construction :

  • Réutilisez le code et les modèles d'interaction du projet.
  • Polices décoratives pour les titres uniquement ; vérifiez la couverture des glyphes CJK et définissez des piles de repli.
  • Tous les états : survol, focus, actif, sélectionné, désactivé, chargement, vide, erreur — visuellement cohérents.
  • L'animation sert l'interaction et l'ambiance ; même durée/famille d'assouplissement dans toute l'œuvre ; respectez prefers-reduced-motion.

4. Intégrer les actifs

  • Placez l'image héroïque en premier, puis disposez les informations de support.
  • Unifiez les actifs via recadrage, masque, étalonnage des couleurs, grain, fusion des bords, direction de la lumière unifiée ; laissez des zones calmes pour le texte.
  • Les styles de sources multiples conflictuels → étalonnez pour correspondre ; toujours conflictuels → remplacez, ne forcez pas.
  • Les actifs sont des fichiers de projet locaux, pas des URL liées à chaud. Respectez les licences/attributions.

Révision visuelle (basée sur capture d'écran, problèmes les plus importants en premier)

  1. Premier coup d'œil (vignette, ~1s) : où l'œil se pose-t-il ; est-ce le point focal prévu ; y a-t-il quelque chose de mémorable.
  2. Plisser les yeux : la structure de valeur se lit en 2–3 masses ; l'écran est-il principalement une illustration ou principalement des panneaux sombres.
  3. Cacher le titre : toujours reconnaissable comme cette œuvre, pas un modèle du même genre.
  4. Côte à côte : toutes les régions semblent relever d'une seule direction artistique (lumière, ligne, matériau, palette, type).
  5. Taille réelle : texte du corps en chinois confortable.
  6. Bords : alignement, débordement, chrome natif du navigateur, états vides, pas d'art dessiné par code ou d'espaces réservés restants.
  7. Interaction : états et animation.
  8. Largeur cible : mise en page étroite/intégrée.

Priorité de correction : direction > composition > art de base > cohérence > lisibilité > détail. Corrigez uniquement les 1 à 3 premiers problèmes par tour ; recapture d'écran après chaque tour. Maximum deux tours par étape ; gardez un point de rollback avant chaque session de correction.

Diagnostiquez la classe de cause avant de corriger : art de base manquant / identité de concept faible / hiérarchie de composition faible / conflit de style / erreur de lisibilité ou de mise en page. Chacune a une correction différente.

Si le modèle principal ne peut pas voir les images, réutilisez un outil de vision existant ou déléguez la révision à un sous-agent capable de vision. Signalez uniquement ce qui a été réellement vérifié.

Liste de contrôle d'acceptation (tout doit être « oui »)

  1. Y a-t-il un élément mémorable au premier coup d'œil qui provient du contenu propre de l'œuvre ?
  2. Avec le titre caché, cette interface serait-elle toujours impossible à confondre avec un modèle du même genre ?
  3. La zone visuelle la plus importante utilise-t-elle des actifs d'illustration à une précision correspondant à son statut — pas de figures dessinées par code, pas d'élément manifestement plus grossier dans le cadre ?
  4. Les actifs, la typographie, les composants et l'arrière-plan se lisent-ils comme une seule production ? La région la plus simple est-elle toujours picturale et au même niveau de qualité ?
  5. La page est-elle claire, opérable, adaptée à la largeur cible, sans que la fonction ne soit jamais sacrifiée au visuel ?

Livraison

  • Livrez d'abord les résultats exécutables.
  • Tâches complexes : indiquez brièvement le concept artistique de base, les actifs réellement utilisés (avec notes de licence), les principales corrections effectuées lors de la révision, les résultats de vérification et tout élément encore provisoire.
  • Tâches simples : indiquez uniquement les modifications clés.
  • Pas de longs documents de conception à l'utilisateur. Le registre de conception existe pour la continuité entre les étapes/sessions, pas comme un rapport utilisateur.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

n0ctx/dag-engineering

Use for large software engineering work that needs dependency-aware planning and coordinated subagents: implementing a PRD or roadmap, multi-module features, substantial refactors or migrations, or resuming a plan saved under .dag/. Investigates the relevant code, decomposes the work into independently verifiable DAG tasks, runs independent tasks in parallel in isolated git worktrees, and continuously integrates and verifies the results. Also use when only a plan of this scope is requested. Do not use for small or self-contained changes (quick fixes, routine or single-file edits, anything a few tool calls can finish) or non-code tasks.

n0ctx/reader-first-writing

Use when writing or revising any text a human will read (articles, emails, notices, explanations, reports, marketing copy, social posts, chat replies) or when reviewing such text. Covers sentence-level readability in any language; not layout, and not "humanizing" text to get past AI detectors.

n0ctx/writing-for-agents

Writes or improves prompts and other text an AI agent will read and act on: system prompts, subagent delegation briefs, SKILL.md files, MCP or tool descriptions, handoff documents, GitHub issues and plan files for coding agents, AGENTS.md or CLAUDE.md rules. Use when asked to write a prompt, optimize or rewrite an existing prompt, turn a rough idea into instructions for an agent, or before drafting a substantial brief for another agent. Not for testing, A/B comparison, or eval loops, and not for text only humans will read.

Skills associés