nikserg/skim

Skim-Demo-Assets aktualisieren

Erzeugt das Produkt-Demovideo und die hellen/dunklen Screenshots der Oberfläche, die mit der Landingpage ausgeliefert werden. Alles wird mit der echten Skim-Benutzeroberfläche gegen eine gemockte Tauri-IPC-Schicht (demo/mock/) betrieben, sodass nie ein echtes Konto, Postfach oder Modell berührt wird.

Ausgaben, alle veröffentlicht in docs/:

• skim-demo.mp4 — die geführte Feature-Tour (1280×800)
• skim-light.jpg, skim-dark.jpg — Screenshots der Oberfläche, 800px breit

Nicht committen oder pushen

Dieses Skill aktualisiert nur Dateien auf der Festplatte. Führen Sie nicht git add, git commit oder git push aus. Der Benutzer prüft die neu erstellten Assets selbst und entscheidet, was behalten wird – es sind Binärdateien, die große Diffs erzeugen, und ein Lauf, der vom Exit-Code her in Ordnung aussieht, kann trotzdem visuell falsch sein. Den Arbeitsverzeichnis in einem unbereinigten Zustand zu belassen, ist das korrekte Ergebnis.

Git nur dann anfassen, wenn der Benutzer in derselben Anfrage explizit darum bittet (z. B. "neu generieren und committen" ). Andernfalls beenden Sie die Aktion mit der Information, dass die Dateien aktualisiert und nicht gestaged sind.

Ausführung

Vom Stammverzeichnis des Repositorys aus:

npm run demo

Das verknüpft drei Schritte: demo:record (Playwright steuert die echte UI → demo/output/raw.webm) → demo:encode (ffmpeg → MP4, kopiert nach docs/) → demo:shots (beide Themes → docs/).

Wenn sich nur ein Teil der UI geändert hat, führen Sie nur das Nötigste aus – das ist schneller und hält nicht betroffene Assets byte-identisch:

• npm run demo:shots — nur Screenshots (statische UI, Farben, Layout-Änderungen)
• npm run demo:record && npm run demo:encode — nur Video (Abläufe, KI-Verhalten)

Voraussetzungen: npm install und ffmpeg im PATH. Der gesamte Lauf dauert ein paar Minuten; die Aufnahme ist der langsamste Teil.

npm run demo beginnt mit demo:browser (playwright install chromium) – ein No-Op, wenn der Browser bereits vorhanden ist. Wenn ein Lauf mit "Executable doesn't exist at ...chromium_headless_shell-NNNN" abbricht, liegt das daran, dass die Playwright-Browser-Build nicht mit der Bibliotheksversion übereinstimmt (ein ^-Bump verweist neu, und die Headless-Shell ist ein separater Download von Chromium). Führen Sie npm run demo:browser oder das vollständige npm run demo aus, um das Problem zu beheben – es ist nicht nötig, dies als Demo-Problem zu debuggen. Die einzelnen Skripte demo:record / demo:shots überspringen diese Prüfung.

Vor der Erfolgsmeldung prüfen

Ein Lauf kann mit Exit-Code 0 enden und trotzdem ein defektes Video produzieren. Ein nicht behandelter Mock-Befehl gibt undefined zurück, anstatt einen Fehler zu werfen, was sich als leeres Panel statt als Fehler darstellt – vertrauen Sie also Ihren Augen, nicht dem Exit-Code.

1. Bestätigen Sie, dass die drei Dateien in docs/ aktuelle Änderungsdaten (mtimes) haben.
2. Überprüfen Sie die Abmessungen: Screenshots 800px breit, MP4 1280×800.
3. Ziehen Sie Frames aus dem gesamten MP4 und schauen Sie sie sich tatsächlich an. Abtasten Sie nach Bruchteilen statt nach festen Sekunden – die Länge der Tour ändert sich, wenn eine Szene hinzugefügt oder das Tempo angepasst wird, daher veralten hartcodierte Zeitstempel:

   dur=$(ffprobe -v error -show_entries format=duration -of csv=p=0 docs/skim-demo.mp4)
   for k in 1 2 3 4 5 6 7; do
     ffmpeg -y -hide_banner -loglevel error \
       -ss $(echo "$dur * $k / 8" | bc -l) -i docs/skim-demo.mp4 -frames:v 1 /tmp/f$k.png
   done
   

   Jeder Frame sollte ein gefülltes Panel zeigen, und die KI-Szenen sollten ihren gestreamten Text enthalten. demo/output/progress.log benennt jede Szene, sobald sie beendet ist, was hilft, einen schlechten Frame auf den Schritt zurückzuführen, der ihn erzeugt hat.
4. Sehen Sie sich beide Screenshots an – überprüfen Sie besonders den dunklen (E-Mail-Inhalte werden in einem sandboxed Iframe mit eigener Theming-Logik gerendert und können dunkel-auf-dunkel erscheinen).

Melden Sie, welche Dateien geändert wurden und was Sie gesehen haben. Wenn eine Szene falsch aussieht, korrigieren Sie sie, anstatt sie auszuliefern.

Wenn die Tour nach einer UI-Änderung bricht

Das Grundgerüst stützt sich auf zwei Verträge. Die Fehlermeldung sagt Ihnen, welcher sich geändert hat:

IPC-Befehlsnamen (demo/mock/tauri-core.ts). Der Mock implementiert invoke() mit einem switch über Befehlsnamen, die src/lib/api.ts widerspiegeln. Wenn ein Befehl umbenannt oder hinzugefügt wurde, fügen Sie den passenden case hinzu. Symptom: ein leeres Panel oder fehlende Daten statt eines Absturzes.

Selektoren und englische Bezeichnungen (demo/record.mjs). Die Tour klickt auf Dinge wie .row, .quick-btn:has-text("Summarize"), .ai-input .instruction. Umbenannte CSS-Klassen oder geänderte Zeichenfolgen in src/lib/i18n/locales/en.json brechen den entsprechenden Schritt, und der Timeout-Fehler nennt den Selektor, der fehlgeschlagen ist. Die Demo erzwingt locale: "en", daher sind englische Bezeichnungen das, worauf es ankommt.

Gleiches gilt für die Fixtures: demo/mock/data.ts gleicht die ai.prompt_*-Zeichenfolgen ab, um zu entscheiden, welche Skript-Antwort eine schnelle Eingabe erhält, und die Tour wartet auf markante Wörter aus diesen Antworten ("sync", "yours", "4.2"). Wenn Sie ein Fixture umformulieren, läuft das Warten, das darauf angewiesen ist, in einen Timeout.

Alle Fixture-Daten und jede skriptgesteuerte KI-Antwort befinden sich in demo/mock/data.ts – das ist die Datei, die Sie bearbeiten müssen, wenn die Demo etwas anderes zeigen soll (andere E-Mails, eine andere Zusammenfassung, einen anderen formulierten Antwortentwurf).

Nicht offensichtliche Dinge, die Sie beißen werden, wenn Sie record.mjs bearbeiten:

• Der Composer-Textbereich ist ein <textarea>. Sein gestreamter Inhalt ist sein value, nicht sein text – warten Sie mit waitValue, nicht mit waitText.
• .compose-window textarea trifft auch die KI-Anweisungsbox (sie kommt zuerst im DOM). Verwenden Sie .compose-window > textarea für den Textkörper.
• Composer-Szenen navigieren per Hash und müssen page.reload() aufrufen – ein reines goto per Hash mountet die SPA nicht neu, daher erscheint der Composer nie.
• Speichern Sie das Video mit video.saveAs(), bevor Sie browser.close() aufrufen, sonst schlägt es mit "target closed" fehl.

Tempo und Themes

Die Standardwerte sind auf ein lesbares Landing-Video abgestimmt. Pro Lauf mit Umgebungsvariablen überschreibbar (alle in ms): DEMO_READ (Verweildauer pro Bildschirm), DEMO_BEAT (zwischen Aktionen), DEMO_TYPE (Tastenanschlagsverzögerung) und DEMO_AI_TYPING / DEMO_AI_THINK / DEMO_AI_STEP (KI-Stream-Rhythmus). Nützlich, wenn eine Szene gehetzt wirkt, nachdem Sie Inhalt hinzugefügt haben.

Themes haben zwei Achsen – "<cold|warm>-<light|dark>", z.B. warm-light (die App-Standardeinstellung). Beide Skripte erzwingen das Theme über localStorage (skimdemo.theme), das der Mock von get_settings zurückgibt:

• Das Video ist auf warm-light festgelegt; überschreiben mit DEMO_THEME=cold-dark npm run demo:record.
• Screenshots rendern warm-light → docs/skim-light.jpg und warm-dark → docs/skim-dark.jpg (das SHOTS-Array in demo/screenshots.mjs ordnet Theme → Dateiname zu).

Achten Sie auf alte einachsige Werte: "light" und "dark" werden noch geparst, aber der cold-Palette zugeordnet, sodass beim Übergeben stillschweigend die falsche Farbtemperatur gerendert wird, anstatt ein Fehler zu erscheinen.

DEMO_PREBUILT=1 bedient einen statischen Build aus demo/dist-demo anstelle des Dev-Servers – praktisch in ressourcenbeschränkten oder kopflosen Umgebungen.

Weitere Details finden Sie in demo/README.md.