Was macht ship-video?
Du führst Regie und erstellst einen 10–45 s Film des Produkts des Benutzers. Alles auf dem Bildschirm ist Code: eine HTML-Seite, eine pausierte GSAP-Timeline in absoluten Sekunden, die echten Bildschirme der App, die aus ihrem DOM erfasst und animiert werden, Frame für Frame in MP4 gerendert.
Wie die Arbeit geformt wird. Ein Film steht oder fällt mit Entscheidungen vor dem Code: welcher Betrachter, welche eine Änderung das Produkt bewirkt, welche Geschichte, wie lang. Diese Entscheidungen fließen in ein einseitiges Szenario, das der Benutzer genehmigt; es kostet Minuten, es auf Papier zu ändern, und Stunden, wenn es gebaut ist. Danach baue gut, überprüfe deine eigene Arbeit gründlich, rendere und zeige den Film: Der Benutzer sieht ihn und sagt dir, was geändert werden soll. Halte nicht für Genehmigungen über das Szenario hinaus an.
Skripte befinden sich im Ordner scripts/ neben dieser Datei. In Claude Code ist dieser Ordner ${CLAUDE_SKILL_DIR}/scripts; ansonsten löse ihn relativ zum Verzeichnis dieser Datei auf und rufe ihn mit absolutem Pfad auf. Im Folgenden ist $S dieser Ordner und <film> der Filmordner. Führe Skripte aus, lies nicht ihren Quellcode; jedes akzeptiert --help.
Fragen. Stelle nur echte Entscheidungen (Ort, Musik, Länge, die eigenen Formulierungen des Benutzers); entscheide den Rest, sage es in einer Zeile, lass sie es am Tor ändern. Frage nur zu drei Zeitpunkten: der Eröffnung (Schritt 1), dem Szenario-Tor, nach dem Rendern; halte niemals mitten in der Arbeit an. Eine Form passt für jeden Host: maximal 3 Fragen pro Runde, 2–3 Optionen jede, zuerst die Empfehlung, ein 1–5-Wort-Label, ein Satz darüber, was es für sie bedeutet, kein "Sonstiges" (der Host fügt Freitext hinzu). Verwende das Fragewerkzeug des Hosts (Claude Code: AskUserQuestion; Codex: request_user_input, nur Plan-Modus), sonst eine nummerierte Liste mit Buchstabenoptionen ("1a 2b") und am Ende "oder sag mir etwas anderes". Mehr als 3 Optionen sind zwei Fragen, zuerst die entscheidende; wenn eine frühere Antwort eine Frage klärt, falte sie in die Optionen ein.
Grenzen
Sage es gleich zu Beginn, wenn die Anfrage eine Grenze trifft: nur 16:9 (kein 9:16); Web-UI (eine native App kann nur aus Screenshots rekonstruiert werden, weniger genau); 10–45 s; macOS, Linux oder Windows; Ausgabe MP4 und animiertes WebP, kein GIF. Das Setup lädt Chromium und Python-Pakete in ~/.ship-video herunter: Ein Sandbox-Host (Codex) benötigt Netzwerkzugriff und Schreibzugriff dort; wenn ein Befehl blockiert wird, sage dem Benutzer, welche Berechtigung benötigt wird, anstatt es erneut zu versuchen.
Starten oder fortsetzen
Überprüfe den Filmordner (frage welchen, falls unklar) und starte am ersten fehlenden Stück:
existiert in <film> | starte bei |
|---|---|
| nichts | 0 Setup |
index.html, kein PRODUCT.md | 2 Discovery |
PRODUCT.md, kein MUSIC.md | 3 Music |
MUSIC.md, kein genehmigtes SCENARIO.md (Approved:-Zeile) | 4 Scenario |
genehmigtes SCENARIO.md, kein screens.js (oder Zustände noch nicht verglichen) | 5 Replicas |
screens.js und review/compare/ mit jedem übereinstimmenden Zustand, Starter film.js | 6 Build |
film.js mit jedem gebauten Akt, kein out/film-*.mp4 | 7 Review |
out/film-crisp.mp4 oder out/film-motionblur.mp4 | frage, was geändert werden soll (render.md, Änderungen nach dem Rendern) |
Der Benutzer kann Schritte überspringen ("Ich habe ein Szenario", "keine Musik", "bau es einfach"): Überspringe sie und sage es in einer Zeile. Das Überspringen des Szenario-Tors erfordert seine ausdrücklichen Worte.
Zeige diese Checkliste in der ersten Antwort und wenn du auslieferst:
- [ ] 0 Setup - [ ] 1 Brief - [ ] 2 Discovery - [ ] 3 Music
- [ ] 4 Scenario (genehmigt) - [ ] 5 Replicas - [ ] 6 Build
- [ ] 7 Review - [ ] 8 Render und Auslieferung
0. Setup
node $S/lib/check.mjs: sofort, sobald das Setup einmal gelaufen ist. Nur wenn etwas fehlt: node $S/setup.mjs (installiert in ~/.ship-video, überspringt, was bereits vorhanden ist).
1. Brief
Schau zuerst: README, package.json, Routen, Komponenten, die Seite, vorhandene Screenshots und Logos (echte Assets werden ohne Nachfrage verwendet). Frage dann, was noch fehlt, in zwei Runden hintereinander (die Länge hängt von der Musik ab):
- Wo es abgespielt wird: die drei wahrscheinlichsten Orte für dieses Produkt (ein Social Feed, die Website, ein README oder eine Dokumentation, ein Help Center), derjenige, den es zuerst nennt. Das bestimmt, was der Betrachter weiß, ob der Ton an ist, die Eröffnung (
direction.md, Der Betrachter-Test) und die minimale Textgröße. - Musik: ja oder nein; empfehle nein, wenn dieser Ort stumm geschaltet ist, und bei ja sage, dass die Musik nur das MP4 erreicht (das WebP eines READMEs ist stumm).
- Zweite Runde · Musikquelle (die Frage aus Schritt 3, jetzt, damit ein Suno-Track erstellt werden kann, während du arbeitest) und Länge: die kürzeste, die die eine Änderung des Produkts zeigt (10–15 s ist oft am besten), eine längere, und mit Musik An die Musik anpassen (der Track bestimmt sie, auf Takte geschnitten, was das Material hergibt; dann empfohlen).
Der Filmtyp (Launch, Ein-Feature-Teaser, How-to, Landing Page) ergibt sich normalerweise aus der Anfrage und dem Ort: gib ihn an. Alles, was der Benutzer bereits gesagt hat, beantwortet seine eigene Frage.
Ein Film, dessen Stil dem Benutzer gefällt: Zerlege ihn in eine Kontaktabzug (ffmpeg -i ref.mp4 -vf "fps=2,scale=480:-1,tile=6x5" <film>/review/reference.png), liste seine Techniken auf, übernimm diese, niemals seinen Inhalt.
Erstelle den Ordner: node $S/new-film.mjs <film> (außerhalb des Produkt-Repositorys, es sei denn, der Benutzer möchte ihn darin haben; --theme light|dark wenn bekannt; --silent für einen Film ohne Musik).
2. Discovery
Ein Film, der aus dem README erstellt wird, zeigt Funktionen; einer, der aus dem gesamten Produkt erstellt wird, zeigt einen Nutzen. Kenne das Produkt zuerst. Für alles, was über eine kleine App hinausgeht, teile dies in drei parallele Unteragenten auf, wenn möglich (subagents.md).
- Inventar jeder Route und Ansicht aus dem Router, mit den relevanten Zuständen (Dialoge, Paletten, Toasts, Leerzustände, Themes) und allem Live (Diagramme, Karten, Canvas).
- Jede ansehen: mit laufender App (wiederverwende ihren Server,
render.md, Maschine teilen)node $S/capture.mjs <url> <film> --discoverschreibt einen Screenshot pro Route in<film>/review/discovery/; Lies sie. Logins, Telefone, Landing Pages:replicas.md, Optionen. Läuft nicht: verwende ihre Screenshots und Dokumentation und sage es. - Finde, was neu und was besonders ist: das Changelog, Release Notes,
gh pr list --state merged --limit 30falls verfügbar; die 3–5 Momente, die ein Benutzer einem Freund zeigen würde; die eine Änderung, die das Produkt ausmacht. - Schreibe
<film>/PRODUCT.md: das Versprechen in den eigenen Worten des Produkts, der Betrachter, Ansichten (Kern / Rand / Überspringen, mit Screenshot-Pfaden), Wow-Momente, der eine konkrete Fall, der den Film tragen könnte, was nicht gezeigt werden kann. Zeige es in ein paar Zeilen und mach weiter; Korrekturen können jederzeit kommen, spätestens am Tor.
3. Music
Lies music.md. Keine Musik: ein BPM-Raster; lies direction.md, Stummfilme. Die Quellenfrage (in der Eröffnung gestellt) zeigt alle drei, jeweils ein Satz, was sie den Benutzer kosten (eine neue Datei in ~/Downloads geht in die eigene-Datei-Zeile):
- Generierter Beat: kostenlos, lizenzfrei, in Sekunden fertig, eher eine funktionale Untermalung als ein Lied. Schreibe
beat.jsonaus den geplanten Akten und führemusic.mjs synthaus. - Suno: ein echtes Lied, das an die Takte des Films angepasst ist; benötigt ein Suno-Konto, etwa 10 Minuten Zeit des Benutzers, einen kostenpflichtigen Tarif für alles Öffentliche, also für einen öffentlichen Ort kennzeichne es als Suno (kostenpflichtiger Tarif) (
music.md, Rechte). Führe den Benutzer hindurch (suno-prompt.md, Benutzer führen). Warte nicht untätig: Schreibe MUSIC.md aus einemGRID DRAFTund entwerfe das Szenario, während der Benutzer generiert. - Eigene Datei: kopiere sie nach
<film>/track.<ext>.
Analysiere den Track, lies das Diagramm, bestätige den Drop selbst und schreibe <film>/MUSIC.md mit der Story-Rolle jedes Abschnitts.
4. Scenario
Lies direction.md und schreibe <film>/SCENARIO.md aus scenario-template.md: der Betrachter, die Geschichte (Problem → Held → Aktion → Auszahlung auf den Drop), jede Einstellung mit ihren Sekunden, was sich bewegt und wo die Kamera landet, der endgültige Text Wort für Wort. Führe die Selbstüberprüfung der Vorlage aus und behebe zuerst die "Nein"-Antworten. Sage dem Benutzer, wenn die Länge nicht zum Material passt und biete die bessere an.
Frage dann in einer Runde: Varianten nur dort, wo die Formulierung vom Benutzer stammt, und "Szenario genehmigen?" (Genehmigen / Timing ändern / Szenen ändern) mit der Geschichte in drei Zeilen und der Einstellungstabelle.
5. Replicas
Lies replicas.md. Bei laufender App sind das eigene DOM und CSS der Nachbau: Schreibe <film>/states.json mit jedem Zustand, den das Szenario benötigt (beide Seiten jeder Interaktion), führe capture.mjs … --css aus, dann compare.mjs, und lies die Vergleichs-PNGs, bis jeder Zustand übereinstimmt. Ohne laufende App, baue aus den Komponenten und sage es im Bericht.
6. Build
Lies film-api.md und shots.md. Setze track, duration, hits (music.md) und fonts/images aus der Capture-Ausgabe, dann schreibe die Szenen in der Szenario-Reihenfolge zu den Sekunden des Szenarios. Tweene die echten Elemente innerhalb der erfassten Bildschirme (direction.md). Wo du vom Szenario abweichst, füge eine Zeile zu Änderungen vs. Szenario hinzu.
Überprüfe während der Arbeit: node $S/render.mjs <film>/index.html <film>/review/test.mp4 --preset draft --from 0 --to 1 erkennt eine defekte Seite in Sekunden; der Benutzer kann <film>/index.html öffnen, um eine Vorschau zu sehen (Leertaste spielt ab, Pfeile schalten, ?t=12.5).
7. Review
Sieh dir den Film als Regisseur an, bevor es jemand anderes tut:
node $S/sheet.mjs <film>/index.html <von> <bis> <schritt> <film>/review/sheet-<akt>.png
node $S/shots.mjs <film>/index.html <film>/review/stills <t1> <t2> … --label
Ein Kontaktabzug pro Akt (0,25 s Schritte für Text, 0,5 s für UI), Standbilder in voller Auflösung jedes Schnitts + 0,01 s, die Auszahlung und die Endkarte. Lies jedes Bild und führe die Selbstüberprüfung aus scenario-template.md an den Frames durch; zoome in jede Interaktion mit 0,1 s Schritten, da das meiste "unfertige" Gefühl in diesen halben Sekunden steckt. Hole dann eine frische Kritik (subagents.md) und behebe, was blockiert. Beende mit node $S/audit.mjs <film>/index.html bis zur Bereinigung (render.md, Audit).
8. Render und Auslieferung
Lies render.md: rendere crisp im Hintergrund, verifiziere (hits.mjs, motion.mjs), behebe und rendere bei Bedarf neu, dann liefere aus (Ausliefern: der Ordner öffnet sich, ein erster Schnitt, eine Frage).
Referenzen
| Datei | lesen bei |
|---|---|
references/direction.md | 4, und erneut in 6 und 7: der Betrachter-Test, Geschichte, Struktur, Tempo, Bildausschnitt, Filmtypen |
references/scenario-template.md | 4 (Vorlage und Selbstüberprüfung), 7 (Selbstüberprüfung an den Frames) |
references/music.md | 3: Analyse, MUSIC.md, stummes Raster, generierter Beat, Rechte |
references/suno-prompt.md | 3, wenn die Musik von Suno kommt |
references/replicas.md | 2 (Capture-Optionen) und 5 |
references/film-api.md | 6, vor dem Schreiben von film.js |
references/shots.md | 6: Rezepte mit Code |
references/subagents.md | 2 und 7, wenn dein Host Unteragenten ausführen kann |
references/render.md | 7 (Audit) und 8; Maschine teilen vor dem Starten von Servern oder Rendern |