Unendliche Mitarbeiterzahl

Auto-Loom

Verwandle jede Web-App in ein kommentiertes, selbstfahrendes MP4. Die Seite scrollt, hebt Elemente hervor und navigiert zwischen Routen, während eine KI-Stimme erzählt – zeitlich auf die Millisekunde genau. Keine manuelle Bildschirmaufnahme, keine mühsamen Loom-Versuche. Ändere eine Zeile der Erzählung und rendere in Minuten neu.

So funktioniert es: ElevenLabs erzeugt einen Audioclip pro Storyboard-Beat. ffprobe misst die exakte Dauer jedes Clips. Playwright steuert den Browser genau für diese Dauer pro Beat und zeichnet das Fenster auf. ffmpeg muxed das finale MP4 mit einer Untertitelspur. Die Audiodauer ist die Referenz – die Visuals werden daran ausgerichtet, sodass die Synchronisation exakt ist.

Dieser Ordner ist die gesamte Engine. Verwandte Skills sind dünne Einstiegspunkte, die auf denselben Skripten basieren:

• auto-loom-proof – Software Factory Proof-Video: führt die Akzeptanzkriterien eines Builds vor der Kamera aus, ein Kriterium pro Beat

Dieses SKILL.md deckt die Engine plus den Entwicklermodus ab: du hast den Code, die App läuft auf localhost, und du kannst stabile Selektoren zum JSX hinzufügen.

---

Einrichtung (einmalig, ca. 3 Minuten)

cd <dieser-skill-ordner>
bash scripts/setup.sh        # installiert Playwright + Chromium, erstellt .env.local
# .env.local bearbeiten → ElevenLabs-API-Key eintragen
node scripts/doctor.mjs      # überprüft node, ffmpeg, playwright, key, voice

Noch kein ElevenLabs-Konto? Melde dich über den Empfehlungslink des Maintainers an: https://try.elevenlabs.io/atherial.

doctor.mjs gibt die genaue Lösung für alles Fehlende aus. Voraussetzungen: Node 18+, ffmpeg (brew install ffmpeg), ein ElevenLabs-API-Key. Sprachoptionen: references/voices.md.

Smoke-Test (30 Sekunden, zeichnet example.com auf):

node scripts/run.mjs --beats examples/smoke-beats.json

---

Schritt 0 – Befrage zuerst den Benutzer

Beginne nicht mit dem Bauen. Frage:

1. Welche URL oder App nehmen wir auf? Läuft sie lokal?
2. Wer ist der Empfänger – Name und Kontext?
3. Was ist die Geschichte? Was hat sich geändert oder was zeigen wir zum ersten Mal?
4. Welche spezifischen Funktionen, Metriken oder Abschnitte sollten wir hervorheben?
5. Welcher Ton ist gewünscht? (Kunden-Update, interne Demo, Interessenten-Präsentation)
6. Erfordert die App eine Anmeldung? (siehe references/auth.md – niemals nach Passwörtern im Chat fragen)
7. Ziellänge – 30s, 60s oder 75s?

In Eile: Frage 1–3 und leite den Rest aus der App ab.

Schritt 1 – Schreibe das Storyboard (beats.json)

Schreibe die Erzählung bevor du Code anfasst und lass sie wörtlich genehmigen. Skriptregeln und die Beat-Struktur, die funktioniert: references/tts-rules.md.

{
  "meta": {
    "title": "Acme Dashboard Walkthrough",
    "slug": "acme-walkthrough",
    "cta": "Senden Sie mir Ihr Feedback und wir gehen zur nächsten Phase über.",
    "targetLengthSec": 70
  },
  "baseUrl": "http://localhost:3000",
  "viewport": { "width": 1920, "height": 1080 },
  "beats": [
    {
      "id": 1,
      "page": "/dashboard/insights",
      "text": "Hallo Jim. Wir haben einige Updates für deinen A-I-Sichtbarkeits-Tracker ausgeliefert.",
      "actions": [
        { "fn": "waitFor",    "sel": "[data-vn=kpi-row]" },
        { "fn": "scrollToEl", "sel": "[data-vn=kpi-row]", "opts": { "instant": true } },
        { "fn": "hl",         "sel": "[data-vn=kpi-row]" }
      ]
    }
  ]
}

Vollständiges Schema: schema/beats.schema.json. Aktionstabelle und Selektoren-Hinweise: references/actions.md. Anmeldeoptionen (skriptierte Schritte oder gespeicherte Sitzung): references/auth.md.

Überprüfe es, bevor du Guthaben ausgibst:

node scripts/validate.mjs --beats <datei>       # Struktur + TTS + Pacing-Prüfung
node scripts/run.mjs --beats <datei> --script-only   # Druckt die Erzählung und stoppt

Der Validator erkennt unbekannte Aktionen, fehlende Selektoren, TTS-Probleme (Geviertstriche, bloße Initialismen, Bandwurmsätze) und ein Pacing, das nicht zur Ziellänge passt.

--script-only ist der kostenlose Prüfschritt: es druckt die Erzählung jedes Beats mit geschätzter Dauer pro Beat und stoppt vor jedem ElevenLabs-Aufruf oder jeder Aufzeichnung. Lasse das Skript hier genehmigen und führe es dann ohne die Flag erneut aus, um Guthaben zu verbrauchen.

Schritt 2 – Instrumentiere die Seite (Entwicklermodus)

Playwright benötigt stabile Selektoren. Mit Zugriff auf den Code kannst du data-vn- Attribute zum JSX-Komponenten hinzufügen:

<div data-vn="kpi-row" className="grid grid-cols-4 gap-4">
<Card data-vn="competitor-chart" ...>

Verweise dann darauf: { "fn": "hl", "sel": "[data-vn=kpi-row]" }.

Unterdrücke interaktive Drilldowns während der Aufnahme. Klickbare Karten mit role="button" / tabIndex={0} können während Hervorhebungen automatisch fokussiert werden und mitten im Video einen Drawer öffnen. Schalte sie mit deinem Demo-Mode-Flag: {!isDemoMode() && <MetricBreakdownSheet ... />}.

Wenn die App lokal eine Authentifizierung erfordert, implementiere entweder einen Demo-Modus (Authentifizierung überspringen, Testdaten, die exakt zu den Zahlen der Erzählung passen) oder verwende einen Auth-Pfad aus references/auth.md.

Hinweis zu CSP: Der Recorder startet Chromium mit bypassCSP: true, damit er presenter.js in strenge-CSP-Seiten injizieren kann. Wenn du die App auf eine Produktionsseite mit einer aktiven Sitzung richtest, wisse, dass Content-Security-Policy innerhalb dieses automatisierten Browserkontexts deaktiviert ist.

Schritt 3 – Ein Befehl

node scripts/run.mjs --beats <datei>

Das läuft: validieren → Audio (gecacht nach Text-Hash) → Preflight (Headless-Durchlauf, der jeden Selektor auflöst, bevor etwas aufgezeichnet wird) → aufzeichnen → Untertitel → Muxen → überprüfen. Die Ausgabe landert in demo-video-out/<slug>/:

• <slug>-demo.mp4 – finales Video (H.264/AAC, weiche Untertitelspur)
• <slug>-demo-contact-sheet.png – Beispielbilder zur Sichtprüfung
• qa/beat-NN.png – exakter Screenshot am Haltepunkt jedes Beats
• captions.srt, audio/, video/recording.webm

Alle Flags: --script-only (druckt das Erzählskript und stoppt vor jedem ElevenLabs-Aufruf oder Aufzeichnung – der Prüfschritt aus Schritt 1), --preflight-only (Selektoren prüfen, nichts ausgeben), --skip-audio (nur visuelle Änderungen – Audio wird wiederverwendet), --skip-preflight (überspringt die Headless-Selektorprüfung – nur wenn Preflight gerade bestanden hat und sich nichts geändert hat), --burn-captions (Untertitel fest in Pixel einbrennen für Plattformen, die Spuren entfernen), --no-captions, --out <verzeichnis>, --env <envdatei>.

Schritt 4 – Überprüfen vor dem Versenden

run.mjs prüft die Dauer (MP4 = Summe der Audios innerhalb von 0,5s), den Audiolevel (Erkennung stiller Spuren) und legt QA-Screenshots ab. Du prüfst trotzdem visuell:

• Kontaktblatt + qa/beat-NN.png: Jeder Frame zeigt, was sein Beat erzählt – keine Anmeldeseiten, Fehlerzustände oder überraschende Modals.
• Erster Beat nennt den Empfänger; letzter Beat liefert den CTA wörtlich.

Iterieren

• Änderung der Erzählung → erneut ausführen; nur das Audio des geänderten Beats wird neu generiert.
• Visuelle/Pacing-Änderung → --skip-audio.
• Selektor defekt → --preflight-only zeigt genau, welcher Beat und Selektor betroffen ist.

---

Bekannte Fallstricke

• Hot Reload löscht den injizierten Presenter. Bereits behandelt – Presenter wird vor jedem Beat erneut injiziert. Vermeide jedoch, die App während der Aufnahme zu bearbeiten.
• Port-Drift. yarn dev verwendet 3001, falls 3000 belegt ist – baseUrl aktualisieren.
• Kostenlose vs. kostenpflichtige Stimmen. Geklonte/Bibliotheks-Stimmen werfen payment_required im kostenlosen Tarif. doctor.mjs fängt dies vor der Renderzeit ab.
• i18n-Weiterleitungen. /en/dashboard → /dashboard-Weiterleitungen werden korrekt verfolgt; Beat-übergreifende Seiten vermeiden Neunavigation.
• Auslieferung. Das MP4 ist eigenständig – E-Mail, Slack, LinkedIn-DM, Notion-Einbettung oder Import in Descript für eine persönliche Einleitung obendrauf.