Communitygithub.com

Vedit – Story-Schnitt

Dieses Skill wird verwendet, wenn der Nutzer darum bittet, vor dem mechanischen Schnitt zu entscheiden, worum es im Video eigentlich geht – „bau die Story“, „was soll ins Video“, „was kann raus“, „welche Themen bleiben“, „kürz das auf 6 Minuten“, „mach daraus ein kurzes Video“, „wo ist der Hook“. Es handelt sich um den CONTENT-Auswahlschritt, der den „story“-Block in project.json schreibt und nach der Transkription und vor dem Grobschnitt läuft.

Was ist Vedit – Story-Schnitt?

Dieses Skill namens „cut-story“ führt die inhaltliche Entscheidungsfindung durch, bevor mechanische Schnitte gesetzt werden. Es analysiert ein transkribiertes Video, segmentiert es in sinnvolle Themenblöcke, bewertet, ob jeder Block zur Kernaussage beiträgt, und erstellt eine strukturierte Story mit einem Hook und einer priorisierten Reihenfolge. Es unterstützt die Zusammenarbeit mit einem „transcript-analyst“-Agenten für lange Transkripte (über 2500 Wörter), um Kontext zu sparen. Die Ausgabe ist ein „story“-Block in der project.json, der die Entscheidungen (keep/drop/maybe) festhält. Das Skill läuft auf Plattformen wie Claude Code, Cursor oder Codex und ist speziell auf den Workflow der Video-Editing-Pipeline abgestimmt.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/businessbaum/vedit/tree/HEAD/.agents/skills/cut-story

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation


name: cut-story description: Dieses Skill sollte verwendet werden, wenn der Nutzer darum bittet, vor dem mechanischen Schnitt zu entscheiden, worum es im Video eigentlich geht – „bau die Story“, „was soll ins Video“, „was kann raus“, „welche Themen bleiben“, „kürz das auf 6 Minuten“, „mach daraus ein kurzes Video“, „wo ist der Hook“, „sortier die Themen“, „worum geht es hier eigentlich“, „build the story“, „decide what stays“, „structure this“, „cut this down to N minutes“, „find the hook“, „reorder the topics“. Dies ist der CONTENT-Auswahlschritt, der den „story“-Block in project.json schreibt; er läuft nach der Transkription und vor dem Grobschnitt. argument-hint: [Projekt-Slug] [Ziel-Minuten] arguments: [project, target]

cut-story

Entscheide, was das Video ist. Mechanischer Schnitt strafft nur, was in der Reihenfolge gesagt wurde, in der es gesagt wurde; dieser Durchlauf entscheidet, welche Themenblöcke überleben, in welcher Reihenfolge und wo der Hook ist. Es ist die einzige Phase, die aus einem 25-minütigen Geschwafel ein 6-minütiges Video machen kann, und sie ist die Phase, die am meisten darüber entscheidet, ob jemand zusieht.

Argumente: $project ist der Projekt-Slug, $target eine optionale Ziellänge in Minuten. Der vollständige Anfrage-Text steht in $ARGUMENTS. Wenn kein Slug angegeben ist, verwende das Projekt, das im Session-Hook unter PIPELINE_STATE benannt ist, und nenne das ausgewählte Projekt.

Die Verb-Namen unten folgen dem Build-Vertrag. Wenn python engine/ve.py --help widerspricht, hat die CLI Vorrang – verwende ihre Namen und erwähne die Abweichung.

Vorbedingungen

  • projects/$project/project.json existiert mit stage auf transcribed oder später.
  • transcript.path ist auflösbar und transcript.word_count ist gesetzt.
  • Wenn stage noch intake ist, anhalten und zuerst das Transkribieren-Skill ausführen.

Führe diesen Durchlauf niemals stillschweigend zweimal aus. Falls story.blocks bereits existiert, zeige zuerst die aktuellen Entscheidungen an und frage, ob überarbeitet oder ersetzt werden soll.

Schritt 1 – Ein lesbares Transkript erhalten

Wortgenaues JSON ist unlesbare Prosa. Glätte es zuerst:

python engine/ve.py transcript flatten $project --numbered

Dies gibt die Wörter als Fließtext mit einem Wortindex-Marker alle 25 Wörter aus. Wortindizes sind die Anker, die der story-Block speichert – speichere niemals Sekunden, niemals Timecodes.

Schritt 2 – Dispatch eines Transkript-Analysten bei langen Transkripten

Wenn word_count > 2500 (ungefähr 15 Minuten deutscher Sprache), dispatch den transcript-analyst-Agenten anstatt das Transkript selbst zu lesen.

Warum: Ein Transkript mit 5.000 Wörtern verbraucht den Kontext, den du für den Rest der Sitzung brauchst, und der Analyst gibt etwa 40 Zeilen zurück. Wenn du es selbst liest, machst du dich voreingenommen – nachdem du jeden Satz gelesen hast, fühlt sich alles tragend an. Ein frischer Kontext schneidet härter, was korrekt ist.

Gib dem Agenten: den Pfad zum geglätteten Transkript, die Ziellänge, die Plattform aus output.platform und etwaige Lenkung durch den Nutzer in $ARGUMENTS. Der Agent gibt Kandidaten-Blöcke mit Entscheidungen und Begründungen zurück. Die endgültige Entscheidung liegt immer noch bei dir – überprüfe seine Streichungen und widersprich jeder Streichung, die der Nutzer explizit behalten möchte.

Bei unter 2500 Wörtern lies das Transkript selbst.

Schritt 3 – Das Video in einem Satz benennen

Schreibe vor jeder Blockentscheidung einen deutschen Satz, der sagt, was der Zuschauer am Ende glaubt, was er zu Beginn nicht geglaubt hat. Zeige ihn dem Nutzer.

Wenn dieser Satz nicht geschrieben werden kann, enthält das Material noch kein Video. Sage das klar und stoppe – empfehle eine Nachaufnahme, anstatt etwas Formloses zusammenzustellen. Dies ist ein reales Ergebnis, und es ehrlich zu liefern ist nützlicher als ein ordentliches 6-minütiges Nichts.

Jede spätere Entscheidung muss sich diesem Satz unterordnen.

Schritt 4 – Das Transkript blocken

Ein Block ist eine Bedeutungseinheit, die eine Verschiebung überlebt: 30 Sekunden bis 3 Minuten, ein Punkt. Blöcke sind zusammenhängende Wortbereiche, die das Transkript lückenlos und ohne Überschneidungen kacheln.

Schneide Blöcke nicht an Pausen. Schneide sie dort, wo das Thema wechselt – die eigenen Wegweiser des Sprechers sind im Deutschen zuverlässig: also, jetzt zum Thema, das andere ist, kurz noch, um nochmal zurückzukommen, was viele nicht wissen.

Schritt 5 – Entscheiden, mit einer Tendenz zum Streichen

Standarderwartung: 40-60 % der aufgezeichneten Wörter streichen. Wenn mehr als 70 % des Materials überleben, wurde keine Entscheidung getroffen – gehe zurück und wende die Streichtests härter an.

Streichtests, in dieser Reihenfolge anzuwenden:

  1. Der Glaubens-Test. Entferne den Block. Ändert sich, was der Zuschauer am Ende glaubt? Wenn nicht, streiche ihn. Dies ist der primäre Test; die anderen sind Abkürzungen dorthin.
  2. Der Zweites-Beispiel-Test. Zwei Beispiele für denselben Punkt: behalte das konkretere, streiche das andere. Sprecher wiederholen sich, um zu denken, nicht um zu lehren.
  3. Der Waisen-Test. Aufbau für eine Pointe, die gestrichen wurde, ist jetzt Rauschen. Streiche ihn und prüfe nach jedem weiteren Streichen erneut – Waisen treten kaskadenartig auf.
  4. Der Aufwärm-Test. Die ersten 60-90 Sekunden fast jeder Aufnahme sind Räuspern. Streiche sie standardmäßig und teile dem Nutzer mit, dass du es getan hast. Diese eine Regel verbessert mehr Videos als jede Entfernung von Füllwörtern zusammen.
  5. Der Zusammenfassungs-Test. Gesprochene Zusammenfassungen des gerade Gesagten („also nochmal kurz zusammengefasst“) sind eine Sprechkrücke, keine Struktur. Streiche sie, es sei denn, das Video ist wirklich lehrreich und lang.

Behaltesignale, stärkste zuerst: eine Zahl, ein Name, ein Datum, ein konkreter Fehler, den der Sprecher zugibt, ein konkretes durchgerechnetes Beispiel. Spezifität ist das stärkste Behaltesignal. Abstrakte Rahmung ist billig und kann in zehn Sekunden neu aufgenommen werden; eine konkrete Anekdote nicht.

Verwende "decision": "maybe" für Blöcke, deren Schicksal von der endgültigen Länge abhängt. Halte maybe unter 20 % der Blöcke – darüber ist es keine Nuance, sondern Unentschlossenheit, und der Nutzer muss die Arbeit erledigen, die du tun solltest.

Wenn $target gesetzt ist, plausibilisiere es: Summiere die Wortanzahlen der behaltenen Blöcke und teile durch die gemessene Sprechrate des Sprechers (word_count / Quell-Dauer in Minuten). Gib die Schätzung vor dem Schreiben an. Deutsche Sprecher bei Talking-Head-Aufnahmen liegen bei ~130-160 Wörtern pro Minute.

Schritt 6 – Den Hook finden

Der Hook liegt fast nie am Anfang der Aufnahme. Leute kommen spät zu ihrem eigentlichen Punkt, nachdem sie sich aufgewärmt und aufgehört haben, zu performen.

Suche zuerst im letzten Drittel. Suche nach: einer Behauptung, die sich falsch anhört, bis sie erklärt wird; einer Zahl, die größer oder kleiner ist als erwartet; einem eingestandenen Fehler; einem Einsatz („das hat mich zwei Wochen gekostet“). Wähle 15-25 Sekunden – ein oder zwei Sätze, kein Absatz.

Schreibe es als story.hook mit einem word_range und einer deutschen note, die sagt, warum es verschoben wurde. Den Hook nach vorne zu verschieben, ist die einzige Umordnung, die fast immer richtig ist.

Schritt 7 – Ordnen, und nur umordnen, wenn du den Grund nennen kannst

Es gibt genau zwei legitime Gründe, umzuordnen:

  1. Der Hook kommt nach vorne.
  2. Ein Block beantwortet eine Frage, die ein späterer Block stellt, also muss er vorausgehen.

Alles andere behält die Aufnahme-Reihenfolge. Das Umordnen gesprochenen Materials zerbricht Rückwärtsverweise, und du wirst den Bruch erst beim Rendern hören – zu diesem Zeitpunkt sind bereits drei Phasen gelaufen.

Integritätsprüfung für Rückwärtsverweise, obligatorisch für jeden verschobenen Block. Lies die ersten beiden Sätze des verschobenen Blocks auf Rückwärtsverweise. Im Deutschen brechen diese leise: also, deswegen, deshalb, dadurch, dabei, wie gesagt, das, dieser/diese/dieses, außerdem, trotzdem, andererseits, wie eben erwähnt. Wenn ein verschobener Block mit einem solchen Verweis beginnt, starte den Block entweder einen Satz später oder markiere ihn als maybe und sage dem Nutzer, dass er eine Brücke benötigt. Verschiebe ihn nicht in der Hoffnung, dass es gut geht.

Schritt 8 – Den Story-Block schreiben

Schreibe story.blocks[] und story.hook in projects/$project/project.json genau so, wie das Schema in docs/edl-schema.md definiert: id, word_range (halb-offen, in Wortindizes), label (Deutsch), decision (keep|drop|maybe), order (Ausgabe-Reihenfolge, kann von der Aufnahme-Reihenfolge abweichen), rationale.

Nicht verhandelbare Regeln:

  • Nichts wird gelöscht. Ein gestrichener Block bleibt im Array mit "decision": "drop". Jede Entscheidung muss durch das Umlegen eines Feldes umkehrbar sein. Der Nutzer wird mit einigen deiner Streichungen nicht einverstanden sein und muss sie rückgängig machen können, ohne den Durchlauf neu zu starten.
  • rationale ist ein deutscher Teilsatz und sagt WARUM, nicht WAS. „trägt das Kernargument“ ist nützlich; „spricht über Frame-Snapping“ ist ein Label, kein Grund.
  • order ist dicht über behaltenen Blöcken und beginnt bei 0. Gestrichene Blöcke erhalten ihren Index aus der Aufnahme-Reihenfolge; sie sind inert, dürfen aber nicht kollidieren.
  • Setze stage auf "story". Rühre segments[] nicht an – das ist der Bereich des Grobschnitts.

Zeige dem Nutzer dann eine kompakte Tabelle: Reihenfolge, Label, Entscheidung, geschätzte Minuten. Diese Tabelle ist das Arbeitsergebnis, nicht das JSON.

Schritt 9 – Übergeben

Sage explizit, dass der mechanische Schnitt jetzt nur innerhalb der behaltenen Blöcke läuft, was sowohl korrekt als auch günstiger ist – Füller- und Wiederholungs-Erkennung über Material, das gleich gestrichen wird, ist verschwendete Arbeit. Biete dann das Grobschnitt-Skill an.

Fehlermodi

SymptomUrsacheLösung
Alles sieht essenziell ausTranskript inline gelesen, als es lang warDispatch von transcript-analyst; ein frischer Kontext schneidet härter
85 % des Materials behaltenKeine redaktionelle Entscheidung getroffenWende den Glaubens-Test auf jeden Block erneut an
Video springt nach Umordnung seltsamRückwärtsverweis gebrochenFühre die Schritt-7-Prüfung für jeden verschobenen Block durch
word_range-Lücken oder ÜberschneidungenBlöcke kacheln nichtBlöcke müssen zusammenhängend und halb-offen sein
Nutzer lehnt die meisten Streichungen abFalscher Satz in Schritt 3Schreibe den Ein-Satz-These mit dem Nutzer neu, dann wiederhole

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

businessbaum/vedit

This skill should be used when the user asks for subtitles or on-screen text of what is being said - "brenn die Untertitel ein", "mach Untertitel", "Untertitel drauf", "leg Untertitel drüber", "brenn die Subs ein", "mach die Captions", "Wort für Wort Untertitel", "Karaoke-Untertitel", "korrigier den Untertitel-Text", "burn in the captions", "add subtitles", "burn the subs", "word-by-word captions", "fix a caption typo". Covers ASS generation, the pixel-width grouping rule for German, the font table, and burn-in through libass.

businessbaum/vedit

This skill should be used when the user asks for mechanical tightening of material that is already selected - "mach den Rohschnitt", "bau den Rohschnitt", "schneid die Ähms raus", "nimm die Füllwörter raus", "entferne die Pausen", "kürz die Pausen", "schneid die Versprecher raus", "mach den Radioschnitt", "straff das", "build the rough cut", "cut the fillers", "remove the ums", "tighten the pauses", "trim the dead air", "cut the retakes", "radio edit". Turns kept story blocks into enabled segments in project.json. Does not decide what the video is about - that is cut-story.

businessbaum/vedit

This skill should be used when the user asks for the finished video file - "exportier das", "render das fertig", "mach das final", "renderte das Video", "mach den Endexport", "bau das Video zusammen", "mach es fertig für YouTube", "gib mir die MP4", "export the final", "render the final cut", "make the master", "export for TikTok", "give me the mp4". Covers segment rendering with the cache, guarded concat, the one-pass audio, loudness normalisation and the single mux.

Verwandte Skills