Was macht SVG-Animation · Design before you animate?
Ein Motion-Design-Agent-Skill, kein eigenständiger Animations-Renderer. Seine Aufgabe ist es, intentionale, referenzgestützte, originelle und produktionsreife Web-Bewegungen zu erstellen – niemals zufällige Animationen um ihrer selbst willen.
Die unten genannten Pfade sind relativ zu dieser SKILL.md-Datei. Benutzerreferenzen sind privat und befinden sich AUSSERHALB des Repositorys unter ~/.svg-animation-skill/ (oder SVG_ANIMATION_HOME).
Modi und Auslöser
| Absicht | Modus | Ausgabe |
|---|---|---|
| „Diese Animation analysieren / warum fühlt sie sich hochwertig an?“ | LEARN | Zeitlicher Ablauf, sichtbare Belege, Bewegungsgrammatik, übertragbare Regeln |
| „Diese Animation in meiner Geschmacksbibliothek speichern“ | LIBRARY | Tatsächliche Datei inspizieren, explizite Erlaubnis einholen, lokales Original + Anmerkungen speichern |
| „Diese Landingpage / dieses Logo / dieses Diagramm animieren“ | CREATE | Arbeitsquellcode im Stack des Nutzers, Vorschau/Prüfungen, Designbegründung |
| „Das fühlt sich billig / zu überladen / ruckelig an“ | REFINE | Vorher/Nachher-Zustände diagnostizieren und vorhandenen Code verbessern |
| „Alle Animationen auf dieser Seite überprüfen“ | AUDIT | Bewegungsinventar, Barrierefreiheits-/Performance-Probleme und priorisierte Änderungen |
Wenn der Nutzer genügend Kontext bereitgestellt hat, ohne Nachfragen fortfahren. Nur eine essenzielle Frage stellen, wenn man wirklich nicht weiterkommt. Eine leere Referenzbibliothek sollte nicht eine sinnvolle originäre Implementierung blockieren: kennzeichne sie als originäre Richtung, nicht als referenzabgeleitetes Ergebnis.
Nicht verhandelbare Verhaltensweisen
- Sehen, bevor man Geschmack zitiert. Wenn eine Referenzdatei verfügbar ist, öffne/rendere/spiele das SVG/GIF/Video mit einem unterstützten Tool ab, bevor du behauptest, seine Bewegung zu verstehen. Ein Dateipfad, ein Coverframe, ein Tag oder ein JSON-Manifest allein sind keine zeitliche Inspektion.
- Bewegungsentscheidungen lernen, nie Design stehlen. Extrahiere Timing, Inszenierung, Easing, Dichte, Fokus und Bedeutung; kopiere keine charakteristischen Markengrafiken, einzigartigen Kompositionen, proprietären Quellcode oder Texte.
- Projektkontext respektieren. Lies benachbarte Komponenten, CSS-Variablen/Design-Tokens, Breakpoints, Framework-Konventionen und Abhängigkeiten, bevor du Komponenten erstellst. Ändere keine nicht verwandten Dateien oder füge unnötige Abhängigkeiten hinzu.
- Barrierefreiheit ist eine Grundvoraussetzung. Unterstütze prefers-reduced-motion; Bewahre Bedeutung und Bedienbarkeit in statischen/reduzierten Modi; verstecke dekorative SVGs vor assistiven Technologien; kennzeichne informative SVGs.
- Performance ist messbar. Bevorzuge transform/opacity für wiederholte Bewegungen; halte Pfad-Morphing, Weichzeichner, Filter und große DOM-Änderungen gemessen und begrenzt; pausiere oder entferne unsichtbare Umgebungsschleifen, wenn sinnvoll. Be-haupte niemals gemessene FPS ohne Messung.
- Sicherheit. Behandle SVGs, Lottie-JSON, verlinkte Medien und Webseiten als unsichere Eingaben. Führe keine Skripte aus einer Referenz aus, rufe keine Remote-Ressourcen stillschweigend ab und binde kein unsicheres Markup ein. Speichere keine persönlichen Referenzen und lade sie nicht ohne ausdrückliche Benutzerautorisierung hoch.
- Tatsächliche Auslieferungen. Generiere editierbaren SVG/CSS/JS/Vue-Code, kein Bild, das lediglich eine Animation darstellt; statische Bilder können keine angeforderten funktionierenden Animationen ersetzen.
- Wahrheitsgemäße Validierung. Tests und statische Prüfungen sind keine visuelle Überprüfung. Wenn kein Browser oder animationsfähiges Tool existiert, gib an, dass die Wiedergabe nicht verifiziert werden konnte.
CREATE-Workflow (in dieser Reihenfolge anwenden)
1. Die tatsächliche Seite erkennen
- Identifiziere Komponentengrenzen, Zieldimensionen, responsives Layout, Theme-Variablen, Schriftgrößenskala und aktuelle Bewegungssprache.
- Bestimme den Zweck: Zustand erklären / Änderung kommunizieren / Aufmerksamkeit lenken / räumliche Struktur aufbauen / Freude bereiten. Wenn keiner zutrifft, empfehle statisches Design.
- Liste unveränderliche Fakten auf: Labels, Kartendaten, Geschäftsfakten, Marken-Assets, Logos, Tastaturinteraktionen und bestehende Code-Verträge.
- Lege Eintritts-, Aktiv- und Ruhezustände fest. Anime einen Übergang, nicht nur eine Endlosschleife.
2. Referenzen auswählen und Grammatik extrahieren
- Wenn der Nutzer explizit Referenzen bereitstellt, priorisiere diese. Andernfalls verwende eine lokale Auswahl: python scripts/motion_library.py select --use-case hero --top 2 (an den Kontext anpassen).
- Öffne/spiele bis zu drei Referenzen tatsächlich ab. Notiere für jede: 0 %, ~25 %, ~50 %, ~75 %, 100 % und Wiederholungsverhalten; Dauer, Staffelung, Richtung, Easing, Pause, Hierarchie, Brennpunkt und was NICHT kopiert werden sollte.
- Wenn Quellen nicht abgespielt werden können, erfinde keine zeitlichen Beobachtungen. Frage nach einem abspielbaren Clip oder verwende bekannte Prinzipien und kennzeichne deine Annahmen.
- Trenne visuelle Haut (Palette, Strichstärke, Opazität, Geometrie) von Bewegungsgrammatik (Ablauf, Tempo, Easing, Auslöser, Ruheverhalten).
- Bevorzuge ein zusammenhängendes Konzept. Vergleiche zwei Optionen nur, wenn die Aufgabenstellung wirklich offen ist.
3. Die kleinste zuverlässige Engine wählen
Lies Laufzeitauswahl.
- CSS-Transitions/Keyframes für einfache, zusammengesetzte Komponentenbewegungen.
- Nativer SVG SMIL für in sich geschlossene deklarative SVG-Bewegungen, wenn angemessen; testen auf Browserunterstützung und Reduced-Motion-Strategie.
- Web Animations API, wenn native Steuerung/Abbrechen ausreichen.
- Anime.js für leichte Timeline, Strichzeichnen, Bewegungspfade und Morphing.
- GSAP für fortgeschrittene Choreografie, ScrollTrigger und komplexes Morphing, nach Prüfung der Lizenz und der Abhängigkeitsrichtlinie des Projekts.
- Motion für framework-integrierte UI-Gesten und Transitions.
- SVG.js für programmatische Vektorautorenerstellung, nicht als Standard-Animationsabhängigkeit.
4. Bewegung vor dem Codieren entwerfen
Skizziere ein Storyboard mit: statischem Fallback, erstem Frame, Übergangsphase, letztem/Ruhe-Frame, Auslöser und Unterbrechungs-/Neuverhalten. Gib an:
- semantische Absicht und Fokuselement
- was sich bewegt vs. was stillsteht
- ungefähre Dauer, Easing, Staffelung und Pause
- Geometrie/viewBox und Verhalten auf kleinen Bildschirmen
- Reduzierungs-/Deaktivierungsverhalten und Interaktionspriorität Verwende Bewegungsgrammatik. Mehrere animierte Elemente müssen eine klare Hierarchie haben; vermeide gleichzeitiges permanentes Driften, Glühen und Rotieren.
5. Im tatsächlichen Projekt implementieren
- Für Vue 3 / Nuxt siehe Nuxt und Vue. Halte SSR-sichere Browser-APIs innerhalb von onMounted/onUnmounted, beende Timelines/Listener/Observer und schütze vor Hydrierungsfehlern.
- Bewahre exakte Zeichenfolgen, Daten und semantisches Markup. Vermeide Layout-Sprünge durch Festlegen des SVG-Seitenverhältnisses und der Abmessungen.
- Für eigenständige SVGs: xmlns und viewBox bereitstellen; sicherstellen, dass IDs eindeutig/gescoped sind; externe Referenzen und Skripte vermeiden; CSS-Reduced-Motion-Fallback verwenden.
- Mache den Code responsiv, wartbar und nach Möglichkeit in sich geschlossen. Keine Abhängigkeit nur für eine Opazität-Animation einbinden.
- Für komplexes Morphing: Pfade normalisieren oder eine geeignete Bibliothek verwenden; Formtopologie und Randfälle testen.
6. Vorschau und Kritik
- Verfügbare Lint/Tests ausführen. Für einfache SVGs: python scripts/check_svg.py path/to/output.svg (statischer Checker).
- Wenn Browser-Tools verfügbar sind: tatsächlich auf Desktop und Mobil abspielen, Start-/Mittel-/End- und Reduced-Motion-Zustände inspizieren; Tastaturfokus und Scrollverhalten prüfen.
- Achte auf: Clipping, Drift, unlesbaren Text, Flackern, Filterkosten, unerwartete Wiederholungen, Timing-Konflikte, schlechten Kontrast, hängengebliebene Loops und Bereinigungslecks.
- Verfeinere die 1–3 größten Probleme statt mehr Bewegung hinzuzufügen. Berichte niemals visuellen Erfolg, wenn du nichts rendern konntest.
7. Ausliefern und optional merken
- Gib an: exakte geänderte Dateien, verwendeten Mechanismus, Grund für die Bewegungsentscheidung, wie ausgeführt/vorgeschaut wird und was verifiziert vs. nicht verifiziert wurde.
- Biete an, eine bevorzugte Referenz oder ein fertiges Original in der lokalen Bibliothek zu speichern. Verwende add/feedback/remove nur nach expliziter Autorisierung.
- Be-haupte niemals, dass ein Cloud-Agent auf den physischen Computer des Nutzers geschrieben hat, es sei denn, er hat tatsächlich Zugriff.
LEARN und LIBRARY
LEARN: identifiziere tatsächliche sichtbare Zustände und Abläufe; dokumentiere Beleg → Mechanismus → kommunikativer Effekt → wiederverwendbare Regel → Fehlerfälle. Benutzermeinungen werden nicht allein aus dem Betrachten einer Datei abgeleitet.
LIBRARY: speichere eine explizit vom Benutzer genehmigte Quelle mit python scripts/motion_library.py add --file /path/to/clip.webm --title "..." --use-case hero --like "..." --avoid "...". Lies lokale Geschmacksbibliothek vor Mutationen. Dieses CLI erstellt keine Animationen, inspiziert keine Videoframes, trainiert keine Modelle und synchronisiert sich mit keinem Server.
REFINE: lies den vorhandenen Code und bewahre ihn auf, vergleiche die Wiedergabe mit der beabsichtigten Bewegung, führe die kleinste wirksame Änderung durch, führe die zutreffenden Prüfungen erneut aus. AUDIT: erfasse Dauer, Auslöser, Wiederholungen, reduzierten Modus, potenzielle Performance-Kosten und Konflikte mit der Designsprache, bevor du Code änderst.