Animierter Sticker-Generator

Was macht Animierter Sticker-Generator?

Aus einem Referenzbild und einer Bewegungsbeschreibung wird ein kurzer, transparenter animierter Sticker erstellt. Leite die Identitätssperre, den Bewegungsplan, das Frame-Timing, den Validierungsplan und die Exporteinstellungen intern ab; zwinge den Benutzer nicht dazu, routinemäßige Produktionsentscheidungen zu treffen.

Löse jedes Skript und jeden Referenzpfad relativ zu dem Verzeichnis auf, das diese SKILL.md enthält.

Eingaben und Grenzen

Erfordere nur:

1. reference_image: ein statisches Bild mit einem klaren Hauptmotiv.
2. prompt: natürlichsprachliche Beschreibung des beabsichtigten Ausdrucks, der Aktion, des Textes, der Schleife oder der Zielplattform.

Unterstützt Menschen, Haustiere, Maskottchen, Illustrationen, Objekte und Logos. Wenn das Bild mehrere plausible Motive hat und der Prompt keines identifiziert, frage einmal nach, bevor du generierst. Versprich keine stabile Multi-Subjekt-Darstellung, Szenenanimation oder Kamerabewegung.

Erzeuge einen Sticker pro Aufruf. Für eine Serie mehrerer Sticker behalte gemeinsame Identitätsspezifikationen, Pack-Reihenfolge, Release-Namen und Marken-Assets im übergeordneten Projekt und rufe diese Fertigkeit für jeden Sticker separat auf. Mache aus der projektspezifischen Pack-Orchestrierung kein generisches Fertigkeitsmerkmal.

Dies ist ein Agent Skills-Paket für Hosts, die den Standard unterstützen; pflege kein separates host-spezifisches Anweisungsformat. Der Host muss eine referenzbedingte Rastererzeugungs- oder -bearbeitungsfähigkeit bereitstellen, die die Identität des Motivs bewahren kann. Verwende die native Host-Fähigkeit und gib eine klare Fehlermeldung aus, bevor eine Generierung stattfindet, wenn keine verfügbar ist. agents/openai.yaml ist eine optionale OpenAI-Benutzeroberfläche und Aufruf-Metadaten, nicht Teil des Workflow-Vertrags.

Verwende Python 3.10 oder neuer sowie die Pakete in requirements.txt für deterministische Verarbeitung. Mache OpenCV nicht zu einer erforderlichen Abhängigkeit.

Standardausgabe

Erstelle diese Struktur, es sei denn, der Prompt überschreibt sie explizit:

output/<name>/
├── sticker.webp
├── source/
│   ├── frames/
│   │   ├── 000.png
│   │   └── ...
│   ├── rendered-frames/      # optional validierte High-Frame-Spur
│   ├── reference.json        # Basisname, Hash und Bildmetadaten
│   └── motion.json
├── validation/
│   ├── contact-sheet.png
│   └── report.json
└── exports/                  # nur wenn eine Plattform oder ein zusätzliches Format angefordert wird
    └── <platform>/           # nur wenn eine Plattform oder ein

Verwende ein workspace-lokales output/<name>/, es sei denn, der Benutzer gibt ein anderes lokales Ziel an. Leite <name> als kurzen, dateisystemfreundlichen Slug aus dem Motiv und dem primären semantischen Beat ab. Wenn es bereits existiert, verwende -2, -3 usw.; überschreibe kein vorhandenes Paket standardmäßig. Beachte einen expliziten Release oder öffentlichen Namen, wenn der Benutzer einen angibt.

Verwende 1024×1024 RGBA für kontinuierliche Töne, illustrierte oder generierte Rasterquellen. Für native Pixelgrafik oder ein anderes striktes Low-Resolution-Raster behalte die logische Quellleinwand bei und setze motion.resampling auf nearest; erzwinge keine Neuberechnung über eine nicht-ganzzahlige 1024×1024-Fläche. Verwende 4–8 eindeutige Frames, Dauer pro Frame, eine Gesamtdauer von etwa 1,2–2,0 Sekunden und eine 400–700 ms Haltezeit auf dem klarsten semantischen Frame. Standardmäßig als Schleife. Erstelle kein preview.gif, es sei denn, es wird angefordert oder von der Zielplattform benötigt.

Arbeitsablauf

1. Anfrage normalisieren

• Bestätige, dass ein Referenzbild und ein Bewegungs-Prompt verfügbar sind. Extrahiere das Hauptmotiv, einen semantischen Beat, exakten Text, Schleifenabsicht und alle genannten Zielplattformen.
• Wenn das Motiv mehrdeutig ist, frage einmal nach. Wenn das Referenzbild, der Prompt oder die erforderliche Host-Fähigkeit fehlt, stoppe mit einer klaren Blockermeldung vor der Generierung.
• Wenn keine Plattform genannt wird, produziere das plattformneutrale Paket. Eine benannte Plattform ist ein optionaler Exportzweig, nachdem das Paket die Validierung bestanden hat.
• Wähle den Ausgabe-Slug, bevor du Dateien erstellst, und verwende die obige Kollisionsregel.

2. Identität sperren und Bewegung planen

Lies references/motion-plan.md. Untersuche die Referenz in voller Größe und als kleines Symbol, klassifiziere erkennbare Merkmale als fest, flexibel oder entfernbar und schreibe motion.json, bevor du die endgültigen Frames erstellst.

Verpflichte dich zu einem primären semantischen Beat, einer kleinen Reihe von Ankerposen, deterministischen Übergängen, exakten Textebenen, Frame-Dauern und Schleifenverhalten. Generiere nur das, was nicht sicher durch deterministische Transformationen erhalten werden kann. Wähle motion.resampling bewusst: lanczos für kontinuierliche Töne oder illustrierte Rasterarbeiten und nearest für native Pixelgrafik oder ein anderes striktes logisches Raster.

Schließe diese Phase nur ab, wenn die Identitätssperre explizit ist und jedes angeforderte semantische Element einen geplanten Frame oder eine deterministische Ebene hat.

3. Anker erzeugen und saubere RGBA-Assets bereinigen

Lies die Anweisungen des Hosts zur Rastererzeugung oder -bearbeitung, bevor du generierst. Gib immer die ursprüngliche Referenz an, wenn du einen neuen Anker anforderst, fordere ein isoliertes Motiv auf Transparenz oder einer flachen, weit entfernten Arbeitsfarbe an und generiere die wenigsten benötigten Anker.

Überprüfe jeden Anker sofort gegen die Identitätssperre. Lehne Identitätsdrift ab, bevor du zeitliche Frames erstellst. Wenn ein abgelehnter vollständiger Anker einen brauchbaren lokalen Ausdruck oder ein Requisit enthält, rette ihn nur auf eine genehmigte, identitätsstabile Basis; zeichne die Komponentenquelle, die Extraktionsregel und die genehmigte Basis im Bewegungsplan auf. Benenne ein abgelehntes Vollbild niemals als genehmigt um.

Bewahre sauberes vorhandenes Alpha. Andernfalls lies references/transparency.md, wähle eine Arbeitsfarbe weit entfernt von der Motivpalette und führe scripts/chroma_key.py aus. Halte Schatten getrennt, wenn der Prompt oder die Plattform eine unabhängige Schattensteuerung benötigt.

Schließe diese Phase nur ab, wenn jeder Vollbild-Anker verwendbar ist, jede gerettete Komponente eine begrenzte deterministische Rolle hat und jedes Asset keinen undurchsichtigen Hintergrund, keine Farbverschmierung, keinen hellen Rand, keinen abgeschnittenen Überstand und keinen Kontakt zur Leinwandkante aufweist.

4. Die erstellte Animation komponieren

Erstelle ein RGBA PNG pro eindeutigem erstelltem Frame. Bewahre das Seitenverhältnis, es sei denn, die angeforderte Bewegung erfordert eine Verformung. Rendere exakten Text in deterministischen Ebenen und gib jedem Frame einen Zweck. Bevorzuge Antizipation, Aktion, einen klaren semantischen Halt und eine kurze Erholung gegenüber gleichmäßig getakteter Bewegung.

Wenn ein Begleitobjekt auf das Motiv drückt, sich darauf setzt, es trägt oder berührt, richte es an der lokalen Silhouette unter seinem Fußabdruck aus. Verwende nicht die globale Begrenzungsrahmenkante des Motivs als Kontaktebene, wenn die Oberfläche gekrümmt, eingekerbt oder verformt ist.

Schließe diese Phase nur ab, wenn die Sequenz ohne Dateinamen oder Erklärung lesbar ist und die Schleife keinen unbeabsichtigten Sprung, kein Aufblitzen und keinen Positionsreset aufweist.

5. Paketieren und technische Validierung durchführen

Führe aus:

python <skill-dir>/scripts/package_sticker.py \
  --frames-dir <working-frames> \
  --motion <motion.json> \
  --reference-image <reference-image> \
  --output <output/name>

Übergib --expected-size <BREITExHÖHE>, wenn sich die Quellleinwand von 1024x1024 unterscheidet. Verwende --include-reference nur, wenn der Benutzer das Original eingebettet haben möchte; anderenfalls binde seinen Basisnamen, Hash, Abmessungen, Modus, Format und Bytegröße ohne Kopie. Verwende nicht standardmäßige Timing- oder Frame-Anzahl-Flags nur, wenn der Prompt die Standardeinstellungen explizit überschreibt. Fahre nicht mit dem Plattformexport fort, wenn die technische Validierung fehlschlägt.

Lies references/validation.md für den Berichtsvertrag und die deterministischen Prüfungen. Halte das Paket transaktional, behandle gepacktes source/motion.json als die in sich geschlossene Quelle der Wahrheit, bewahre Artefakt-Fingerabdrücke und halte technical_validation getrennt von visual_validation.

Wenn motion.render vorhanden ist, behandle seine explizit geordneten Frames als optionale, separat validierte Render-Spur. Behalte erstellte Keyframes als Standard; erstelle oder wähle die Render-Spur niemals stillschweigend aus. Lies die Bewegungs- und Plattformreferenzen für ihre Timing-, Ressourcen- und Exportregeln.

Schließe diese Phase nur ab, wenn das WebP, die normalisierten Quellen, die Referenzmetadaten, der Bewegungsplan, das Kontaktblatt, der primäre technische Bericht und alle anwendbaren Render-Spur-Berichte existieren und alle anwendbaren technischen Prüfungen bestanden sind.

Jede erfolgreiche Neupaketierung erstellt einen neuen Bericht mit ausstehender visueller Validierung. Führe die visuelle Validierung nach jeder Neupaketierung erneut durch; behalte niemals eine vorherige visuelle Bestätigung über geänderte Artefakte hinweg bei.

6. Inspizieren, aufzeichnen und optional exportieren

Lies references/validation.md und references/review-page.md. Generiere unmittelbar vor der Inspektion oder Weitergabe eine frische Überprüfungsseite:

python <skill-dir>/scripts/generate_review.py <validation-report.json> \
  --reference-image <original-reference-image> \
  --language <en|zh>

Lasse --reference-image weg, wenn das Paket seine gebundene Referenz enthält. Wähle zh für ein chinesisches Gespräch und en andernfalls. Überprüfe das tatsächlich codierte Überprüfungsziel, die semantische Halte-Markierung, Alpha auf einem Checker/hellen/dunklen Hintergrund, Ansichten in Originalgröße und 50×50 gezoomt sowie das Frame-Belichtungsblatt. Erstellte oder Render-Frames sind Vergleichsnachweise; das decodierte WebP/GIF steuert das Paket oder die Exporthälfte.

Zeichne das Ergebnis mit scripts/record_visual_validation.py auf. Der Bericht muss seinen genauen Artefakt-Fingerabdruck behalten, und deliverable_ready ist nur wahr, wenn sowohl die technische als auch die visuelle Validierung bestehen. Wenn der endgültige Status auf einer gemeinsamen Überprüfungsseite erscheinen muss, generiere die Seite neu, nachdem du sie aufgezeichnet hast. Eine Überprüfungsseite ist abgeleitetes, wegwerfbares HTML, kein Nachweis oder Liefergegenstand.

Wenn eine Plattform angefordert wird, lies references/platform-exports.md, überprüfe die aktuellen offiziellen Einschränkungen und exportiere nur unter exports/<platform>/ aus dem validierten Paket. Verwende standardmäßig erstellte Keyframes; wähle eine deklarierte Render-Spur nur dann explizit aus, wenn sie das angeforderte Ergebnis wesentlich verbessert. Jeder angeforderte Export benötigt seine eigene technische und visuelle Validierung.

Führe vor der Auslieferung scripts/doctor.py auf den genauen Paket-, Render-Spur- und Exportberichten aus, die ausgeliefert werden. Doctor ist schreibgeschützt; incomplete wird erwartet, während eine anwendbare visuelle Validierung aussteht. Lies references/doctor.md für die Zielauswahl und JSON-Ausgabe.

Entscheidungs- und Wiederherstellungsregeln

• Entscheide über routinemäßige Timing-, Positions-, Skalierungs-, Arbeitsfarbenschwellenwert-, Komprimierungs- und Ausgabe-Slug-Details, ohne den Benutzer zu unterbrechen.
• Ein technischer oder visueller Fehler, der durch ein sicheres, reversibles Problem verursacht wird, darf einen fokussierten automatischen Korrekturdurchlauf erhalten, der nur diese sicheren Anpassungen verwendet. Paketiere neu, generiere die Überprüfungsseite neu und inspiziere erneut; jede Neupaketierung setzt die visuelle Validierung zurück.
• Wenn die Korrektur immer noch fehlschlägt oder eine Änderung die Identität, Bedeutung, Ankergenerierung oder eine explizite öffentliche Ausgabe verändern würde, stoppe und frage den Benutzer. Überschreibe niemals ein fehlgeschlagenes technisches Tor mit visuellem Urteil.
• Wenn der Benutzer teilnimmt, teile die frische Überprüfungsseite und sammle Feedback im Gespräch. Der Benutzer muss kein Python ausführen oder ein Formular abschicken.

Übergabe

Verwende die aktuelle Gesprächssprache und melde immer diese Felder:

• status: ready, incomplete oder blocked;
• Paketpfad und Pfad des primären Validierungsberichts;
• Pfad des Render-Spur-Berichts, falls vorhanden;
• Pfad der Überprüfungsseite, falls generiert;
• jeder angeforderte Export und sein Berichtspfad;
• Doctor-Ergebnis für jeden genau ausgelieferten Bericht;
• ungelöste Einschränkungen, ausstehende visuelle Prüfungen, Anforderungen an externe Referenzen oder plattformspezifische Einschränkungen.

Bezeichne ein Artefakt niemals als bereit, es sei denn, sein genauer Bericht hat technical_validation, visual_validation und deliverable_ready: true und Doctor meldet healthy für die ausgelieferte Grenze. Präsentiere Überprüfungs-HTML nicht als Paketartefakt, Validierungsnachweis oder Liefergegenstand.

Eskalationsregel

Frage den Benutzer nur, wenn eine fehlende Auswahl das beabsichtigte Motiv, die angeforderte Bedeutung oder die irreversible öffentliche Ausgabe ändert. Frage einmal nach einem mehrdeutigen primären Motiv; stoppe klar, wenn eine erforderliche Eingabe oder Host-Fähigkeit nicht verfügbar ist. Nimm sichere Anpassungen auf Projektebene automatisch innerhalb der oben genannten begrenzten Wiederherstellungsregel vor.