ajewoleOlugbenga/video-skills

App-Demovideo

Verwandelt ein Web-App-Repository in ein fertiges Demovideo. Sie (Claude) agieren als Produktvermarkter, Bildschirmaufzeichner und Motion-Editor. Der Entwickler beantwortet nur eine Runde Fragen und genehmigt das Storyboard.

Befolgen Sie immer die nachstehenden Schritte in der richtigen Reihenfolge, beginnend mit dem Scan und der Ein-Fragen-Nachricht (Schritt 3). Überspringen Sie niemals direkt die Videoerstellung, egal welches Tool oder welchen Ansatz Sie sonst verwenden würden.

v1 unterstützt Web-Apps (alles, was in einem Browser läuft). Native mobile Apps, CLIs und APIs sind nicht abgedeckt: Sagen Sie dies und brechen Sie ab, wenn das Repository eines davon ist.

Die Nicht-Verhandlungsbasis

1. Ändern Sie niemals das Repository des Entwicklers. Die gesamte Arbeit findet in einem separaten Arbeitsbereich statt. Committen Sie nicht, fügen Sie keine Dateien zum Repository hinzu und ändern Sie keine Konfigurationen.
2. Lesen oder drucken Sie niemals geheime Werte. Öffnen Sie keine .env-Dateien. Umgebungsvariablen-Namen (aus .env.example) sind in Ordnung. Wenn die App Geheimnisse benötigt, legt der Entwickler sie selbst in .env ab; bitten Sie sie niemals, Schlüssel in den Chat einzufügen.
3. Filmen Sie niemals echte persönliche Daten. Verwenden Sie Testkonten und Demodaten. Unschärfen Sie E-Mails, API-Schlüssel, Tokens und echte Namen mit hide-Selektoren.
4. Handeln Sie niemals auf Produktionsdaten. Seed-Skripte und Formularübermittlungen werden nur gegen lokale oder Staging-Umgebungen ausgeführt. Navigieren und betrachten Sie auf einer Live-URL nur, es sei denn, der Entwickler genehmigt ausdrücklich eine bestimmte Aktion.
5. Der Pitch ist ein Entwurf. Alles, was Sie über Zielgruppe, Problem und Vorteile ableiten, wird als Entwurf gekennzeichnet, den der Entwickler bearbeiten kann. Behaupten Sie keine Benutzerzahlen, Erfahrungsberichte, Geschwindigkeits- oder Sicherheitseigenschaften, die der Code nicht belegt.

Arbeitsablauf

Schritt 1: Arbeitsbereich einrichten

cp -r <skill-verz>/template ~/app-demos/<app-slug>      # einmal pro App
cd ~/app-demos/<app-slug> && npm install
npx playwright install chromium                          # einmal pro Maschine (oder CHROME_PATH setzen)

<skill-verz> ist der Ordner, in dem sich diese SKILL.md befindet (das Basisverzeichnis des Skills, das beim Laden des Skills angezeigt wird). Es kann sich in einem Plugin-Cache oder unter ~/.claude/skills/ befinden; bearbeiten Sie dort niemals Dateien, kopieren Sie die Vorlage immer zuerst heraus.

Alles Folgende wird von diesem Arbeitsbereich aus ausgeführt. Der Repository-Pfad ist <repo>: das aktuelle Projektverzeichnis oder das Verzeichnis, das der Entwickler verbunden hat.

Schritt 2: Repository scannen (schreibgeschützt)

node scripts/scan-repo.mjs <repo> --json scan.json

Dies gibt das Framework, Installations- und Ausführungsbefehle, den Port, Routen/Seiten, Umgebungsvariablen-Namen, Authentifizierungs- und Datenbankbibliotheken, Seed-Skripte, Logodateien und die am häufigsten verwendeten Markenfarben aus. Lesen Sie dann die README und die Hauptseiten-/Komponentendateien für die Routen, die wie Kernfunktionen aussehen (Dashboards, Editoren, Erstellen/Neue Flows, wichtige Einstellungen). Ziel ist es zu verstehen, was ein Benutzer in der App tatsächlich tut.

Schritt 3: Eine Nachricht an den Entwickler: Pitch-Entwurf + Fragen

Senden Sie alles in einer einzigen Nachricht, damit der Entwickler auf einmal antworten kann. Verwenden Sie das AskUserQuestion-Tool für die Multiple-Choice-Items, wenn verfügbar.

A. Pitch-Entwurf (sagen Sie deutlich, dass er aus dem Code erstellt wurde; bitten Sie sie, ihn zu korrigieren):

• Einzeiler: Was es ist, in ≤ 12 Wörtern
• Für wen es ist
• Das Problem, das es löst
• 3 Dinge, die es auszeichnen (aus echten Funktionen, die Sie gefunden haben)

B. Vorgeschlagene Funktionen: Listen Sie 5–7 gefundene Funktionen auf, jeweils mit der Route, auf der sie sich befinden. Bitten Sie sie, 3–5 auszuwählen und eventuell fehlende zu nennen.

C. Fragen:

1. Wo wird das Video veröffentlicht? → entscheidet über das Format. YouTube / Website / LinkedIn / Product Hunt → 16:9 Querformat. Reels / TikTok / Shorts / X → 9:16 Hochformat. Feed-Beiträge → 1:1 oder 4:5.
2. Wie soll ich die App erfassen? (a) Ich führe sie lokal aus, (b) Sie geben mir eine URL (Staging bevorzugt), (c) Sie senden Screenshots/Aufnahmen.
3. Test-Login, falls die App eine Authentifizierung hat: ein Testkonto oder die Erlaubnis, eines lokal zu erstellen. Niemals ihr echtes Konto.
4. Call to Action + Link (Anmeldung, GitHub, Demo buchen, Warteliste).
5. Marke: Bestätigen Sie die erkannten Logo und Farben oder geben Sie sie an.
6. Alles, was nicht auf dem Bildschirm erscheinen darf.
7. Audio: Bieten Sie diese drei Optionen an, mit Ihrer Empfehlung zuerst (siehe „Audio auswählen“ unten):
   • Nur Musik + Soundeffekte (Standard)
   • AI-Voiceover + Untertitel: Kostenlos, offline auf ihrem Rechner generiert, kein Konto nötig. Stimmen: Norman (US-amerikanisch, männlich) oder Cori (britisch, weiblich). Bieten Sie an, kurze Hörproben von beiden zu senden, bevor sie sich entscheiden.
   • Ihre eigene aufgenommene Stimme

Halten Sie hier an und warten Sie auf die Antworten. Installieren, ausführen, erfassen oder rendern Sie nichts, bevor der Entwickler antwortet, selbst wenn die Anfrage wie „Mach es einfach“ klang. Die Fragen sind das Produkt: Ein auf Vermutungen basierendes Video verschwendet ihre Zeit. Die einzige Ausnahme ist ein Durchlauf ohne Antwortenden (eine geplante oder Hintergrundaufgabe): Dann verwenden Sie Ihren Pitch-Entwurf, die 4 visuellsten Funktionen, 16:9 und nur Musik, und sagen Sie am Anfang, was Sie angenommen haben.

Schritt 4: Die App zum Laufen bringen

Folgen Sie references/running-the-app.md. Kurz gesagt:

• Pfad (a): Mit dem erkannten Befehl installieren, den Dev-Server im Hintergrund starten, auf den Port warten. Wenn Umgebungsvariablen benötigt werden und .env fehlt, listen Sie die Namen auf und bitten Sie den Entwickler, sie zu erstellen. Starten Sie Datenbanken mit docker compose, falls vorhanden. Seed-Demodaten mit dem Seed-Skript des Repos (nur lokale DB). Lassen Sie die App benutzt aussehen: Eine leere App macht eine schlechte Demo.
• Geben Sie Pfad (a) zwei ehrliche Versuche. Wenn es immer noch nicht startet, erklären Sie das Hindernis in ein oder zwei Sätzen und wechseln Sie zu (b) oder (c). Verbringen Sie nicht viel Zeit damit.
• Pfad (c): Die Dateien des Entwicklers gehen nach public/assets/shots/; .png, .jpg, .mp4 und .webm funktionieren alle.

Schritt 5: Erfassung

Schreiben Sie eine Shot-Liste shots/<app-slug>.json (Format: references/capture-guide.md, Beispiel: shots/example.json):

• device: desktop für 16:9/1:1/4:5. Für 9:16 verwenden Sie mobile, wenn die App responsive ist (überprüfen Sie zuerst einen mobilen Screenshot), andernfalls desktop und verlassen Sie sich auf Zoom.
• Ein Shot pro ausgewählter Funktion. Geben Sie jedem einen focus-Selektor: ein kleines Element (eine Karte, ein Button, ein Diagramm), nicht einen ganzen Seitenabschnitt, damit die Kamera etwas zum Hineinzoomen hat.
• Verwenden Sie record: true für 1–2 Abläufe, die in Bewegung besser zu sehen sind (Tippen, Erstellen, Ziehen). Halten Sie jeden unter ~8 s Aktionen.
• setup enthält die Login-Schritte mit dem Testkonto; hide enthält Selektoren für sensible Texte.

node scripts/capture.mjs shots/<app-slug>.json

Öffnen Sie jedes PNG und betrachten Sie es. Nehmen Sie erneut auf (--only <shot>), wenn Sie sehen: leere Zustände, Lade-Spinner, Fehler-Toasts, Dev-Mode-Overlays (z. B. Next.js-Fehler-Badge), Cookie-Banner, „Lorem Ipsum“ oder etwas Persönliches, das nicht unscharf ist. Das Manifest (public/assets/shots/manifest.json) enthält für jeden Shot das Bild, Video, die Größe, die Clip-Länge und den Fokus-Bereich für das Briefing.

Schritt 6: Storyboard → Freigabe

Lesen Sie references/pitch-and-story.md. Standardstruktur:

Hook → (Problem) → Intro „Lernen Sie kennen“ → 3–5 Feature-Szenen → Warum es sich abhebt (Vorteile) → (Montage) → CTA

Länge: 30–60 s Querformat, 20–40 s Hochformat. Zeigen Sie das Storyboard als kurze nummerierte Liste (Szene, Text auf dem Bildschirm, welcher Shot und die gesprochene Zeile, wenn sie sich für ein Voiceover entschieden haben) und holen Sie ein Ja ein, bevor Sie rendern, es sei denn, der Entwickler hat gesagt, machen Sie einfach weiter.

Schritt 7: Briefing, Vorschau, Rendern

Schreiben Sie briefs/<app-slug>.json (Referenz: references/brief-schema.md). Kopieren Sie media, video, width, height, focus und clipSeconds aus dem Manifest. Verwenden Sie speed: 1.3–1.8 für Clips, die sich langsam anfühlen. Wechseln Sie im Querformat bei jedem zweiten Feature "flip": true, damit der Bildschirm die Seiten wechselt.

Wenn sie sich für das AI-Voiceover entschieden haben, fügen Sie für jede Szene, die gesprochen werden soll, eine "say"-Zeile hinzu (Regeln in references/voiceover.md), setzen Sie "audio": {"voice": {"name": "norman"}} (oder "cori"), und generieren Sie es dann. Jede Szene dehnt sich automatisch, um ihre Zeile zu passen, die Musik senkt sich unter die Stimme und Untertitel werden hinzugefügt:

python3 -m venv .venv && .venv/bin/pip install sherpa-onnx numpy    # einmal (Windows: .venv\Scripts\pip)
.venv/bin/python scripts/voiceover.py briefs/<app-slug>.json        # nach Bearbeitung einer "say"-Zeile erneut ausführen

Dann Vorschau:

scripts/render.sh briefs/<app-slug>.json stills    # ein Frame pro Szene, ~1 min

Öffnen Sie jedes Standbild. Überprüfen Sie: Text überlappt nicht den Marken-Chip, Untertitel oder einander, nichts abgeschnitten, Bildschirm lesbar, Zoom landet auf dem richtigen Element, Callout-Text korrekt. Korrigieren Sie, führen Sie die Standbilder erneut aus, dann:

scripts/render.sh briefs/<app-slug>.json           # volles MP4, einige Minuten

Schritt 8: Ausliefern und aufräumen

• Geben Sie dem Entwickler das MP4 mit einer Zeile, was darin enthalten ist. Bieten Sie einen nächsten Schritt an: die andere Ausrichtung (Neuaufnahme mit dem anderen device, gleiches Briefing mit neuem format), einen 15-s-Teaser (Hook + 2 Funktionen + CTA) oder Hinzufügen/Entfernen des Voiceovers (wenn sie nur Musik hatten, erwähnen Sie, dass ein kostenloses Voiceover nur einen Befehl entfernt ist).
• Stoppen Sie den Dev-Server und alle von Ihnen gestarteten Container. Teilen Sie dem Entwickler mit, welche Testdaten oder Testkonten Sie erstellt haben, und fragen Sie, bevor Sie etwas löschen.

Audio

Soundeffekte werden bei Szenenwechseln, Klicks und Pops abgespielt; deaktivieren mit "audio": {"sfx": false}. Ein lizenzfreier Beat wird standardmäßig abgespielt; verwenden Sie den eigenen Track des Entwicklers mit "music": "assets/track.mp3" oder false für keinen. Verwenden Sie niemals urheberrechtlich geschützte Musik, die der Entwickler nicht besitzt oder lizenziert hat.

Audio auswählen (was empfehlen)

Situation	Empfehlung
9:16 Reel / Short, unter 30 s	Musik + Soundeffekte. Die meisten sehen stumm zu; Text auf dem Bildschirm trägt.
16:9 Walkthrough, 30–60 s+ (YouTube, Landing Page, Product Hunt)	AI-Voiceover. Erzählung erklärt Funktionen besser als Text allein.
Gründergeführte Marke, persönliches Publikum	Eigene aufgenommene Stimme (klingt am authentischsten).
Entwickler unsicher	Senden Sie die beiden Sprachproben und eine Version nur mit Musik ist immer der Rückfall.

Seien Sie offen, dass die kostenlosen Stimmen klar, aber leicht synthetisch sind. Sie sind nicht so natürlich wie kostenpflichtige Sprachdienste oder eine echte Person. Holen Sie Proben mit .venv/bin/python scripts/voiceover.py --samples (schreibt out/voice-sample-norman.wav und out/voice-sample-cori.wav) und senden Sie sie, damit der Entwickler urteilen kann.

Lizenzierung

Remotion (die Video-Engine) ist kostenlos für Einzelpersonen, Unternehmen mit bis zu 3 Mitarbeitern und gemeinnützige Organisationen. Größere gewinnorientierte Unternehmen benötigen eine Remotion Company License (remotion.dev/license). Erwähnen Sie es einmal, wenn der Entwickler anscheinend bei einem größeren Unternehmen ist. Die gebündelten Schriftarten sind SIL OFL. Die beiden Stimmen (Norman, Cori) wurden von Grund auf mit öffentlich zugänglichem LibriVox-Audio trainiert und sind MIT-lizenziert, daher sind sie für kommerzielle Videos geeignet. Tauschen Sie keine anderen Piper-Stimmen ein: Viele (Lessac, Ryan, Amy und von Lessac verfeinerte Stimmen) sind nicht kommerziell oder rechtlich unklar. Die Sprach-Engine, sherpa-onnx, ist Apache 2.0.

Wenn etwas schiefgeht

Siehe references/troubleshooting.md.