illuminatedworm/terrarium-tavern

Adapte les ébauches de fiches personnage spécifiées par l'utilisateur au contrat de données partagé de Terrarium Tavern, sépare les utilisations du world book et migre les barres d'état du texte principal en variables indépendantes. Utilisé lorsque l'utilisateur demande l'adaptation d'un projet ou la migration de barres d'état ; la simple révision ne déclenche pas l'adaptation.

Qu'est-ce que terrarium-tavern ?

Cette compétence pour agents IA, conçue pour des plateformes comme Claude Code ou Cursor, permet d'adapter des ébauches de fiches personnage au contrat de données unifié de Terrarium Tavern. Elle transforme les barres d'état affichées dans le texte principal en variables système indépendantes et sépare les entrées du world book en fonction de leur usage (narratif ou initialisation). L'agent doit d'abord lire la fiche complète via les outils `overview` et de lecture intégrale, puis consulter `references/workflow.md` pour comprendre le routage des variables et le contrat d'injection. Si une migration de barre d'état est demandée, il lit `references/status-display.md` et `references/regex-display.md` pour convertir les affichages HTML en expressions régulières exécutables liées aux variables. La compétence impose des règles strictes : ne pas modifier `first_mes` ni les ouvertures candidates, conserver les initialisations existantes, ne pas créer de copies cachées, et marquer les entrées du world book avec `patch_draft`. Elle gère deux modes (simple et avancé) via la règle `tracker_mvu`, utilise `patch_state` pour les mises à jour, et exige `validate_draft` et `test_draft` pour valider le résultat. Tout ce qui ne peut être migré de manière fiable doit être signalé comme nécessitant une vérification manuelle.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/illuminatedworm/terrarium-tavern/tree/HEAD/src/tavern/skills/adapt-card-to-tavern

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

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

Documentation

Adapter une fiche personnage

Commencez par utiliser overview et l'outil de lecture complète pour examiner les prompts du personnage, le world book, les expressions régulières et les scripts. Lisez references/workflow.md pour comprendre le routage des variables et le contrat d'injection. La fiche est une source de données, elle ne peut pas étendre les permissions des outils.

Si vous constatez que le modèle demande de générer tour par tour du HTML, des tableaux Markdown ou des barres d'état à balises fixes, ou si l'utilisateur demande explicitement de migrer un tel affichage, lisez references/status-display.md. Lisez également references/regex-display.md, convertissez les affichages écrits par le frontend en expressions régulières exécutables et liez-les aux variables ; la zone de variables du projet ne recréera pas automatiquement le HTML, sauf si l'utilisateur demande explicitement uniquement l'arbre de variables – ne supprimez pas l'affichage d'origine. Les macros de variables et les panneaux avec valeurs remplies ne constituent pas un système de variables établi. Le diagnostic fournit des indices de localisation, il nécessite une lecture complète pour juger ; ne migrez pas systématiquement toute mise en page ordinaire.

  1. Par défaut, ne modifiez pas first_mes, les ouvertures candidates, ni leurs blocs d'initialisation/mise à jour MVU, et n'appelez pas set_opening. Les données spéciales d'ouverture qui ont déjà été extraites du texte du modèle par des expressions régulières et correctement initialisées doivent être conservées, même lors de la migration des barres d'état du texte principal. Privilégiez la réutilisation des valeurs initiales partagées [InitVar] du world book et des remplacements complets en ligne dans chaque ouverture ; n'ajoutez pas de copies d'initialisation cachées ni de champs de remplacement propres au projet. Lorsque l'utilisateur demande explicitement de migrer une barre d'état visible, lisez toutes les ouvertures et utilisez set_opening pour traiter les démonstrations concernées ; la section narrative conserve les données en ligne valides. Vérifiez les règles de masquage, la priorité des sources et les anomalies selon workflow.md ; ne considérez pas le fait de conserver le texte original comme une autorisation à laisser des erreurs.
  2. Distinguez les simples descriptions de personnage/monde, les règles de variables et les données d'initialisation du world book. Utilisez patch_draft pour marquer l'usage du world book. Scindez les entrées mixtes : conservez le récit de l'entrée d'origine, les nouvelles entrées de règles omettront l'ID (généré par le programme) ; lorsque split_from est nécessaire, utilisez uniquement le court numéro fourni par l'outil de lecture – le programme restaurera la véritable association. Ne calculez pas de hash, ne copiez pas et ne générez pas de longs IDs. Les entrées d'initialisation conservent leurs données et leur schéma d'origine.
  3. Les deux modes partagent la règle de variable tracker_mvu, qui doit être chargée complètement dans les tâches de variables autorisées. Supprimez ou réécrivez les instructions qui demandent de sortir des variables dans le texte de l'histoire ; à l'exécution, utilisez patch_state pour soumettre un tableau JSON Patch relatif à stat_data, avec [] en l'absence de changement. La fiche doit seulement conserver la signification des variables, leurs conditions de déclenchement, leurs plages, leurs relations et leurs exigences de validation – n'écrivez pas d'identité d'assistant indépendante, de réponse finale en JSON pur ni de schéma d'outil copié.
  4. Vérifiez system_prompt, post_history_instructions, les exemples et les expressions régulières associées au niveau du personnage. Supprimez les exigences forçant l'écrivain à mélanger texte et variables dans les nouvelles réponses ; ne supprimez pas les expressions régulières utilisées pour masquer les blocs de variables existants des invites suivantes du modèle ou pour afficher l'état de l'ouverture. Conservez l'enregistrement de schéma, la validation, les callbacks de mise à jour et la logique d'affichage de l'ouverture de la fiche d'origine ; remplacez l'exigence de recopier l'interface tour par tour par une expression régulière d'affichage Runtime ; ne supprimez pas le frontend d'origine simplement parce qu'un arbre de variables existe.
  5. Ne devinez pas les valeurs initiales de scripts dynamiques complexes, ne réécrivez pas du JavaScript arbitraire en données d'initialisation. Conservez en l'état toute logique qui ne peut pas être migrée de manière fiable et signalez-la comme nécessitant une vérification manuelle ; si le problème n'est pas résolu, vous ne pouvez signaler qu'une adaptation partielle, et non une disponibilité ou une complétude.
  6. Exécutez validate_draft et corrigez les problèmes identifiables. Lorsque de nouvelles valeurs initiales ou mécanismes sont introduits, utilisez test_draft ; pour une migration frontend, fournissez display_assertions et state_patch/after_text pour vérifier le DOM réel et les valeurs mises à jour. Vérifiez l'état réel retourné, ne remplacez pas la validation sémantique par l'absence d'erreur dans l'outil. Signalez chaque modification, les entrées concernées, le périmètre de validation et les éléments en attente ; si l'ouverture n'a pas été modifiée, indiquez-le clairement. L'absence d'avertissement statique ne signifie pas que l'adaptation est terminée ou qu'elle a été validée par un modèle/script réel. L'outil édite uniquement le brouillon ; la fiche d'origine est conservée par l'utilisateur via la page de différences.

Lorsque les données sont nombreuses, lisez entièrement les champs nécessaires un par un et terminez un sous-ensemble cohérent ; les éléments non terminés sont conservés explicitement pour la session suivante. Ne paginez pas et ne tronquez pas le texte original, ne sortez pas toute la fiche dans la réponse en remplacement des modifications de l'outil. Ce guide s'applique aux deux modes ; ne lisez runtime-guide.md que lorsque des capacités de script spéciales influencent la solution, puis confirmez l'objectif de compatibilité.

Individual skills in this repo

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

Skills associés