Video Craft Playbook

Was macht Video Craft Playbook?

Dies ist ein Handbuch zur Videoproduktion für Coding-Agents. Es hilft dir, vor dem Start eines Projekts zu sehen: Welche visuellen Fähigkeiten stehen zur Verfügung, um ein qualitativ hochwertiges Video zu erstellen? Bei welchen Ausdrucksformen funktioniert jede Fähigkeit, wo versagt sie, und was kostet sie? Wie wurden frühere Fälle kombiniert, und welche Fallstricke gab es?

Dieses Handbuch legt kein Werkzeug fest. Es gibt keine Standardwerkzeuge und kein festes Rezept: Derselbe visuelle Stil, derselbe Videotyp erfordert unter verschiedenen Zwängen (Budget, Material, Länge, echte Physik nötig? echte Personen nötig? wie viele Änderungsrunden?) völlig unterschiedliche Kombinationen. Die Auswahl liegt bei dir, basierend auf einer gezielten Planung für die aktuelle Aufgabe. Dieses Handbuch bietet nur die Bewertungsgrundlage.

Wie man es verwendet

1. Vor dem Start: Überprüfe ausstehende Rückmeldungen

python3 ~/.agents/skills/video-craft-playbook/scripts/playbook.py status

status listet die noch nicht destillierten Fallkarten (cases/inbox/), die überfälligen Fähigkeitskarten und die Anzahl der Einträge im Backlog (references/lessons-backlog.md) auf; wenn der Schwellwert für die Zusammenfassung erreicht ist, wird consolidate vorgeschlagen. Im Inbox befinden sich nur Karten, die beim letzten Mal als archivierungswürdig eingestuft, aber noch nicht destilliert wurden. Wenn Rückstände vorhanden sind, nimm dir ein paar Minuten, um sie in das Handbuch zu destillieren (siehe Schritt 4), bevor du ein neues Projekt startest. Wenn die Zeit knapp ist, informiere den Benutzer zumindest über die Anzahl der ausstehenden Einträge.

2. Planung: Zerlege zuerst die Ausdrucksanforderungen, dann ordne die Fähigkeiten zu

Beginne nicht mit der Frage „Welches Werkzeug verwende ich?“, sondern mit der Frage „Wodurch wird jedes Element in diesem Video getragen?“:

1. Zerlege das fertige Video in Elemente: Subjekt, Umgebung, Bewegung, Kameraführung, Text und Grafiken, Textur, Ton, Rhythmus.
2. Beantworte für jedes Element die Fragen in references/task-lenses.md: Woher kommt seine „Realität“, ist Frame-genaue Kontrolle erforderlich, wie viele Änderungsrunden, darf es bezahlt werden, wie schnell muss das Video fertig sein?
3. Finde im references/capability-atlas.md für jedes Element mindestens zwei mögliche Fähigkeiten: Scanne zuerst die Übersichtstabelle am Anfang, um Kandidaten auszuwählen, lies dann die entsprechenden Karten; vergleiche und wähle aus, notiere den Grund für die Auswahl und die abgelehnten Alternativen. Die Kandidaten sollten auch „findbares reales Material“ enthalten (Atlas Gruppe H: lokale Materialindizes, offene Materialbibliotheken) – vergleiche nicht nur Generierung und Code; die Quellenstufen und der Pfad „Text → Kamerabeschreibung → Suche → Lizenzprüfung → Synthese“ finden sich in Frage 11 von task-lenses und in craft-lessons L60.
4. Wenn mehrere Fähigkeiten kombiniert werden, lege zuerst die Schnittstellen fest: Zeit-Autorität, Bildrate, Koordinaten und Kamera, Alpha, Farbe, Audio-Bus (Abschnitt 3 von task-lenses).
5. Schreibe vor dem Start eine „Fähigkeits-Arbeitsteilungs-Tabelle“ (Vorlage in Abschnitt 4 von task-lenses) und zeige sie dem Benutzer in der ersten Antwort, dann führe sie aus – warte nicht auf Bestätigung.

Für reine Schnittaufgaben (Material bereits gegeben, hauptsächlich Schnitt und Nachbearbeitung) siehe Abschnitt 6 von task-lenses: Techniken werden in universelle Komponenten und „Signal → Technik“-Regeln zerlegt, siehe references/editing-grammar.md; die Signale und Felder, die von der Verständnisebene erzeugt werden müssen, siehe references/edit-signals.md. Beide Dokumente sind derzeit Annahmen; verwende sie als Ausgangspunkt und beurteile am Ende, ob sie aktualisiert werden können.

Die Grammatik für Kamerabewegungen auf Ebene der Einstellungen (Eröffnung, Übergänge, Titelkarten, UI-Einführungen, Abschluss) kann nach Auswahl von Remotion über den externen Rezepturbibliotheksindex references/shot-vocabulary.md abgerufen werden: Suche nach funktionalen Slots und Energie, dann lies die vollständige Karte und den Demo-Code im Repository; es stammt aus dem Kontext von Produktwerbevideos und wurde lokal nicht verifiziert.

references/composition-patterns.md dokumentiert, wie historische Fälle tatsächlich kombiniert wurden, und kann zur Ideenfindung und Kostenschätzung verwendet werden. Sie sind Lösungen für damalige Aufgaben, keine Vorlagen: Überprüfe vor der Übernahme, ob deine Aufgabenbeschränkungen mit denen von damals übereinstimmen.

3. Ausführung: Handwerk und Fallstricke

• Übergreifende bewährte Vorgehensweisen (Prüfung zuerst, Zeit als einzige Autorität, Bild als reine Funktion von t, Überprüfung in Ebenen, kostenpflichtige Trias, Audio-Standards usw.) siehe references/craft-lessons.md.
• Bekannte Fallstricke nach Werkzeug gruppiert siehe references/pitfalls.md. Bevor du ein bestimmtes Werkzeug verwendest, wirf einen Blick auf seine Gruppe.
• Die konkrete Aufrufweise eines Werkzeugs richtet sich nach dem entsprechenden Skill (jede Karte im Atlas hat einen Einstieg); dieses Handbuch wiederholt keine Befehl Details.

4. Abschluss: Beurteile zuerst, ob es sich lohnt, festzuhalten, dann entscheide ob zurückgeschrieben wird

Das Handbuch wächst durch Fälle, aber nicht jeder Fall muss zurückgeschrieben werden: Nur Details, die wiederholt vorhandene Einträge duplizieren oder nur für diesen einen Fall gelten, würden das Handbuch verwässern. Wenn das Video geliefert (oder die Aufgabe abgebrochen) wird, liste Kandidaten nach Abschnitt 1 von references/writeback.md auf, durchlaufe drei Prüfungen (Wiederverwendbarkeit, Nicht-Ableitbarkeit, Kosten), und zähle nur solche, die alle bestehen und Belege haben; füge sie in vorhandene Einträge ein, anstatt neue zu erstellen.

• Wenn mindestens einer zählt: Schreibe zurück nach Abschnitt 2 von writeback: new-case erstellt Fallkarte → destilliere in die entsprechende Datei (bei vollem Persistent Layer schreibe in references/lessons-backlog.md) → check → close. Wenn die Destillation nicht rechtzeitig erfolgt, lasse die Karte im Inbox; beim nächsten status wirst du daran erinnert.
• Wenn keiner zählt: Überspringe das Zurückschreiben, erstelle keine Fallkarte, führe kein Log. Überspringe ebenfalls, wenn der Benutzer sagt, nicht zurückzuschreiben.

Füge in die finale Lieferdokumentation eine Zeile Playbook-Rückmeldung ein, die die Schlussfolgerung angibt: welche Dateien geändert wurden, oder dass eine Fallkarte noch destilliert werden muss, oder „Übersprungen: <Begründung in einem Satz>“.

Neutralitätsprinzip (gilt sowohl beim Schreiben als auch beim Verwenden des Handbuchs)

• Fähigkeitskarten schreiben nur Fakten: Was sie gut können, was nicht, Kosten, Determinismus, Validierungsquelle. Keine sortierenden Wörter wie „Standard“, „bevorzugt“, „empfohlen“, „priorisiert verwenden“; playbook.py check fängt diese Wörter ab.
• Die Reihenfolge der Karten erfolgt nach Medientyp, nicht nach Rangfolge.
• Wenn ein Werkzeug in einem Fall gut funktioniert hat, notiere es als „unter diesen Einschränkungen, weil ... es funktioniert hat“ – nicht als „dieser Videotyp verwendet es“.
• Auch Fähigkeiten, die nicht in lokalen Fällen validiert wurden, müssen aufgenommen werden, mit dem Vermerk „installiert, nicht validiert“ oder „Annahme“; überspringe sie nicht, weil du sie nicht verwendet hast, und übertreibe nicht, weil du sie verwendet hast.
• Länge ist auch eine Tendenz: Kartenfelder haben eine feste Länge; Funktionslisten und Implementierungsdetails gehören nicht in die Karte; ein häufig verwendetes Werkzeug erhält nicht mehr Platz.
• Wenn ein Eintrag eine Tendenz erkennen lässt (z. B. eine Arbeitsbereichsbeschreibung, die „Standardmäßig X wählen“ sagt), ändere ihn beim Zurückschreiben in eine Bedingung: Unter welchen Einschränkungen ist es geeignet.