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 :
- Confirmez Node.js 20.9+. Si
nodeest 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. - Exécutez
doctoravec le répertoire de sortie réel de l'utilisateur. Utilisezmeshpour la vérification initiale des dépendances ; cela ne sélectionne pas la stratégie de rig de l'animation. Ajoutez--previewsauf si l'utilisateur ignore explicitement l'atelier. Ajoutez--editable/--spine-cliuniquement lorsque le fichier.spineéditable est nécessaire. Revérifiez avec--segmentation mobilesamousam3avant 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. - Lisez
result.ready,checks[].requiredetrepairs. 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.repairsfournit des commandes sous forme decommandplusargs; 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
-
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. -
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
preparepour 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" -
Inspectez le
sourceImageretourné avec votre capacité de visualisation d'images. Lisez references/plans.md pour les formats de coordonnées et d'images clés. Utilisez leimageSizeretourné comme base de coordonnées ; enregistrezimageBudget. 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. Lemeshd'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 commerigDecisiondansquality-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. Écrivezanalysis.jsonetmotion.jsonvous-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. Utilisezauto/mobilesam/sam3/polygonpour découper une source existante.autosé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. -
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. Utilisezmeshpour une stratégie d'image entière, ou un chemin d'intégration de calque/pose testé lorsque lebuildstandard 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 --previewPassez toujours l'ID sélectionné par l'utilisateur avec
--target; l'exemple ci-dessus suppose que Unity a été choisi. Ajoutez--blinkuniquement lorsque le clignement est demandé et que le personnage a des yeux sombres clairs et de face. Omettez--motionpour utiliser le repos par défaut. Utilisez--namepour 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. -
Mettez à jour l'atelier déjà ouvert vers le
previewUrlretourné, 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ôle | Révisions humaines |
|---|---|
| Matériel et rig | Straté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 |
| Mouvement | Animation jouable, poses extrêmes, couture de boucle et yeux fermés/réouverts lorsque demandé |
| Livraison | Format 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.
parentdécrit l'héritage du mouvement ;depthdé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.
buildne télécharge jamais d'environnements SAM/Python ni n'appelle d'API de génération d'images.doctorsignale la disponibilité facultative de MobileSAM/SAM 3 local.autoutilise un backend installé et signale les replis de polygones réels ; les modes SAM explicites échouent lorsqu'ils sont indisponibles. Utilisezsam-setupuniquement 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
inspectouprepare --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
avertissementsde la construction. Ne prétendez pas qu'un clignement ignoré ou un projet éditable indisponible a été produit. Les livrables standard sont des.json,.atlaset.pngdu 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