GraySilver/explainloop

Que fait explainloop ?

Créez des animations originales et lisibles qui expliquent une affirmation, une séquence, une comparaison ou un changement dans le texte fourni. Préservez l'état factuel de la source ainsi que la section, le nombre, le style, la taille et la destination choisis par l'utilisateur. La référence visuelle est un vocabulaire de conception, pas un modèle à copier scène par scène.

Entrées et sélection

1. Lisez l'intégralité du texte fourni. Pour une URL, utilisez les outils de navigation disponibles ; si le corps ne peut pas être récupéré, demandez le texte. Pour un Markdown/TXT local, lisez le fichier et les légendes adjacentes ; scripts/outline.mjs --input /chemin/absolu/article.md [--section "Titre"] signale les plages de titres, le nombre de caractères et si un plan interne développé est utile. Ne déduisez pas le contenu de l'article à partir de son titre.
2. Si l'utilisateur nomme un titre, un paragraphe, une citation ou une plage, sélectionnez uniquement ce passage pour les sujets des GIF ; utilisez le texte environnant uniquement pour résoudre le contexte. Sinon, identifiez jusqu'à trois relations distinctes dignes d'être animées. Préférez un événement observable, un avant/après, une cause/effet, une comparaison ou un changement numérique à un slogan. Produisez 1 à 3 GIF ; ne remplissez jamais le nombre avec des sujets faibles.
3. Construisez pour chaque GIF une carte de preuves compacte : emplacement exact du passage source ou du paragraphe, statut de l'affirmation (fait, mesure, résultat rapporté, proposition ou opinion), objet focal, ce qui change visiblement et une conclusion en une phrase. Conservez les unités et les qualificatifs. Ne choisissez un GIF que lorsque ce changement enseigne quelque chose qu'une image fixe laisserait flou. Ne fabriquez pas de données, d'interface utilisateur, de citations ou de résultats. Plusieurs versions de rapport hauteur/largeur d'un même sujet doivent préserver cette carte.
4. Lorsque le corps sélectionné dépasse 6000 caractères après suppression du balisage ou comporte plus de cinq sections de premier niveau, réalisez un plan thématique interne développé avant de choisir les 1 à 3 GIF les plus forts. Continuez automatiquement ; ne demandez que lorsque le passage demandé ou une affirmation importante reste ambiguë après la lecture de la source. Une section spécifique sélectionnée est mesurée seule.

Consultez content-planning.md lors de la sélection des sujets ou en cas d'incertitude. Cette compétence ne nécessite pas de script vidéo narré complet ni d'approbation de voix off.

Décisions visuelles

• Consultez scene-recipes.md et visual-quality.md avant de composer une scène. Établissez la relation prise en charge, l'objet focal, l'ordre de lecture, la hiérarchie des types, les états des widgets et les battements de mouvement. Concevez d'abord l'image de sortie complète, puis faites en sorte que le mouvement précédent y mène. Pour une nouvelle scène, comparez en interne deux compositions de vignettes sensiblement différentes, puis choisissez celle qui explique la source avec moins de détails concurrents. Consultez design-directions.md lors de la sélection d'une famille visuelle spécifique au sujet, et backgrounds.md lors du choix du traitement du canevas. Un préréglage de style fournit des jetons ; la scène a toujours besoin d'une disposition originale. Ne placez pas chaque sujet dans la même disposition kit.page en-tête/corps/pied de page.
• Partez des instructions visuelles de l'utilisateur. Pour une demande produisant plusieurs GIF ou rapports hauteur/largeur, choisissez un style de lot avant d'écrire les scènes : un seul préréglage parmi styles.md et un fond, une palette, des rôles de police, un traitement des lignes/rayons et un caractère de mouvement partagés. Chaque scène de ce lot utilise le même meta.style et les mêmes styleOverrides de base partagés ; variez la composition et les objets sémantiques pour expliquer chaque sujet. Ne choisissez pas un nouveau préréglage pour chaque GIF. N'utilisez des styles mixtes que si l'utilisateur les demande explicitement.
• Lorsque la typographie porte la scène, consultez font-catalog.md. Comparez deux paires de polices installées par rapport au passage et enregistrez les rôles choisis dans la scène. Vérifiez le visage CJK réel résolu et les glyphes avant le rendu ; ne substituez pas silencieusement une police d'affichage manquante. Le catalogue répertorie également les polices libres installées indépendamment et facultatives. La compétence ne télécharge ni ne regroupe les polices.
• Composez des objets concrets à l'aide de components.md : personnes, messages, documents, tâches, chronologies, mesures et leurs relations. Utilisez les widgets plus riches (email, calendrier, message) lorsque l'explication nécessite des détails d'interface utilisateur ; n'inventez pas l'interface d'un produit réel. Utilisez le sous-ensemble Lucide fourni pour les petites icônes familières. Consultez sources-and-licenses.md avant d'ajouter toute œuvre externe.
• Par défaut, utilisez des objets vectoriels originaux. N'utilisez l'imagerie fournie, une illustration sous licence appropriée ou une image bitmap générée que lorsqu'un sujet concret ne peut pas être expliqué clairement avec des composants vectoriels. Gardez l'imagerie cohérente avec le style choisi et enregistrez sa source. Ne substituez pas silencieusement une icône générique à un sujet réel spécifique.
• Chaque action visible doit répondre à ce qui a changé, où un objet est allé, ou comment le résultat s'ensuit. Révélez les parties apparentées à partir d'une progression de mouvement lorsqu'elles se déplacent en une seule unité ; laissez les informations importantes se déposer dans un ordre délibéré et inversez cet ordre à la sortie. Choisissez l'un des dix traitements de canevas dans backgrounds.md seulement après avoir réservé une zone claire pour l'objet focal et le texte ; faites correspondre sa géométrie à la relation de l'article et utilisez les conditions de rejet du catalogue. Gardez le texte lisible à la largeur de l'article. N'affichez aucune valeur de graphique sans données source. Évitez les longues pauses statiques et un saut brusque entre la première et la dernière image lorsqu'ils cassent la boucle. Consultez failure-cases.md lors de l'examen d'un défaut similaire.

Source de la scène et rendu

Le livrable par défaut est un GIF silencieux de 1600×900, 16:9, 30 ips, 4–7 secondes. Les préférences utilisateur remplacent ces valeurs par défaut. Les autres profils de sortie intégrés sont le 4:3 à 1200×900, le 1:1 à 1200×1200 et le 9:16 à 900×1600 ; acceptez également une taille de pixel personnalisée. Ne produisez que les ratios demandés ; si aucun n'est indiqué, utilisez le 16:9. Ne réduisez pas silencieusement la résolution ou les ips pour réduire la taille du fichier.

Écrivez un fichier .scene.mjs qui exporte meta et draw(t, kit) ; meta.width/height sont le canevas de conception logique, tandis que --output-size définit les pixels raster. draw reçoit les secondes écoulées et renvoie un SVG complet depuis kit.page(...) ou kit.svg(...). Placez la carte de preuves dans meta.sourceRefs. La source doit être déterministe : même scène et même temps, même SVG. Voir scene-format.md, assets/examples/message-filter.scene.mjs et assets/examples/multi-ratio/.

Pour plusieurs ratios dans une même demande, créez une scène modifiable séparée pour chaque ratio et effectuez le rendu de chaque version demandée. Recomposez la disposition pour un espace carré ou portrait ; n'étirez, ne recadrez et ne mettrez jamais en boîte aux lettres une scène paysage comme résultat final. Le contenu à l'écran peut être raccourci pour le cadre plus étroit tout en conservant les mêmes preuves, nombres, statut de l'affirmation et conclusion. Gardez la séquence causale de l'animation cohérente entre les versions.

Sauf si l'utilisateur choisit une autre destination, enregistrez <slug-article>-01.gif et <slug-article>-01.scene.mjs (et les numéros de sujet consécutifs) dans generate/images/ sous le répertoire de travail actuel pour une seule sortie 16:9. Pour une demande multi-ratio, ajoutez -16x9, -4x3, -1x1 ou -9x16 avant les deux extensions ; utilisez -LARGEURxHAUTEUR pour un ratio personnalisé. Conservez les images de travail dans un répertoire temporaire. La source de la scène est le livrable modifiable ; ne laissez pas d'images PNG générées à côté.

Résolvez le répertoire de cette compétence comme SKILL_ROOT à partir du chemin de la compétence chargée.

Pour un lot de deux scènes ou plus, exécutez d'abord node "$SKILL_ROOT/scripts/check-batch.mjs" --scene /chemin/absolu/premiere.scene.mjs --scene /chemin/absolu/deuxieme.scene.mjs (répétez --scene pour chaque scène). Corrigez toute incohérence de préréglage ou de jeton partagé avant le rendu. Cela vérifie les métadonnées de la scène. Lorsque la perception d'image est disponible, exécutez scripts/preview-batch.mjs avec les mêmes arguments --scene et comparez les images de sortie réelles pour les couleurs locales de la scène, les polices, les détails des widgets et le traitement de l'arrière-plan. Ignorez la vérification du style du lot uniquement si l'utilisateur a explicitement demandé des styles mixtes.

Effectuez le rendu et inspectez chaque GIF demandé :

node "$SKILL_ROOT/scripts/render.mjs" --scene /chemin/absolu/vers/nom.scene.mjs --out /chemin/absolu/vers/nom.gif --output-size 1600x900
node "$SKILL_ROOT/scripts/inspect.mjs" /chemin/absolu/vers/nom.gif

render.mjs nécessite Node, rsvg-convert, ffmpeg et ffprobe ; il vérifie la disponibilité et signale un outil manquant plutôt que de l'installer. La taille de sortie demandée doit avoir le même rapport hauteur/largeur que le canevas logique de la scène, chaque dimension de pixel étant au maximum de 4096. Utilisez --poster /chemin/absolu/vers/preview.png lorsqu'un aperçu statique est utile.

Pour une génération axée sur la qualité, suivez le workflow de prévisualisation et de révision conditionnelle décrit dans scene-recipes.md. Si cet agent peut réellement voir les pixels de l'image, exécutez node "$SKILL_ROOT/scripts/preview.mjs" --scene /chemin/absolu/vers/nom.scene.mjs --temporal-strip [--display-width 720], inspectez les quatre images clés et huit images échantillonnées, et corrigez les défauts visuels concrets avant le rendu final. N'effectuez pas plus de deux tours de révision visuelle. Si l'agent ne peut pas voir les pixels de l'image, ignorez la révision visuelle et la prévisualisation ; effectuez le rendu et exécutez inspect.mjs uniquement pour les vérifications techniques. Playwright n'est pas nécessaire. inspect.mjs vérifie les dimensions, le nombre d'images, la durée, le décodage complet, les images répétées et la plus longue séquence statique exacte ; il ne peut pas juger de la qualité visuelle.

Livraison

Fournissez un lien vers chaque GIF et sa source de scène. Indiquez le passage source qu'il illustre, toute inférence importante, le style choisi et les dimensions/ips/durée/taille du fichier réels. Si une section d'entrée a été spécifiée, confirmez que chaque scène en provient. Ne prétendez pas avoir effectué le rendu ou une révision visuelle à moins que cela n'ait été réellement fait ; lorsque la révision visuelle n'était pas disponible, dites-le explicitement.

Cette compétence est destinée aux courts GIF silencieux. Utilisez un workflow de diagramme statique pour une seule image d'architecture immobile et un workflow vidéo pour un MP4 narré.