Communitygithub.com

you tiao gua gua / animation Spine

Créez des animations squelettiques Spine à partir d'images avec des plans de parties et de mouvement rédigés par l'agent, exportez au format JSON/atlas/PNG pour les moteurs de jeu, et ouvrez une page de démonstration d'animation locale. Idéal pour l'animation de personnages, le rigging d'images, le clignement des yeux ou les animations d'interface dans Spine.

Qu'est-ce que animation Spine ?

Cette compétence permet à un agent IA de créer des animations squelettiques complètes avec Spine, en utilisant sa propre compréhension des images pour planifier les parties et les mouvements. Le runtime local intégré s'occupe du rigging d'une image entière transparente ou du découpage des parties, ajoute des images clés, exporte les ressources (JSON, atlas, PNG) et sert une prévisualisation interactive. Il ne nécessite ni modèle API externe ni clé API ; la complétion d'œuvres manquantes utilise les outils de génération/modification d'images de l'hôte (par exemple, l'agent de code). La compétence fonctionne avec Claude Code, Codex, Cursor et d'autres environnements d'agents, en suivant un flux de travail structuré : vérification de l'environnement (Node.js 20.9+, Sharp, Express), ouverture d'un atelier de travail (workbench) dès le début, identification de l'image source et du mouvement demandé, sélection de la cible d'exportation (Unity recommandée par défaut), préparation de l'image (redimensionnement, budget de taille), analyse et planification des parties rigides et des mouvements (écriture de `analysis.json` et `motion.json`), validation et construction de l'animation, puis révision humaine à trois points de contrôle (matériel/rig, jouabilité, livraison). Le `doctor` vérifie les dépendances facultatives comme MobileSAM ou SAM3 pour le découpage d'images. L'agent doit ouvrir l'atelier immédiatement après la vérification de base, sans attendre l'animation terminée. Les formats d'exportation supportés incluent Unity, Cocos Creator 3.8 et d'autres cibles, avec un fichier `.spine` éditable nécessitant l'éditeur Spine et le paramètre `--editable`. Le processus de révision humaine exige une approbation explicite de l'utilisateur avant chaque étape critique. La compétence insiste sur la qualité : utiliser des identifiants de parties en anglais, associer le rig à l'action demandée (pas un rig d'image entière pour un coup de poing), vérifier les arêtes sur fond clair et foncé, et ne pas promettre des œuvres non réalisées.

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/youtiaoguagua/animation-2d/tree/HEAD/skills/spine-animation

Demander à votre IA préférée

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

Documentation

Animation Spine

Utilisez votre propre compréhension des images pour planifier les parties et le mouvement. Le runtime local intégré soit effectue le rigging d'une image entière transparente, soit découpe les parties, ajoute des images clés, exporte les ressources et fournit une prévisualisation. Le runtime local n'appelle pas de modèle API séparé ni n'a besoin de clé API. La complétion des œuvres, si nécessaire, utilise les outils de génération/modification d'images de l'hôte.

Vérification préalable de l'environnement — à exécuter en premier

Résolvez le répertoire de cette compétence à partir de l'emplacement de son SKILL.md. Exécutez son lanceur avec des chemins absolus ; il fonctionne également lorsque votre répertoire actuel est un autre projet :

node --version
node /chemin/absolu/vers/spine-animation/scripts/spine.mjs doctor \
  --segmentation mesh --output /chemin/absolu/output --preview

Avant prepare, validate, build ou le démarrage d'une prévisualisation :

  1. Confirmez Node.js 20.9+. Si node est manquant ou plus ancien, préparez un Node compatible en utilisant le gestionnaire de paquets/versions disponible dans l'environnement avant de lancer la compétence. La compétence fournit du JavaScript compilé, pas l'exécutable Node.
  2. Exécutez doctor avec le répertoire de sortie réel de l'utilisateur. Utilisez mesh pour la vérification initiale des dépendances ; cela ne sélectionne pas la stratégie de rig de l'animation. Ajoutez --preview sauf si l'utilisateur ignore explicitement l'atelier. Ajoutez --editable/--spine-cli uniquement lorsque le fichier .spine éditable est nécessaire. Revérifiez avec --segmentation mobilesam ou sam3 avant d'utiliser explicitement ce backend ; ces vérifications testent également ses imports Python, sans charger les poids pour l'inférence. Les modèles facultatifs manquants ne bloquent pas les workflows mesh/polygone.
  3. Lisez result.ready, checks[].required et repairs. Dans le cadre de l'autorisation existante de l'utilisateur, réparez uniquement les prérequis manquants pour la tâche en cours, puis relancez la même vérification. repairs fournit des commandes sous forme de command plus args ; préservez les chemins comme arguments. La réparation des dépendances de paquets installés utilise pnpm dans le répertoire de la compétence ; le checkout source utilise sa propre installation de dépendances. Démarrez chaque commande de génération uniquement après que ses propres vérifications requises réussissent ; la planification/préparation indépendante peut continuer pendant que les bloqueurs sont résolus. Ne remplacez pas silencieusement un backend ou un format final demandé. Si une réparation est bloquée par le réseau/l'accès ou échoue, signalez le bloqueur spécifique au lieu de réinstaller ou de prétendre être prêt. N'installez pas SAM 3 simplement parce qu'il est listé comme une capacité facultative indisponible.

Le doctor d'amorçage utilise les modules intégrés de Node et peut signaler Sharp/Express manquant ou cassé avant que l'application ne les importe. Il vérifie les fichiers d'exécution, l'encodage natif des images, le gestionnaire de paquets, la possibilité d'écriture dans le répertoire de sortie demandé et les fonctionnalités facultatives. Il n'installe pas de paquets ou de modèles. pnpm est nécessaire pour réparer les dépendances manquantes ; un runtime déjà installé peut fonctionner sans pnpm dans le PATH.

La disponibilité des ressources de prévisualisation ne prouve pas que l'agent dispose d'outils de navigation/ordinateur. La compétence installée sert des ressources web statiques pré-construites ; React/Vite sont nécessaires uniquement lors du développement ou de la reconstruction du frontend à partir des sources. Vérifiez les outils disponibles de l'hôte lorsque l'ouverture automatique de page ou des captures d'écran sont demandées, et signalez la vérification visuelle séparément. Conservez le répertoire de sortie choisi par l'utilisateur ; la valeur par défaut est ./output dans le répertoire de travail actuel. stdout est en JSON, la progression va sur stderr, et les vérifications requises échouées renvoient un code de sortie non nul.

Ouvrir l'atelier au début de la tâche

Pour chaque demande de création d'animation, démarrez ou réutilisez l'atelier dès que la vérification préalable de base réussit, avant les questions de sélection de cible, la génération d'œuvres, la planification ou la configuration du modèle. Utilisez le dossier de sortie de l'utilisateur (sinon ./output dans le répertoire de travail appelant). Un dossier de sortie vide est supporté :

node /chemin/absolu/vers/spine-animation/scripts/spine.mjs preview \
  --output /chemin/absolu/output

Envoyez immédiatement le result.url réellement retourné comme un lien cliquable. Dans Codex desktop, utilisez un outil open_in_codex disponible pour l'ouvrir dans le panneau droit du chat actuel. Voir references/workbench-start.md pour les arguments de l'outil, la réutilisation des onglets et les solutions de repli. L'ouverture de l'atelier n'a pas besoin d'une animation terminée ou d'une cible d'exportation choisie.

Gardez le service et la page disponibles pendant la production et la révision humaine. Après chaque construction terminée, naviguez/actualisez l'atelier existant vers le previewUrl retourné, ou dites à l'utilisateur de sélectionner le nouveau projet et de cliquer sur actualiser lorsque l'hôte ne peut pas automatiser cela. Honorez une demande explicite d'ignorer la page web.

Créer une animation

  1. Avec le lien de l'atelier déjà fourni, identifiez l'image source, le mouvement demandé, la cible d'exportation et le dossier de sortie à partir de la conversation. Si l'utilisateur n'a pas choisi de cible d'exportation, proposez Unity (unity) comme option par défaut/recommandée, Cocos Creator 3.8 et les autres cibles supportées. Attendez la sélection de l'utilisateur avant toute construction ou exportation ; une sélection préalable par défaut ou le silence n'est pas un choix. Réutilisez un choix explicite existant, y compris une instruction d'utiliser la valeur par défaut, sans demander à nouveau. Voir references/export-targets.md pour les options et la compatibilité des versions. Les vérifications indépendantes de l'environnement, la préparation de l'image et la planification peuvent continuer en attendant. Réutilisez les images et ressources fournies. Lorsque seule une description de personnage est fournie, utilisez un outil de génération d'image disponible si l'utilisateur a demandé la création de l'œuvre ; sinon, obtenez une image source.

  2. Appliquez references/image-size.md avant de générer ou de préparer l'œuvre. Par défaut, utilisez un bord le plus long de 512 px et un PNG de travail de 512 Kio. Demandez la plus petite taille de génération appropriée, puis utilisez prepare pour appliquer le budget réel en pixels/octets sans modifier l'original :

    node /chemin/absolu/vers/spine-animation/scripts/spine.mjs prepare \
      --image /chemin/absolu/personnage.png --workdir /chemin/absolu/plans/personnage \
      --max-edge 512 --max-bytes 524288 \
      --prompt "repos de 2 secondes, petits mouvements de tête et de bras, clignement"
    
  3. Inspectez le sourceImage retourné avec votre capacité de visualisation d'images. Lisez references/plans.md pour les formats de coordonnées et d'images clés. Utilisez le imageSize retourné comme base de coordonnées ; enregistrez imageBudget. Confirmez que les yeux, les doigts et les contours fins restent lisibles après la réduction. Définissez les poses clés de l'action et les articulations qui bougent indépendamment, puis choisissez le rig en utilisant references/artwork-completion.md. Le mesh d'image entière convient pour un mouvement de repos petit et cohérent supporté par les pixels existants. Pour un mouvement articulé des membres, de grandes rotations d'articulations ou un chevauchement changeant, utilisez des couches découpées/terminées séparées avec chevauchement des articulations et régions cachées remplies. Utilisez des pièces jointes/poses alternatives lorsque la main, le visage ou les changements de perspective nécessitent des œuvres différentes ; combinez ces méthodes selon les besoins. Ne réutilisez pas un rig d'image entière au repos pour un coup de poing, une marche ou une danse simplement pour éviter les coutures, ou réduisez l'action demandée pour l'adapter à ce rig. Enregistrez le choix et les parties mobiles requises comme rigDecision dans quality-review.json. Vérifiez que le chemin de construction actif peut consommer les ressources et effectuer les poses requises avant d'investir dans les images clés. Complétez et inspectez les œuvres manquantes lorsque c'est supporté ; résolvez une capacité manquante ou un périmètre révisé avec l'utilisateur avant de continuer la production dépendante. Écrivez analysis.json et motion.json vous-même. Ne demandez pas à l'utilisateur d'écrire ces fichiers. Divisez aux articulations qui nécessitent un mouvement relatif et aux limites nécessaires pour le calque visuel ; évitez les coupes inutiles dans les régions fixes. Utilisez auto/mobilesam/sam3/polygon pour découper une source existante. auto sélectionne un backend de masque installé, pas une stratégie de rig. Pour les bords sales, les demandes SAM ou les nouvelles œuvres transparentes, lisez references/cutouts.md avant de choisir une voie.

  4. Validez et construisez un candidat à la révision. Lisez references/human-review.md avant la première construction afin que le candidat inclue les preuves nécessaires à la révision humaine de la qualité. L'exemple ci-dessous découpe des parties avec polygon ; utilisez le backend choisi pour la tâche réelle. Utilisez mesh pour une stratégie d'image entière, ou un chemin d'intégration de calque/pose testé lorsque le build standard ne peut pas effectuer les poses requises :

    node /chemin/absolu/vers/spine-animation/scripts/spine.mjs validate \
      --image /chemin/absolu/plans/personnage/source.png \
      --analysis /chemin/absolu/plans/personnage/analysis.json \
      --motion /chemin/absolu/plans/personnage/motion.json
    
    node /chemin/absolu/vers/spine-animation/scripts/spine.mjs build \
      --image /chemin/absolu/plans/personnage/source.png \
      --analysis /chemin/absolu/plans/personnage/analysis.json \
      --motion /chemin/absolu/plans/personnage/motion.json \
      --project personnage-mouvement --output /chemin/absolu/output \
      --target unity --segmentation polygon --background transparent --blink --preview
    

    Passez toujours l'ID sélectionné par l'utilisateur avec --target ; l'exemple ci-dessus suppose que Unity a été choisi. Ajoutez --blink uniquement lorsque le clignement est demandé et que le personnage a des yeux sombres clairs et de face. Omettez --motion pour utiliser le repos par défaut. Utilisez --name pour un nom de ressource stable. Lors de l'itération sur un travail généré précédemment, utilisez --replace ; les autres projets et sources restent séparés.

  5. Mettez à jour l'atelier déjà ouvert vers le previewUrl retourné, en réutilisant son onglet lorsque c'est supporté. Vérifiez l'image originale par rapport à l'animation au repos et au mouvement le plus large, et inspectez une image d'œil fermé lorsque le clignement a été demandé. Ajustez les plans et reconstruisez lorsqu'un défaut concret est visible. Vérifiez également l'action demandée par rapport à ses poses clés : un coup de poing nécessite une frappe et un retour lisibles, avec une forme de main appropriée et une mécanique corporelle. Enregistrez les auto-vérifications image/action séparément de la validation des fichiers. Effectuez les points de contrôle humains ci-dessous avant de considérer le résultat comme accepté. Préservez les pages ouvertes demandées.

Points de contrôle humains de qualité

Utilisez trois points de contrôle pendant la production de l'animation :

Point de contrôleRévisions humaines
Matériel et rigStratégie de rig, pièces découpées/complétées réelles ou texture d'image entière, chevauchement des articulations, poses de repos/extrêmes
MouvementAnimation jouable, poses extrêmes, couture de boucle et yeux fermés/réouverts lorsque demandé
LivraisonFormat cible de la révision, fichiers réels et toutes limitations non résolues

Attendez l'approbation humaine explicite avant de passer à un point de contrôle de qualité. Les constructions et exportations provisoires sont autorisées pour produire des preuves de révision. Corrigez d'abord les défauts que l'agent peut identifier, puis montrez les images/prévisualisations réelles et demandez des commentaires ciblés. Une construction réussie ou la propre vérification visuelle de l'agent ne constitue pas une approbation humaine.

Suivez references/human-review.md pour les listes de contrôle, les enregistrements de révision et les modifications qui nécessitent une autre révision. Présentez les points de contrôle ensemble lorsque leurs preuves sont prêtes, et réutilisez l'approbation explicite des artefacts inchangés. Honorez l'instruction explicite d'un utilisateur d'ignorer ou d'assouplir un point de contrôle ; enregistrez ce point de contrôle comme levé plutôt qu'approuvé.

Qualité et livrables

  • Utilisez des identifiants de parties en anglais. parent décrit l'héritage du mouvement ; depth décrit l'ordre de dessin. Gardez un membre avec son objet tenu lorsqu'ils bougent ensemble.
  • Faites correspondre le rig à l'action demandée. Gardez les articulations connectées via des pivots appropriés, des œuvres complètes qui se chevauchent et des poids ajustés. Utilisez la déformation locale du maillage dans des calques séparés lorsque c'est utile ; vérifiez que les membres en mouvement s'articulent réellement indépendamment. Les œuvres manquantes ou les limites de mouvement de la construction standard nécessitent un chemin d'œuvres/intégration compatible ou un changement de périmètre convenu, plutôt qu'un geste de substitution plus petit.
  • Une image entière transparente a toujours besoin de régions osseuses et de pivots. Les maillages d'image entière supportent des déformations cohérentes ; l'opacité par partie et l'occlusion changeante indépendante nécessitent des calques séparés. Ne promettez pas d'œuvres non réalisées.
  • build ne télécharge jamais d'environnements SAM/Python ni n'appelle d'API de génération d'images. doctor signale la disponibilité facultative de MobileSAM/SAM 3 local. auto utilise un backend installé et signale les replis de polygones réels ; les modes SAM explicites échouent lorsqu'ils sont indisponibles. Utilisez sam-setup uniquement dans le cadre d'un travail SAM demandé lorsque l'installation du modèle local s'adapte au périmètre et aux contraintes de ressources de l'utilisateur.
  • Pour les œuvres nouvellement demandées, préférez une option de fond transparent réel d'un générateur, puis vérifiez l'alpha avec inspect ou prepare --background transparent. Un damier peint en RVB n'est pas une transparence. Évitez les fonds d'écran vert pour les nouvelles ressources. Le RGBA existant peut encore avoir des bords de couleur mate ; la construction inspecte l'alpha et répare de manière conservatrice les déversements de couleur identifiables.
  • Gardez les images de travail normales dans 512 px / 512 Kio. Utilisez un budget plus grand uniquement pour une exigence de taille explicite de l'utilisateur ou un besoin de détail concret ; enregistrez la raison. Vérifiez les dimensions/octets de l'atlas final, et reconstruisez à partir de la source budgétée lorsqu'il est surdimensionné plutôt que de redimensionner une texture exportée elle-même.
  • Inspectez les avertissements de la construction. Ne prétendez pas qu'un clignement ignoré ou un projet éditable indisponible a été produit. Les livrables standard sont des .json, .atlas et .png du même nom ; un fichier .spine éditable nécessite en plus un éditeur Spine installé et --editable (ou --spine-cli /chemin/vers/editeur). Signalez cette limitation lorsque cela s'applique.
  • Renvoyez le lien de prévisualisation, le dossier ou les fichiers d'artefact, les animations et ce qui a été vérifié, y compris le statut de la révision humaine. Le travail en attente ou rejeté reste un candidat à la révision. Inspectez les bords à la fois sur des fonds de prévisualisation clairs et sombres. Si aucun navigateur n'est disponible, signalez la vérification visuelle comme incomplète et laissez l'humain inspecter la prévisualisation ou les images disponibles.

Le serv

Skills associés