Trainingsvideos für Systeme
Zeichnet die reale Nutzung eines Web-Systems auf und wandelt sie in fertige Trainingsvideos um: ein kurzes Video pro Kapitel und ein Gesamtvideo mit Kapitelmarken. Es gibt keine Sprachaufnahme. Kurze Callouts erklären, was gerade passiert und warum.
Die Methode ist festgelegt, weil jeder Teil ein echtes Aufnahmeproblem löst. Nur das Aussehen ändert sich von System zu System.
| Bleibt in jedem System gleich | Kommt vom System selbst |
|---|---|
| 1920 × 1080 Video, 30 Bilder pro Sekunde, MP4 | Karten- und Callout-Farben, von seinen Seiten gelesen |
| Titelbild: Logo, Vorspann, Titel, eine Zeile, Farbband | Highlight-, Pfeil- und Klickring-Farbe |
| Callout-Box mit Pfeil und Hervorhebung des Elements | Überschriften- und Fließtext-Schriften, inkl. Webfonts |
| „Schritt n von N“-Zähler in einer Ecke | Eckenrundung, übernommen von seinen Buttons |
| Langsamer Cursor, Klickringe, sanfte Zooms, Jump Cuts über Ladezeiten | Logo |
| Soundeffekte, im Code erzeugt | Helle oder dunkle Callouts, je nach Hintergrund |
| Schwarze Kapitelkarten und Marker im Gesamtvideo | Sprache und Rechts-nach-Links-Text |
Regeln und warum sie existieren
- Eine lokale Kopie mit fiktiven Daten nur. Die Skripte klicken und speichern echt, und ein Video kann mit jedem geteilt werden. Die Engine verweigert nicht-lokale Adressen. Nur der Eigentümer des Systems darf
allowRemote: truesetzen, und nur für einen Testserver, der keine echten Daten enthält. Richten Sie es niemals auf ein Live-System und zeigen Sie niemals echte Namen, E-Mails oder Dokumente. - Die Anwendung wird nicht geändert. Alles lebt im
video-tour/Ordner des Projekts, der seine eigenen Pakete hat. Wenn ein Arbeitsablauf nicht gezeigt werden kann, ohne die App zu ändern, lassen Sie ihn weg und melden Sie ihn. - Videos bleiben außerhalb des Repositorys. Sie werden in einen Ordner außerhalb davon abgelegt.
- Befolgen Sie die eigenen Regeln des Projekts. Lesen Sie zuerst dessen
CLAUDE.mdoder ähnliche Dateien. Wenn dort steht, dass der Eigentümer git ausführt, führen Sie git nicht aus. Auf einem kleinen Rechner führen Sie nur eine schwere Aufgabe gleichzeitig aus. - Nicht vortäuschen, was das System nicht kann. Ein Arbeitsablauf, der vom heutigen Datum, einem externen Dienst oder einer Funktion mit wechselnden Antworten (ein Chatbot) abhängt, wird weggelassen und gemeldet. Alle vor der Aufnahme vorbereiteten Daten werden im Bericht offengelegt.
Schritt 1: Sammeln, was Sie brauchen – einmal
Schauen Sie zuerst im Projekt nach: README, package.json, Dokumentation, Seed-Daten, Testkonten. Fragen Sie dann nach allem, was noch fehlt, in einer Liste und fragen Sie nicht weiter nach, bis die erste Liste beantwortet ist.
- Wie das System lokal gestartet wird und seine Adresse.
- Wie die Testdaten zurückgesetzt werden. Ohne Zurücksetzen kollidieren Kapitel mit den Daten der anderen.
- Testkonten, eines pro Rolle, die die Videos benötigen.
- Für wen die Videos sind. Das bestimmt, welche Aufgaben wichtig sind und die Worte auf den Karten.
- Die Sprache der Callouts. Standard: die Sprache der Systembildschirme.
- Wohin die Videos gehen sollen. Standard: ein Ordner neben dem Projekt.
Schritt 2: System kennenlernen und Kapitel planen
Lesen Sie seine Routen, Menüs und jede Benutzerdokumentation und öffnen Sie die Seiten im laufenden System. Schreiben Sie dann einen Kapitelplan: ein Kapitel pro Bereich, in dem eine Person wirklich arbeitet, jedes aufgebaut um Aufgaben („Einen Auftrag erstellen und zur Freigabe senden“), nicht um einen Rundgang durch die Bildschirme. Ein Kapitel hat normalerweise 2 bis 6 Schritte und läuft 1 bis 4 Minuten. Beginnen Sie mit einem „Erste Schritte“-Kapitel. Listen Sie auf, was Sie wegzulassen planen, mit dem Grund.
Schritt 3: Einrichten und das Aussehen des Systems auslesen
node ~/.claude/skills/system-training-videos/scripts/init.mjs <Projektordner> --out "<Videoordner>"
cd <Projektordner>/video-tour && npm install && npx playwright install chromium
Füllen Sie jedes TODO in video-tour/tour.config.mjs aus. Überprüfen Sie, ob der Login funktioniert, indem Sie den nächsten Befehl ausführen, der ihn verwendet:
node video-tour/tour.mjs brand
Dies besucht das System, liest sein Aussehen, schreibt theme.json und das Logo und speichert vier Vorschauen im Ordner <Videoordner>/_work/brand/: title-card.png, chapter-card.png, callout.png und counter.png. Schauen Sie sich alle vier an. Die Farberkennung ist eine gute Schätzung, keine Tatsache, also beurteilen Sie sie als Zuschauer: Sieht das wie das System aus? Ist das richtige Logo vorhanden? Ist die Überschrift in der echten Schriftart? Korrigieren Sie alles mit theme in der Konfiguration, führen Sie dann brand erneut aus. Siehe references/theme-and-config.md.
Schritt 4: Kapitel 1, dann eine Genehmigung
Schreiben Sie Kapitel 1 (lesen Sie zuerst references/writing-chapters.md), dann:
node video-tour/tour.mjs make 1
make setzt die Daten zurück, führt eine schnelle Probe durch, setzt erneut zurück, zeichnet auf, erstellt und prüft. Schauen Sie sich das Standbild und das Kontaktblatt an, das es druckt.
Halten Sie dann an und zeigen Sie dem Eigentümer den Kapitelplan, die weggelassenen Aufgaben und das Standbild. Dies ist die eine Genehmigung. Es ist günstig, das Aussehen oder den Plan jetzt zu ändern, und teuer nach einer vollständigen Serie. Nach dem OK beenden Sie die Serie ohne Unterbrechung.
Schritt 5: Die anderen Kapitel
Für jedes Kapitel: Schreiben Sie es, führen Sie make aus und schauen Sie sich sein Kontaktblatt an. check fängt ein, was messbar ist: Callouts auf dem Bildschirm unter 2,5 s, Ladebildschirme in der Kamera, Browserfehler, Lautstärkepegel. Es kann keine Bedeutung erkennen, also lesen Sie die Einzelbilder selbst auf:
- einen Callout auf dem falschen Element oder am Bildschirmrand abgeschnitten;
- einen Callout, Zähler oder Popup, das das abdeckt, was der Zuschauer sehen muss;
- eine Fehlermeldung, eine leere Seite oder etwas, das nicht fiktiv ist;
- einen Zoom, der das abschneidet, was er zeigen soll.
Wenn etwas auf dem Kontaktblatt zweifelhaft ist, ziehen Sie ein Vollbild heraus: ffmpeg -ss 20 -i kapitel.mp4 -frames:v 1 frame.png.
Wenn ein Kapitel nach zwei Korrekturrunden immer noch fehlschlägt, überspringen Sie es, melden Sie es und machen Sie weiter. Bereits bekannte Probleme finden Sie in references/troubleshooting.md.
Schritt 6: Das Gesamtvideo
Wenn alle Kapitel erstellt sind und das System läuft:
node video-tour/tour.mjs join
Dies schreibt <name>-training.mp4 mit einer Einleitungskarte, einer schwarzen Karte vor jedem Kapitel, einer Schlusskarte, Kapitelmarken und kapitel.txt („00:00 Titel“-Zeilen, bereit für YouTube). Überprüfen Sie die Länge und die Marken:
ffprobe -v error -show_entries chapter=start_time:chapter_tags=title -of csv=p=0 <Gesamtvideo>
Schritt 7: Bericht
Schreiben Sie für jemanden, der nicht technisch ist, in kurzen Sätzen:
- Den Pfad und die Länge jedes Kapitels und des Gesamtvideos in einer Tabelle.
- Den Ordner mit einem Standbild pro Kapitel.
- Die Kapitelliste mit Startzeiten.
- Was weggelassen oder übersprungen wurde und warum.
- Vor der Aufnahme vorbereitete Daten, die das Video nicht zeigt.
- Kleine visuelle Fehler, die Sie gesehen und akzeptiert haben.
- Dass Sie den Ton durch Messen überprüft haben, nicht durch Hören, daher sollte eine Person ein Kapitel anhören, bevor sie es teilt.
Stoppen Sie dann die von Ihnen gestarteten Server.
Referenzdateien
references/writing-chapters.md: vor dem Schreiben eines Kapitels lesen. Jede Aktion, die Muster, die ein Videobild sauber halten, und wie man Callouts schreibt.references/theme-and-config.md: die Einstellungen, wasbrandliest und wie man das Aussehen korrigiert.references/troubleshooting.md: lesen, wenn eine Aufnahme fehlschlägt oder ein Einzelbild falsch aussieht.