wufei-png/animated-sticker-maker

Animated Sticker Maker

Transformez une image de référence et une invite de mouvement en un court autocollant animé transparent. Déduisez le verrouillage d'identité, le plan de mouvement, le minutage des images, le plan de validation et les paramètres d'exportation en interne ; n'obligez pas l'utilisateur à remplir des choix de production de routine.

Résolvez chaque script et chemin de référence par rapport au répertoire contenant ce fichier SKILL.md.

Entrées et limites

Exigez uniquement :

1. reference_image : une image statique contenant un sujet principal clair.
2. prompt : un langage naturel décrivant l'expression, l'action, le texte, la boucle ou la plateforme cible prévus.

Prenez en charge les personnes, les animaux domestiques, les mascottes, les illustrations, les objets et les logos. Si l'image comporte plusieurs sujets plausibles et que l'invite n'en identifie aucun, demandez une fois avant de générer. Ne promettez pas un jeu d'acteur multi-sujets stable, une animation de scène ou un mouvement de caméra.

Produisez un autocollant par appel. Pour une série de plusieurs autocollants, conservez les spécifications d'identité partagées, l'ordre d'emballage, la dénomination des versions et les actifs de la marque dans le projet propriétaire, puis invoquez cette compétence séparément pour chaque autocollant. Ne transformez pas l'orchestration d'un pack spécifique au projet en une fonctionnalité générique de la compétence.

Il s'agit d'un package Agent Skills pour les hôtes prenant en charge le standard ; ne maintenez pas un deuxième format d'instructions spécifique à l'hôte. L'hôte doit fournir une capacité de génération ou d'édition raster conditionnée par une référence qui peut préserver l'identité du sujet. Utilisez la capacité native de l'hôte et échouez avant la génération avec un message de capacité clair lorsqu'aucune n'est disponible. agents/openai.yaml est un fichier facultatif d'interface utilisateur et de métadonnées d'invocation OpenAI, ne fait pas partie du contrat de workflow.

Utilisez Python 3.10 ou plus récent ainsi que les packages dans requirements.txt pour un traitement déterministe. Ne faites pas d'OpenCV une dépendance obligatoire.

Sortie par défaut

Créez cette structure sauf si l'invite la remplace explicitement :

output/<nom>/
├── sticker.webp
├── source/
│   ├── frames/
│   │   ├── 000.png
│   │   └── ...
│   ├── rendered-frames/      # piste d'images haute fréquence validée facultative
│   ├── reference.json        # nom de base, hachage et métadonnées de l'image
│   └── motion.json
├── validation/
│   ├── contact-sheet.png
│   └── report.json
└── exports/                  # seulement lorsqu'une plateforme ou un format supplémentaire est demandé
    └── <plateforme>

Utilisez output/<nom>/ dans l'espace de travail sauf si l'utilisateur nomme une autre destination locale. Déduisez <nom> comme un slug court et sûr pour le système de fichiers à partir du sujet et du temps sémantique principal. S'il existe déjà, utilisez -2, -3, etc. ; ne remplacez pas un package existant par défaut. Honorez un nom de version ou public explicite lorsque l'utilisateur en fournit un.

Utilisez 1024×1024 RGBA pour les sources raster à tons continus, illustrées ou générées. Pour le pixel art natif ou une autre grille stricte de basse résolution, préservez le canevas source logique et définissez motion.resampling sur nearest ; ne le forcez pas à passer par un 1024×1024 non entier. Utilisez 4 à 8 images uniques, des durées par image, une durée totale d'environ 1,2 à 2,0 secondes et un maintien de 400 à 700 ms sur l'image sémantique la plus claire. Bouclez par défaut. Ne créez pas de preview.gif sauf si cela est demandé ou requis par la plateforme cible.

Flux de travail

1. Normaliser la demande

• Confirmez qu'une image de référence et une invite de mouvement sont disponibles. Extrayez le sujet principal, un temps sémantique, le texte exact, l'intention de boucle et toute plateforme cible nommée.
• Si le sujet est ambigu, demandez une fois. Si l'image de référence, l'invite ou la capacité requise de l'hôte est manquante, arrêtez-vous avec un blocage clair avant de générer.
• Si aucune plateforme n'est nommée, produisez le package neutre. Une plateforme nommée est une branche d'exportation facultative après que le package a passé la validation.
• Sélectionnez le slug de sortie avant de créer des fichiers, en utilisant la règle de collision ci-dessus.

2. Verrouiller l'identité et planifier le mouvement

Lisez references/motion-plan.md. Inspectez la référence en taille réelle et en petite icône, classifiez les caractéristiques reconnaissables comme fixes, flexibles ou amovibles, et écrivez motion.json avant de produire les images finales.

Engagez-vous sur un temps sémantique principal, un petit ensemble de poses d'ancrage, des transitions déterministes, des couches de texte exactes, des durées d'image et un comportement de boucle. Générez uniquement ce qui ne peut pas être obtenu de manière sûre par des transformations déterministes. Choisissez motion.resampling délibérément : lanczos pour un travail raster à tons continus ou illustré, et nearest pour le pixel art natif ou une autre grille logique stricte.

Terminez cette étape uniquement lorsque le verrouillage d'identité est explicite et que chaque élément sémantique demandé a une image planifiée ou une couche déterministe.

3. Produire les ancres et les actifs RGBA propres

Lisez les instructions de génération ou d'édition raster de l'hôte avant de générer. Incluez toujours la référence originale lorsque vous demandez une nouvelle ancre, demandez un sujet isolé sur transparence ou une couleur de travail plate et à haute distance, et générez le moins d'ancres possible.

Inspectez immédiatement chaque ancre par rapport au verrouillage d'identité. Rejetez la dérive d'identité avant de construire les images temporelles. Si une ancre complète rejetée contient une expression ou un accessoire local utilisable, ne la récupérez que sur une base approuvée et stable en termes d'identité ; enregistrez la source du composant, la règle d'extraction et la base approuvée dans le plan de mouvement. Ne reétiquetez jamais une image complète rejetée comme approuvée.

Préservez l'alpha existant propre. Sinon, lisez references/transparency.md, choisissez une couleur de travail loin de la palette du sujet et exécutez scripts/chroma_key.py. Gardez les ombres séparées lorsque l'invite ou la plate-forme nécessite un contrôle indépendant des ombres.

Terminez cette étape uniquement lorsque chaque ancre plein cadre est utilisable, chaque composant récupéré a un rôle déterministe borné et chaque actif n'a pas d'arrière-plan opaque, de déversement de couleur, de frange lumineuse, de saillie coupée ou de contact avec le bord du canevas.

4. Composer l'animation créée

Créez un PNG RGBA par image créée unique. Préservez le rapport hauteur/largeur sauf si le mouvement demandé implique une déformation. Rendre le texte exact dans des couches déterministes et donnez à chaque image un seul objectif. Favorisez l'anticipation, l'action, une courte pause sémantique claire et une récupération rapide plutôt qu'un mouvement uniformément chronométré.

Lorsqu'un objet compagnon appuie, s'assoit, porte ou touche le sujet, alignez-le contre la silhouette locale en dessous de son empreinte. N'utilisez pas le bord de la boîte englobante globale du sujet comme plan de contact lorsque la surface est courbe, entaillée ou déformée.

Terminez cette étape uniquement lorsque la séquence se lit sans noms de fichiers ni explications et que la boucle n'a pas de saut, de flash ou de réinitialisation de position involontaire.

5. Empaqueter et exécuter la validation technique

Exécutez :

python <skill-dir>/scripts/package_sticker.py \
  --frames-dir <images-de-travail> \
  --motion <motion.json> \
  --reference-image <image-de-référence> \
  --output <output/nom>

Passez --expected-size <LARGExHAUTEUR> lorsque le canevas source diffère de 1024x1024. Utilisez --include-reference uniquement lorsque l'utilisateur souhaite que l'original soit intégré ; sinon, liez son nom de base, son hachage, ses dimensions, son mode, son format et sa taille en octets sans le copier. Utilisez des indicateurs de synchronisation ou de nombre d'images non standard uniquement lorsque l'invite remplace explicitement les valeurs par défaut. Ne continuez pas vers l'exportation vers une plateforme lorsque la validation technique échoue.

Lisez references/validation.md pour le contrat de rapport et les vérifications déterministes. Conservez le package transactionnel, traitez le fichier source/motion.json empaqueté comme la source de vérité autonome, préservez les empreintes digitales des artefacts et gardez technical_validation séparé de visual_validation.

Si motion.render est présent, traitez ses images ordonnées explicites comme une piste de rendu validée facultative distincte. Conservez les images clés créées par défaut ; ne créez ni ne sélectionnez jamais la piste de rendu silencieusement. Lisez les références de mouvement et de plateforme pour ses règles de synchronisation, de ressources et d'exportation.

Terminez cette étape uniquement lorsque le WebP, les sources normalisées, les métadonnées de référence, le plan de mouvement, la planche contact, le rapport technique principal et tous les rapports de piste de rendu applicables existent et que toutes les vérifications techniques applicables sont réussies.

Chaque réempaquetage réussi crée un nouveau rapport avec une validation visuelle en attente. Réexécutez la validation visuelle après chaque réempaquetage ; ne conservez jamais un passage visuel antérieur sur des artefacts modifiés.

6. Inspecter, enregistrer et exporter éventuellement

Lisez references/validation.md et references/review-page.md. Générez une nouvelle page de révision juste avant l'inspection ou le partage :

python <skill-dir>/scripts/generate_review.py <validation-report.json> \
  --reference-image <image-de-référence-originale> \
  --language <en|zh>

Omettez --reference-image lorsque le package contient sa référence liée. Choisissez zh pour une conversation en chinois et en sinon. Inspectez la cible de révision réelle encodée, le marqueur de maintien sémantique, l'Alpha sur les fonds de vérification/clair/sombre, les vues en taille réelle et zoomées 50×50, et la feuille d'exposition des images. Les images créées ou de rendu sont des preuves de comparaison ; le WebP/GIF décodé contrôle le package ou la page d'exportation.

Enregistrez le résultat avec scripts/record_visual_validation.py. Le rapport doit conserver son empreinte digitale exacte, et deliverable_ready est vrai uniquement lorsque la validation technique et visuelle réussissent toutes les deux. Si le statut final doit apparaître sur une page de révision partagée, régénérez la page après l'avoir enregistrée. Une page de révision est un HTML dérivé jetable, pas une preuve ou un livrable.

Si une plateforme est demandée, lisez references/platform-exports.md, vérifiez les contraintes officielles actuelles et exportez uniquement sous exports/<plateforme>/ à partir du package validé. Utilisez les images clés créées par défaut ; sélectionnez une piste de rendu déclarée explicitement uniquement lorsqu'elle améliore matériellement la sortie demandée. Chaque exportation demandée nécessite sa propre validation technique et visuelle.

Avant la livraison, exécutez scripts/doctor.py sur les rapports exacts du package, de la piste de rendu et de l'exportation qui seront livrés. Doctor est en lecture seule ; incomplete est attendu lorsqu'une validation visuelle applicable est en attente. Lisez references/doctor.md pour la sélection de cible et la sortie JSON.

Règles de décision et de récupération

• Décidez des détails de routine (temporisation, position, échelle, seuil de couleur de travail, compression et slug de sortie) sans interrompre l'utilisateur.
• Un échec technique ou visuel causé par un problème sûr et réversible peut recevoir un passage de correction automatique ciblé utilisant uniquement ces ajustements sûrs. Rempaquetez, régénérez la page de révision et réinspectez ; chaque rempaquetage réinitialise la validation visuelle.
• Si la correction échoue toujours, ou si un correctif devait modifier l'identité, la signification, la génération d'ancres ou une sortie publique explicite, arrêtez-vous et demandez à l'utilisateur. Ne remplacez jamais une porte technique défaillante par un jugement visuel.
• Si l'utilisateur participe, partagez la nouvelle page de révision et recueillez les commentaires dans la conversation. L'utilisateur n'a pas besoin d'exécuter Python ou de soumettre un formulaire.

Transfert de livraison

Utilisez la langue de la conversation actuelle et signalez toujours ces champs :

• status : ready, incomplete ou blocked ;
• chemin du package et chemin du rapport de validation principal ;
• chemin du rapport de piste de rendu lorsqu'il existe ;
• chemin de la page de révision lorsqu'elle a été générée ;
• chaque exportation demandée et son chemin de rapport ;
• résultat Doctor pour chaque rapport livré exact ;
• limitations non résolues, vérifications visuelles en attente, exigences de référence externe ou limitations spécifiques à la plateforme.

N'appelez jamais un artefact prêt à moins que son rapport exact n'ait technical_validation, visual_validation et deliverable_ready: true, et que Doctor signale healthy pour la limite livrée. Ne présentez pas le HTML de révision comme un artefact de package, une preuve de validation ou un livrable.

Règle d'escalade

Demandez à l'utilisateur uniquement lorsqu'un choix manquant modifie le sujet prévu, la signification demandée ou la sortie publique irréversible. Demandez une fois pour un sujet principal ambigu ; arrêtez-vous clairement lorsqu'une entrée requise ou une capacité d'hôte est indisponible. Effectuez automatiquement des ajustements sûrs au niveau du projet dans le cadre de la règle de récupération limitée ci-dessus.