worldwonderer/drama-skills

Kurzserien-Routing

Dies ist ein leichtgewichtiges Projekt-Routing; innerhalb dieses Skills werden keine Geschichten, Asset-Prompts, Kameraperspektiven, Video-Prompts oder finale Prüf-Ergebnisse verfasst.

Für den Autor lesbare Inhalte folgen der short-drama.json#/language (Status, Abweichungen, Auswahl, nächste Schritte zählen dazu); die an Bild-/Video-Generatoren gesendeten Prompt-Texte folgen #/format/prompt_language (Standard en). Beides sind separate Felder, verwenden Sie nicht das eine, um das andere abzuleiten – status gibt beide Werte gleichzeitig aus. Vollständige Regeln finden Sie im Ausgabe-Sprachvertrag von contract-and-ownership.md.

Startpunkt jeder Anfrage

1. Verwenden Sie den vom Benutzer angegebenen Pfad oder suchen Sie vom aktuellen Verzeichnis aus aufwärts nach der nächsten short-drama.json.
2. Lesen Sie vom Installationsverzeichnis dieses Skills die anderen Skills derselben Suite und die suite-manifest.json; fehlende Skills oder gemischte Versionen führen zu einem Stopp.
3. Lesen Sie nur die Zusammenfassungen von short-drama.json und .short-drama/state.json; laden Sie nicht alle Dateien auf einmal.
4. Führen Sie vor status oder einem Schreibvorgang eine Transaktionswiederherstellung durch. Bei externen Bearbeitungskonflikten behalten Sie die Originaldatei und bieten Sie die Optionen adopt, restore und merge an – kein stilles Überschreiben.
5. Routen Sie entsprechend der aktuellen Aufgabe des Autors; erzwingen Sie nicht den gesamten Workflow.

Einstieg, Checkpoints, Überarbeitungen und Lieferung finden Sie in creator-workflow.md. Vor jedem Einstieg führen Sie runtime-preflight.md aus, zur einheitlichen Überprüfung der Installation, Wiederherstellung von Transaktionen und Lesen des Projektstatus. Bei Fragen zu Eigentumsrechten, Datei-Markierung stale, Datenschutz oder Wiederherstellung lesen Sie contract-and-ownership.md. Bei Unklarheiten lesen Sie routing-examples.md. Lesen Sie knowhow-index.md nur, wenn Sie eine Regel-ID dem zuständigen Skill zuordnen müssen; das Routing ist nur für die Zuweisung zuständig, nicht für die kreative Bewertung. Was ein Referenzbild entscheiden kann und der Vertrag für erste/letzte Frames finden Sie in reference-roles.md; was das Publikum zu diesem Zeitpunkt wissen kann, finden Sie in audience-reveal.md; die Beziehung von Nachdrehs, Alternativversionen zum Master finden Sie in pickup-and-alternate.md. Ausführungsübersetzungen für verschiedene Produktionsformen finden Sie in production-form-profiles.md. Wenn vor dem offiziellen Storyboard eine einheitliche visuelle Sprache mit Figuren, Orten und repräsentativen Hochdruck-Frames erstellt werden soll, lesen Sie look-development.md.

Intent-Routing

Autorenabsicht	Route
Idee entwickeln, Story-Versprechen, Serien- und Episodenkarte	$short-drama-develop
Roman/langes Material importieren und nachvollziehbare Episoden mit Asset-Kandidatenvorschau analysieren	$short-drama-novel-analyze → $short-drama-develop → Adaption/Episoden akzeptieren → $short-drama-write → Drehbuch akzeptieren → $short-drama-assets
Beurteilen, ob ein langer Text adaptiert werden sollte; zuerst eine Kurzbewertung lesen	$short-drama-novel-analyze
Episodenvertrag, Kausal-Beat, Drehbuch schreiben/überarbeiten	$short-drama-write
Figuren/Outfits, Orte/Ansichten, Requisiten/Status extrahieren	$short-drama-assets
Bild-Prompts für Figuren/Orte/Requisiten/lokale Änderungen schreiben	$short-drama-image-prompts
Textabdeckung, Kamera oder eingefrorene Schlüsselbilder erstellen	$short-drama-storyboard
Video-Prompts für Aktion/Performance/Kameraführung/Ton schreiben	$short-drama-video-prompts
Stilrichtung, Produktionsform oder visuelle Richtung festlegen	$short-drama selbst: Anhand von production-form-profiles.md eine Formkarte auswählen, Kandidaten erstellen und den Autor zur Annahme auffordern, dann auf creator_authority anheben. Assets, Bild-Prompts, Storyboard und Video-Prompts erfordern alle eine festgelegte Form und wählen diese nicht selbst; daher muss dieser Schritt hier erfolgen
Look Development / Stil-Frames durchführen	$short-drama zuerst beobachtbare visuelle Richtung klären und akzeptieren → $short-drama-image-prompts schreibt lookdev_frame-Textspezifikation; keine Bilder generieren, und Stilreferenzen nicht Identität, Geografie oder Handlungsstatus überschreiben lassen
Projekt mit autorisierten Produktionsbeobachtungen kalibrieren	$short-drama-review bindet genaue Version und diagnostiziert → entsprechender Owner führt gezielte Überarbeitung mit preserve_set durch → erneute Akzeptanz und frische Re-Review; ohne Autorisierte Beobachtung nur Textrisiken melden
Validierung, Prüfung oder Überarbeitungsanfrage	$short-drama-review
Nur auf Vorlagencharakter, KI-Geruch prüfen oder diagnostizieren	frische $short-drama-review, nur Finding mit Beweisen senden
KI-Geruch entfernen, polieren oder gezielt überarbeiten	$short-drama-write, Autorenstimme bewahren und semantische Unterschiede anzeigen
Erst prüfen, dann ändern	fresh review → write owner gezielte Überarbeitung → fresh re-review
Dashboard, Kurzserien-Arbeitsbereich oder Verwaltung von Inhalten öffnen	$short-drama dashboard: führe untenstehenden Vertrag für lokales Dashboard aus

Die explizite Absicht des Autors hat Vorrang vor dem nominellen „nächsten Checkpoint“. Look Development ist ein optionaler projektspezifischer Zweig, kein allgemeines Voraussetzung; Nach der Annahme von C2-Assets sind Bild-Prompts und Storyboard parallele Zweige; wenn der Autor nur einen Zweig bearbeiten möchte, wird nicht auf den anderen gewartet.

Wenn der aktuelle Kontext an der Erstellung der Zieldatei beteiligt war, muss der Prüfungs-Routing zuerst einen frischen Reviewer-Agent/Context starten, der nur das Ziel, die akzeptierten Einschränkungen und die Prüfliste erhält; wenn die Laufzeitumgebung keinen frischen Agent unterstützt, erfolgt transparentes Degradieren zu PROVISIONAL-Selbstprüfung; ein bloßer Skill-Namenswechsel darf nicht als unabhängige Prüfung gelten.

„Sieht aus wie eine Vorlage/von KI geschrieben“ ist eine Diagnoseanfrage; „Ändere es“ ist eine Owner-Überarbeitungsanfrage. Der Write-Owner darf sich nicht selbst diagnostizieren und dann eine Schlussfolgerung ausstellen; der Reviewer darf nicht eigenmächtig den Text ändern. Bei kombinierten Anfragen wird zuerst die Zielversion fixiert, ein frischer Reviewer lokalisiert Beweise und Verluste, dann übergibt er an den Write-Owner, der nur den akzeptierten Bereich ändert; zuletzt führt ein anderer frischer Reviewer eine Re-Review des neuen Hashs durch. Jeder Schritt, der keinen unabhängigen Kontext herstellen kann, bleibt PROVISIONAL.

Initialisierung

Wenn kein Projekt existiert und der Benutzer eines initialisieren möchte:

1. Nur Standardwerte des umkehrbaren Formats bestätigen oder sinnvoll ableiten: Titel, Sprache, Prompt-Sprache, Seitenverhältnis, Pfad; Anzahl der Episoden/Laufzeit bei Unbekanntheit leer lassen. Sprache standardmäßig auf die aktuell vom Autor verwendete Sprache setzen, Prompt-Sprache standardmäßig en; wenn der Autor explizit fordert, dass die Prompt-Sprache ebenfalls die Projektsprache sein soll, der Autorensprache folgen und nicht selbst über Qualitätskonsequenzen urteilen.
2. Projektvorlage kopieren, vorhandene Autorendateien nicht überschreiben.
3. Leere Phasenverzeichnisse und nicht-öffentliche Eingabegrenzen anlegen.
4. In short-drama.json#/creator_authority leere Autorenbeschränkungen, visuelle Richtung und Produktionskonfiguration anlegen; sie initial auf unset setzen; Assets und deren Nachfolger erfordern eine festgelegte Form – daher nach der Initialisierung den Autor informieren: Die Festlegung der Produktionsform ist der nützlichste nächste Schritt; der Einstiegspunkt ist dieser Skill (siehe Intent-Routing-Tabelle), nicht in einem Sub-Skill; die tatsächliche Auswahl in die Entscheidungsaufzeichnung gemäß creator-decision.example.jsonl schreiben.
5. Suite-Version, Vertragsversion und fünf voneinander unabhängige leere Zustände aufzeichnen.
6. Projektpfad und nützlichste Autorenaktion mitteilen.

Die Initialisierung generiert keine Story-Engine, Drehbücher oder Asset-Spezifikationen.

Wenn während der Entwicklungsphase eine 项目开发/director-brief.md eingereicht wird, dem Autor zuerst die semantische Differenz zur aktuellen visual_direction / production_profile anzeigen; erst nach expliziter Annahme routet der Skill die entsprechende Auswahl in short-drama.json#/creator_authority. Die Kandidatendatei selbst hat keine Creator Authority.

Lokales Dashboard

Wenn der Benutzer $short-drama dashboard aufruft, wird nicht an einen Sub-Skill weitergeleitet, sondern direkt das im Skill enthaltene lokale Kurzserien-Dashboard gestartet:

1. Zuerst gemäß runtime-preflight.md die Suite prüfen und unvollständige Transaktionen wiederherstellen.

2. Befindet sich das Arbeitsverzeichnis innerhalb eines Projekts, wird das Projektstammverzeichnis als workspace verwendet; andernfalls das vom Benutzer explizit angegebene Container-Verzeichnis; falls nicht angegeben, das aktuelle Verzeichnis verwenden. Nicht außerhalb des workspace scannen.

3. Vom Installationsverzeichnis dieses Skills aus ausführen:

   python3 <short-drama-skill-dir>/scripts/dashboard_server.py --workspace <workspace> --port 0 --open
   

4. Den Prozess laufen lassen; die vollständige Loopback-Adresse (einschließlich des Sitzungsfragments dieser Instanz) und die Stopp-Methode melden, die das Skript ausgibt. Wenn der Browser nicht automatisch geöffnet wird, den Dienst laufen lassen und den Benutzer auffordern, die vollständige Adresse zu öffnen.

Das Dashboard hat nur eine Bearbeitungsseite: links ein nach Projekten und Episoden gegliedertes, verständliches Inhaltsverzeichnis, rechts der dauerhafte Text; beim Öffnen eines Projekts wird automatisch das Drehbuch geladen; Inhaltswechsel ersetzen nur den Text, es werden keine neuen Seiten oder Overlays geöffnet. Aufgaben und Export erscheinen nur als kurze Hinweise unterhalb des Textes. Die Oberfläche zeigt keinen Dateibaum, echte Pfade, strukturierte Formate, Lebenszyklus oder technische Details. Markdown für Manuskripte lesen und bearbeiten; strukturierte Daten in Karten umwandeln; Bilder und Videos nur als Vorschau. short-drama.json, .short-drama/**, Autorenentscheidungen, Prüfbelege und Exportschecks werden vom System verwaltet und sind nicht Teil der Autorennavigation. Speichern bedeutet nur die Bearbeitung zu sichern, nicht die Annahme einer Version durch den Autor zu ersetzen. Es verbindet sich nicht mit externen Datenquellen, ruft keine Medien-Generierungs-APIs auf und injiziert keine Schlüssel in den Browser. Jede Instanz generiert einen eigenen Sitzungsbeleg und API-Pfad; der Browser tauscht das Adressfragment gegen eine HttpOnly-Lokalsitzung ein; die Projekt-API akzeptiert nur diese Sitzung. Konkrete Parameter finden Sie in lifecycle-commands.md.

Deterministische Tools

Aufruf von scripts/project_tool.py aus dem Installationsverzeichnis dieses Skills, unabhängig vom aktuellen Arbeitsverzeichnis:

Befehl	Verwendung
init	Minimales Projekt initialisieren
status	Lebenszyklus- und Wiederherstellungszusammenfassung lesen
recover	Alle oder bestimmte Transaktionen wiederherstellen
publish	candidate über Write-Ahead-Log veröffentlichen, ohne Annahme- oder Prüfschlussfolgerung
accept	Mit Autorenentscheidung das genaue candidate-Ziel akzeptieren
review	Mit unabhängiger Prüfschlussfolgerung den Validierungs- und Prüfstatus aktualisieren
package	Nach erneuter Überprüfung der fünf Achsen, Abhängigkeiten und Belege ein textbasiertes Lieferpaket erstellen
verify	Mit dem Paket-eigenen Prüfsummen-Selbsttest testen und nicht registrierte neue Dateien melden

Nur wenn diese Befehle tatsächlich aufgerufen werden, eine Diagnose fehlschlägt oder das Format der Aufzeichnung überprüft werden muss, lesen Sie die vollständigen Aufrufbeispiele, Write-Ahead-Logs, Annahme-, Prüf-, Downstream-Verfall-Effekte und Paketierungs-Beschränkungen in lifecycle-commands.md.

Status und Nächste Schritte

In der Autorensprache angeben:

• Bereits vorhandene und als accepted gekennzeichnete Quellen;
• Inhalte mit Status provisional, stale, blocked oder die auf Autorenannahme warten;
• Derzeit parallel betretbare Zweige;
• Die kleinste Aktion, die das vom Benutzer gewünschte Ergebnis vorantreibt.

Sofern der Benutzer nicht explizit eine Diagnose anfordert, werden hash, Transaktions-IDs, interne Datenstrukturen oder Rohstatusinhalte nicht ausgegeben. Die fünf Status sind voneinander unabhängig: Build, Validierung, Autorenannahme, unabhängige Prüfung und Lieferkontrolle; ein einziges accepted darf nicht alle repräsentieren.

Wiederherstellung und Überarbeitung

Stellen Sie die früheste unvollständige Operation innerhalb des vom Benutzer angefragten Bereichs wieder her, nicht die früheste Phase des gesamten Projekts. Bevor Sie bereits bestätigte Inhalte ändern:

1. Den für die Änderung verantwortlichen Skill identifizieren;
2. Die vorgeschlagenen semantischen Änderungen darlegen;
3. Die genaue Liste der betroffenen Downstream-Elemente auflisten;
4. Gegebenenfalls die Autorenannahme einholen;
5. Die Änderung an den Verantwortlichen übergeben und den neuen hash erneut prüfen.

Unvollständige Transaktionen ohne COMMIT werden auf die letzte gespeicherte Version zurückgesetzt; unvollständige Transaktionen mit COMMIT werden bis zum candidate fortgesetzt und die Status ergänzt. Wiederherstellung muss zuerst lesen, dann schreiben und wiederholbar sein; externe Änderungen, deren Quelle nicht bestätigt werden kann, müssen als conflict markiert werden, nicht überschrieben werden.

Lieferung

Zunächst in den frischen Prüfkontext von $short-drama-review routen, validieren, dann verpacken, sobald die Lieferkontrolle bereit ist. Nur als accepted gekennzeichnete Drehbücher, Inventarlisten, Prompts, Prüfprotokolle, Autorennotizen und Prüfsummen sind enthalten. Binäre Medien, nicht-öffentliche Eingaben, Maschinenstatus, absolute Pfade, Berechtigungsnachweise, nicht-öffentliche Quellenmaterialien und nicht genehmigte Entwürfe sind ausgeschlossen.

Grenzen

• Verwenden Sie nur die Textinferenz des aktuellen Agenten; rufen Sie keine Medien-Generierungs- oder Dienst-APIs auf.
• Suchen Sie zur Laufzeit nicht externe oder nicht-öffentliche Produktionsquellen ab.
• Erheben Sie keine anderswo gesehenen Beispiele zu kreativen Gesetzen.
• Der Verantwortliche darf seine eigenen Ergebnisse nicht prüfen.
• Semantische Konflikte werden nicht stillschweigend behoben.