RoosterEdit

RoosterEdit ist ein Videostudio für Agenten. Es ersetzt nicht Remotion, HyperFrames oder FFmpeg; es entscheidet, was erstellt wird, organisiert die Assets, schreibt den Plan, steuert die gewählte Engine, überprüft das Ergebnis und liefert das Paket aus.

Die wichtigste Regel: rendern Sie nicht, bevor der Plan und die Vorschau genehmigt wurden, es sei denn, der Benutzer bittet explizit um keine Stopps. Das Rendern ist der günstigste Teil der Pipeline und der teuerste Fehler, um ihn rückgängig zu machen.

Die CLI ausführen

Diese Fähigkeit liefert ihre CLI unter scripts/rooster.mjs relativ zum Basisverzeichnis der Fähigkeit. Führen Sie sie aus dem Projektverzeichnis des Benutzers aus, wobei das Skript gegen die Basis der Fähigkeit aufgelöst wird. In den folgenden Beispielen steht <skill> für dieses Basisverzeichnis:

node "<skill>/scripts/rooster.mjs" doctor --json

Erstellen Sie kein scripts/-Verzeichnis im Projekt des Benutzers, nur um den Befehl zu erfüllen. Der Arbeitsbereich (rooster/) gehört zum Projekt; die CLI gehört zur Fähigkeit. Wenn das Arbeitsverzeichnis der Shell das Fähigkeitsverzeichnis ist, erstellt die CLI den Arbeitsbereich am falschen Ort.

Wo die Fähigkeit installiert werden soll

Wenn der Benutzer Sie bittet, RoosterEdit zu installieren, fragen Sie zuerst, ob die Installation lokal zum Projekt (empfohlen) oder global sein soll. Verwenden Sie den Fähigkeitsordner, den die aktuelle Harness tatsächlich liest; gehen Sie nicht von OpenCode aus.

Lokal: Der projektbezogene Fähigkeitsordner der Harness plus rooster-edit (z. B. .opencode/skills, .claude/skills oder .agents/skills). Empfohlen, da die Version beim Projekt bleibt und andere Arbeiten nicht überraschen kann.
Global: Der globale Fähigkeitsordner der Harness plus rooster-edit (z. B. ~/.config/opencode/skills oder ~/.claude/skills). Verwenden Sie dies nur, wenn der Benutzer RoosterEdit in jedem Projekt auf dem Rechner haben möchte.

Wenn Sie die Ordner der Harness nicht bestimmen können, überprüfen Sie deren Fähigkeitsfindungspfade oder fragen Sie den Benutzer. Warten Sie auf die Antwort, bevor Sie klonen. Diese Wahl betrifft den Speicherort der Fähigkeit, nicht den des Videoarbeitsbereichs (./rooster).

Berichterstattung

End-of-Task-Antworten sind standardmäßig kurz: 5-10 Zeilen oder eine kompakte Tabelle. Fügen Sie nur das hinzu, was der Benutzer zum Handeln benötigt:

was getan oder gefunden wurde;
die Pfade oder Links zum Ergebnis;
was fehlt oder blockiert ist, falls vorhanden;
eine klare nächste Frage.

Wiederholen Sie nicht die Kurzbeschreibung, fügen Sie keine Logs ein, listen Sie nicht jeden Befehl auf und erklären Sie nicht die gesamte Fähigkeit, es sei denn, der Benutzer fragt danach. Legen Sie Details in Arbeitsbereichsdateien ab oder verlinken Sie die Referenzdokumente. Ein Plan, ein QA-Bericht oder ein Lieferpaket darf nur länger sein, weil der Benutzer dessen Inhalt überprüfen muss.

Installation und Arbeitsbereichseinrichtung sind separate Schritte. Beginnen Sie nach der Installation und dem Ausführen von doctor nicht mit dem Onboarding oder schreiben Sie eine Anleitung. Fassen Sie die Umgebung in wenigen Zeilen zusammen und fragen Sie, ob der Benutzer den Arbeitsbereich jetzt konfigurieren möchte. Warten Sie auf ein Ja, bevor Sie rooster/ oder einen Kanal erstellen.

Fortschrittsaktualisierungen

Verwenden Sie einen kompakten Schrittmarker in Statusaktualisierungen und an jedem Genehmigungstor. Führen Sie einen 8-stufigen Tracker für das Projekt:

Umgebung und Arbeitsbereich
Kurzbeschreibung und Aufnahme
Assets und Transkript
Bearbeitungsplan
Storyboard und Timeline
Engine-Build
Vorschau und QA
Rendern und Auslieferung

Beispiele:

Schritt 3/8 — Transkription abgeschlossen. 42 Abschnitte, 10:12 Dauer.
Schritt 4/8 — Plan bereit in edit/plan.html. Kann ich mit der Timeline fortfahren?
Schritt 6/8 — Build abgeschlossen. Kann ich die Vorschau öffnen und die QA durchführen?
Schritt 8/8 — Vorschau genehmigt. Kann ich das Finale rendern?

Überspringen Sie nicht zutreffende Schritte und sagen Sie warum. Drucken Sie die vollständige Checkliste nicht bei jeder Nachricht aus; zeigen Sie den aktuellen Schritt, was sich geändert hat und das nächste Tor. Kombinieren Sie Timeline und endgültiges Rendern nicht in einer Genehmigung: Vorschau und QA liegen dazwischen.

Subagenten-erste Ausführung

Der Hauptagent ist der Regisseur, nicht der Arbeiter. Er spricht mit dem Benutzer, besitzt die Kurzbeschreibung und die Entscheidungen, führt die Genehmigungstore aus und betrachtet die endgültigen Frames. Die laute Arbeit geht an einen Stufen-Subagenten: Transkriptanalyse, Recherche, Drehbuchtentwürfe, Planentwürfe, Stil und Storyboard, Build und Korrekturen, QA-Durchläufe, Rendern und Verpacken. Jeder Subagent hat seinen eigenen Kontext, der verworfen wird, wenn die Stufe endet, sodass sich Rohmaterial niemals im Hauptthread ansammelt.

Delegieren Sie standardmäßig, wann immer die Harness ein Subagenten-Tool hat. Halten Sie die Stufe inline, wenn es sich um einen günstigen Befehl handelt, wenn es sich um das Gespräch selbst handelt (Aufnahme, Genehmigungen) oder wenn es sich um das endgültige visuelle Urteil handelt.

Stufe	Subagent	Hauptagent erhält
Kurzbeschreibung	`producer`	ein-absätzige Kurzbeschreibung + offene Fragen
Recherche	`researcher`	5 Erkenntnisse + Quellen + Lizenzkennzeichen
Transkript	`transcript-analyst`	Dauer, Themen, 10–20 Beats, Kennzeichen
Drehbuch	`scriptwriter`	Aufhänger + Beat-Zusammenfassung
Plan	`editor`	Planzusammenfassung + Risiken
Stil/Storyboard	`art-director`	Token + Szenenzahl + Asset-Bedarf
Timeline	`editor`	Dauerberechnung + Marker
Audio	`audio-director`	Sprach-/Musik-/Mix-Entscheidungen
Build	`engineer`	Status + Artefaktpfade + Blocker
QA	`qa`	Urteil + Hauptprobleme + Framepfade
Rendern	`engineer`	Endgültiger Pfad + Prüfungsstatistiken

Starten Sie mit einer kurzen Eingabeaufforderung: Rollendateipfad, Projektpfad, ein Satz Aufgabe, Eingabepfade, Einschränkungen. Übergeben Sie Pfade, niemals die Kurzbeschreibung, das Transkript, die Logs oder den Planinhalt. Wenn die Eingabe das Gespräch selbst ist, schreiben Sie die Antworten zuerst in work/intake.md. Fragen Sie nach der in references/subagents.md beschriebenen Übergabe und sonst nichts. Verwenden Sie den Allzweck- oder Arbeiteragenten der Harness für Stufen, die Dateien schreiben oder Befehle ausführen; ein Nur-Lese- oder Forschungstyp ist für die Recherche in Ordnung. Dies ist eine Fähigkeit, kein Tool-Name: Wenn die Harness keinen neuen Agenten mit Datei- und Befehlszugriff starten kann oder ein Start zweimal fehlschlägt, führen Sie die Stufe inline aus und behalten Sie die Dateigrenzen bei.

Die Übergabe ist das Einzige, was in den Hauptkontext gelangt:

status: ok | needs-decision | blocked
artifacts: Pfade, die existieren
summary: <= 5 Zeilen
decisions: was der Hauptagent bestätigen muss
blockers: was die Stufe aufhält
next: nächste Stufe oder genaue Frage

Der Hauptagent darf die Kurzbeschreibung, das Drehbuch, den Stil, review.md und die Übergaben lesen und plan.html und 3–5 Frames anzeigen. Er darf nicht das rohe Transkript, das vollständige Plan-JSON, den generierten Code, die Build-/Render-Logs oder ein Kontaktblatt mit Dutzenden von Frames lesen. Wenn ein Detail fehlt, senden Sie eine Nachverfolgung an denselben Subagenten, anstatt die Rohdatei zu öffnen.

Nichts hier ist eine Abhängigkeit. Die Artefakte und Tore sind dieselben, wenn eine Stufe inline ausgeführt wird; Sie verlieren die Kontextisolierung, nicht den Workflow.

Genehmigungstore werden niemals an einen Subagenten weitergegeben. Der Subagent schlägt vor; der Benutzer und der Hauptagent entscheiden.

Erster Lauf nach der Installation

Wenn der Arbeitsbereich noch nicht existiert, führen Sie ein kurzes Onboarding durch, bevor Sie ein Projekt erstellen.

Fragen Sie zuerst: "Möchten Sie den Arbeitsbereich jetzt einrichten?" Erklären Sie in einem Satz, dass dies rooster/ und den ersten Kanal erstellt. Wenn die Antwort Nein ist, hören Sie auf und erstellen Sie nichts.

Wenn die Antwort Ja ist:

Verwenden Sie standardmäßig ./rooster. Fragen Sie nicht "wo soll der Arbeitsbereich leben", es sei denn, der Benutzer möchte einen benutzerdefinierten Pfad.
Stellen Sie eine Frage: "Was wird dieser Kanal produzieren? Ein Satz reicht." Verwenden Sie die Antwort und das Gespräch, um den Kanalnamen, die Sprache, das Format, die Quelle, das Profil, die Assets, die Engine, die Autonomie und die Stimme abzuleiten. Fragen Sie nicht alle zwölf Kanalfelder ab und fragen Sie nicht nach einer Dauer.
Zeigen Sie die abgeleiteten Standardwerte in einer kompakten Zeile an und fragen Sie "Ist das in Ordnung oder möchten Sie etwas anpassen?" Stellen Sie eine Nachfrage nur, wenn ein Feld wirklich mehrdeutig ist, wie z. B. die Plattform oder ob die Quelle echtes Filmmaterial ist.
Führen Sie bei Bestätigung init aus, dann channel new <id> ... mit den Antworten. Zeigen Sie eine kurze Zusammenfassung und hören Sie auf.

Die Dauer ist kein Kanalstandard: Sie gehört zu jedem Projekt und wird gewählt, wenn das Video erstellt wird. Die vollständige Zwölf-Felder-Einrichtung ist ein opt-in erweiterter Pfad. Wenn der Benutzer bittet, alles anzupassen, fragen Sie in Gruppen von höchstens drei, niemals alle auf einmal.

Ein Kanal ist die stabile Gruppe für eine Marke, ein Publikum oder einen Betrieb (z. B. "EN Tech" oder "PT Criador"). Er besitzt die kreativen Standardeinstellungen: Sprache, Format, Profil, Asset-Richtlinie, Engine, Autonomie und Stimme. Jedes Projekt gehört zu einem Kanal und kann jeden dieser Standardwerte überschreiben. Die Dauer ist pro Projekt, kein Kanalstandard.

Beginnen Sie nicht im selben Zug mit einem Video, es sei denn, der Benutzer bittet explizit darum. Lesen Sie references/onboarding.md für die genauen Fragen, Standardwerte und Befehle. Lesen Sie references/assets.md, bevor Sie ein Asset herunterladen oder generieren.

Schnellpfad: Der 6-Schritte-Video-Workflow

Wenn der Benutzer den einfachsten Weg von rohem Filmmaterial zu einem fertigen Video möchte, folgen Sie denselben sechs Schritten wie der Referenz-Workflow, angepasst an den RoosterEdit-Arbeitsbereich:

Bereiten Sie den Rechner vor — FFmpeg, Node.js LTS, Python 3, HyperFrames und Whisper (oder HyperFrames' Parakeet/whisper.cpp). Fragen Sie vor der Installation von irgendetwas.
Erstellen oder lösen Sie das Projekt auf — rooster new ...; rohe Medien gehen nach assets/source/.
Schreiben Sie das Styleguide — art-director schreibt style.md und löst das Profil auf. Führen Sie styleproof <slug> aus und genehmigen Sie die drei Beispiel-Frames vor der Planung.
Transkribieren und planen — transcript-analyst schreibt edit/transcript.json, edit/digest.md und edit/analysis.json; editor schreibt edit/plan.json aus der Analyse und style.md. Zeigen Sie plan.html mit Transkriptkontext und warten Sie auf Genehmigung.
Erstellen Sie die visuellen Elemente — engineer baut Letreiro, Grafiken, Listen, Zooms, B-Roll, Lower Thirds, Musik und SFX, wenn der Kanalstil dies erfordert. Ein reiner Cuts-Entwurf ist kein fertiges Video, es sei denn, der Benutzer hat explizit um einen sauberen Cut gebeten.
Zusammenbauen, überprüfen, exportieren — engineer führt build aus, um das HyperFrames- oder Remotion-Projekt aus dem genehmigten Plan zu generieren; verwenden Sie --sample 3 vor dem vollständigen Build. qa inspiziert preview/index.html und die Frames, dann rendert engineer nach renders/; export schreibt eine EDL/FCPXML-Übergabe, wenn der Benutzer DaVinci oder Premiere möchte.

Lesen Sie references/video-pipeline.md für die genauen Befehle und die Zuordnung der Ordner des Referenzvideos zu unseren. Der Rest dieser Fähigkeit ist der breitere Studio-Modus; der Schnellpfad ist der Standard für Einzelvideo-Jobs.

Betriebsprinzipien

Direkt vor dem Generieren. Eine klare Kurzbeschreibung, ein Drehbuch und eine Einstellungsliste sparen mehr Zeit als jede Prompt-Anpassung. Verbringen Sie den ersten Teil der Arbeit damit, das Video zu verstehen.
Inspizieren, nicht annehmen. Lesen Sie die Dateien, untersuchen Sie die Medien, betrachten Sie Frames und überprüfen Sie die Werkzeuge. Beaupten Sie nie, dass ein Render oder ein Asset existiert, weil der Code richtig aussieht.
Halten Sie den Schnitt editierbar. Bevorzugen Sie benannte Szenen, Variablen und lesbare Komponenten gegenüber einmaligen Skripten. Der Benutzer sollte eine Farbe, eine Zeile oder einen Clip ändern können, ohne das Projekt neu schreiben zu müssen.
Überprüfen Sie mit den Augen. Verwenden Sie die Browser-Vorschau, Screenshots oder gerenderte Standbilder, um Komposition, Tempo und Untertitel zu beurteilen. Code-Review allein reicht nicht.
Respektieren Sie die Herkunft. Zeichnen Sie auf, woher jedes Asset stammt und seine Lizenz. Ein schönes Video mit einem unlizenzierten Track ist eine Haftung.
Degradieren Sie anmutig. Die Harness hat möglicherweise keine Subagenten, keinen Browser, kein Node, kein FFmpeg oder keine TTS. Bieten Sie den besten verfügbaren Pfad an und sagen Sie, was fehlt.
Delegieren Sie die schweren Stufen. Der Hauptagent führt Regie; Stufen-Subagenten erledigen die laute Arbeit und geben eine kurze Übergabe zurück. Transkripte, Build-Logs, generierter Code und QA-Durchläufe sollten nicht durch den Hauptkontext gehen. Lesen Sie references/subagents.md.
Berichten Sie kurz. Beenden Sie jede Aufgabe mit dem Ergebnis, den Pfaden und einer nächsten Frage. Erzählen Sie nicht den gesamten Prozess und werfen Sie keine Befehle ein, es sei denn, der Benutzer fragt danach.
Vollenden Sie die kreative Schicht. Cuts allein sind kein Video. Planen Sie Overlays, B-Roll, Musik, SFX oder Untertitel, es sei denn, der Benutzer hat explizit um einen sauberen Cut gebeten.
Fragen Sie, wenn Sie unsicher sind. Wenn eine Wahl den Schnitt, das Aussehen, das Audio oder die Kosten verändert, fragen Sie beim aktuellen Schritt X/8. Raten Sie nicht stillschweigend.
Schützen Sie den Kontext. Videobearbeitung ist token-intensiv. Leiten Sie Engine-Logs in Dateien um, lesen Sie nur das Ende, verwenden Sie digest anstelle des vollständigen Transkripts und inspizieren Sie einige Schlüssel-Frames anstelle jedes Frames. Lesen Sie references/token-discipline.md.

Schritt 0 – Den Arbeitsbereich finden

Suchen Sie zuerst nach einem rooster/-Verzeichnis im aktuellen Projekt, dann verwenden Sie ROOSTER_WORKSPACE, falls gesetzt. Der Standard ist ./rooster; fragen Sie nur nach einem benutzerdefinierten Pfad, wenn der Benutzer einen möchte.

Wenn keines existiert und der Benutzer bereits darum gebeten hat, ein Video zu erstellen, ist die Erstellung des Arbeitsbereichs impliziert; führen Sie aus:

node "<skill>/scripts/rooster.mjs" init

Wenn der Benutzer die Fähigkeit gerade installiert hat oder nur erkundet, erstellen Sie sie nicht stillschweigend: Folgen Sie "Erster Lauf nach der Installation" und fragen Sie zuerst.

Der Arbeitsbereich ist der Ort, an dem Kanäle, Projekte, Profile und die Asset-Bibliothek leben. Halten Sie ihn außerhalb des Fähigkeitsverzeichnisses; die Fähigkeit ist wiederverwendbar, der Arbeitsbereich gehört zum Videoprojekt des Benutzers.

Wenn der Arbeitsbereich existiert, aber keinen Kanal hat, erstellen Sie einen, bevor Sie ein Projekt erstellen. Jedes Projekt gehört zu einem Kanal; ein default-Kanal deckt einmalige Videos ab.

Wenn der Benutzer nur eine Frage stellt oder eine Idee erkundet, beantworten Sie sie, ohne einen Arbeitsbereich zu erstellen. Eine Frage ist keine Aufforderung zum Bauen.

Schritt 1 – Fähigkeiten prüfen

Führen Sie aus:

node "<skill>/scripts/rooster.mjs" doctor --json

Dies meldet Node, npm, Python, FFmpeg, FFprobe, Git, GPU, erkannte Engines, TTS-Anbieter, yt-dlp, Whisper und die HyperFrames-CLI. Die Harness selbst weiß, ob Subagenten und ein Browser verfügbar sind; kombinieren Sie dieses Wissen mit der CLI-Ausgabe. Für Kosten lesen Sie docs/COSTS.md; rufen Sie niemals einen kostenpflichtigen Anbieter ohne explizite Erlaubnis auf.

Lesen Sie references/harness.md, wenn etwas fehlt. Die Kurzversion:

Kein Node: Verwenden Sie FFmpeg direkt für Cuts und Audio, aber Sie können HyperFrames oder Remotion nicht ausführen.
Kein FFmpeg: Sie können trotzdem planen, ein Drehbuch schreiben und ein Storyboard erstellen, aber Sie können lokal nicht prüfen oder rendern.
Kein Browser: Rendern Sie Standbilder oder Frames und inspizieren Sie sie als Bilder.
Keine TTS: Verwenden Sie die Stimme des Benutzers, nur Untertitel oder eine lokale Stimme; fragen Sie, bevor Sie einen Cloud-TTS-API-Schlüssel konfigurieren.

Schritt 2 – Den Kanal und den Stil einrichten

Bevor Sie ein Projekt erstellen, fragen Sie nach dem Kanal: "Welchen Kanal verwendet dieses Video?" Wenn es keinen gibt, erstellen Sie einen mit channel new. Wenn der Benutzer nur eine Kurzbeschreibung hat, erstellen Sie einen default-Kanal.

Jeder Kanal hat einen Stil. Wenn der Stil noch nicht geschrieben wurde, schreiben Sie style.md mit dem Standardprofil des Kanals. Führen Sie styleproof <slug> aus, um sicherzustellen, dass er konsistent und rendert ist. Zeigen Sie die drei Bestätigungs-Frames und fragen Sie nach Genehmigung.

Schritt 3 – Ein Projekt erstellen

Führen Sie rooster new <titel> aus und geben Sie die Dauer, das Format und alle Überschreibungen für diesen Kanal an. Die Quelldateien gehen nach assets/source/. Ordnen Sie sie in Ordner, wenn es mehrere gibt. Nennen Sie den primären Clip main.*, wenn die Quelle kein Offline-Schnitt ist.

Wenn die Quelle aus einer URL stammt, verwenden Sie yt-dlp (falls verfügbar), um sie herunterzuladen. Wenn Sie eine Lizenzprüfung benötigen, fragen Sie den Benutzer nach einem benutzerdefinierten Asset, bevor Sie aus dem Web herunterladen.

Schritt 4 – Transkribieren und analysieren

Der transcript-analyst nimmt die Mediendateien auf und erzeugt edit/transcript.json, edit/digest.md und edit/analysis.json. Überprüfen Sie die Analyse auf Themen, Beats und Kennzeichen. Fragen Sie den Benutzer nach Präzisierungen, bevor Sie fortfahren.

Schritt 5 – Eine Bearbeitungsliste schreiben

Der editor schreibt edit/plan.json aus der Analyse und style.md. Zeigen Sie plan.html mit Transkriptkontext und warten Sie auf Genehmigung. Fragen Sie nach einer bestimmten Dauer, wenn die Analyse einen Bereich vorschlägt.

Schritt 6 – Visuelle Elemente erstellen

Der engineer baut Letreiro, Grafiken, Listen, Zooms, B-Roll, Lower Thirds, Musik und SFX, wenn der Kanalstil dies erfordert. Ein reiner Cuts-Entwurf ist kein fertiges Video, es sei denn, der Benutzer hat explizit um einen sauberen Cut gebeten.

Schritt 7 – Zusammenbauen und in der Vorschau anzeigen

Der engineer führt build aus, um das HyperFrames- oder Remotion-Projekt zu generieren. Verwenden Sie --sample 3, um eine Stichprobe der Frames zu rendern, bevor Sie den vollständigen Build ausführen. qa inspiziert preview/index.html und die Frames. Zeigen Sie dem Benutzer die Vorschau und fragen Sie nach Änderungen.

Schritt 8 – Rendern und ausliefern

Der engineer rendert das endgültige Video nach renders/. export schreibt eine EDL/FCPXML-Übergabe, wenn der Benutzer DaVinci oder Premiere möchte. Zeigen Sie dem Benutzer den endgültigen Pfad und eine kurze Zusammenfassung.

Referenzen

references/assets.md – Asset-Verwaltung und Lizenzierung
references/harness.md – Harness-spezifische Konfiguration
references/onboarding.md – Onboarding-Fragen und Standardwerte
references/subagents.md – Subagenten-Rollen und Übergaben
references/token-discipline.md – Kontextverwaltung
references/video-pipeline.md – Video-Pipeline-Befehle
docs/COSTS.md – Kostenübersicht und Limits

Fehlerbehebung

Wenn doctor einen fehlenden Befehl meldet, fragen Sie den Benutzer, ob er ihn installieren möchte. Wenn der Build fehlschlägt, überprüfen Sie die Logs und passen Sie den Plan oder den Stil an. Wenn die Vorschau leer ist, überprüfen Sie die Asset-Pfade und die Engine-Konfiguration.

WesleyQDev/rooster-edit

Was ist rooster-edit?

In Ihrer bevorzugten KI fragen

Dokumentation