100x-Persona

Was macht 100x-Persona?

Ein-Satz-Positionierung

Eingabe eines Skript-/Textabschnitts als reinem Text, Ausgabe von "Wer spricht" (Persona) + "Wo wird gesprochen" (Szene, unabhängige Entität, kein Textfeld der Persona) + wie beide mit dem Originalsatz des Skripts verknüpft sind – alle drei können wörtlich auf den Originaltext zurückverweisen. Gehört zur 100x-Architektur, L2-Ebene der kreativen Generierung, entspricht Schritt "3.1 Persona × Szene".

Wann wird das Skill ausgelöst?

Der Benutzer sagt:

• "Gib diesem Skript eine Persona" / "Wer soll dieses Skript liefern?" / "Wie legen wir die Persona fest?"
• "Wie wird die Szene festgelegt?" / "Welche Szene passt zu dieser Werbung?" / "Wo soll dieses Skript gedreht werden?"
• "who should deliver this script" / "what persona fits this product"
• "what setting fits this ad" / "where should this be filmed"
• Oder übergibt direkt einen Skripttext mit der Anforderung "Persona und Szene zuweisen" / "assign a character and setting"

Eingabe

Minimaleingabe (Kategorie A, erforderlich): source_script – vollständiger Skript-/Textabschnitt als reiner Text. Dieses Skill akzeptiert keine Videodateien, nur Text.

Optionale Upstream-Ausgabe (Kategorie C, stillschweigend übersprungen, blockiert nicht, erfordert nicht, dass der Benutzer zuerst andere Skills ausführt): 100x-segment-Ausgabe segments[] (falls vorhanden, kann pairings[].segment_ref zurückgefüllt werden; fehlt dieses Feld, wird es weggelassen und die Positionierung erfolgt allein über script_span_quote).

Ausgabe

Die Struktur ist in schema.json definiert: PersonaSceneBundle = source_script (Originaltext zur Überprüfung) + personas (Persona-Map, unabhängige Entitäten) + scenes (Szenen-Map, unabhängige Entitäten, gleichrangig mit personas, keine Textfelder der Persona) + pairings (Zuordnungstabelle: Persona × Szene × Originalsatz im Skript) + meta. Optional eine menschenlesbare Markdown-Zusammenfassung (Persona-Liste / Szenen-Liste / Pairing-Vergleichstabelle).

Kernbeschränkungen (4 Axiome, siehe axioms.md)

1. Szenen sind unabhängige Entitäten, die über IDs referenziert werden, keine eingebetteten Textfelder einer Persona – personas/scenes sind zwei gleichrangige Maps, pairings[].persona_ref/pairings[].scene_ref müssen tatsächlich in den entsprechenden Maps existieren (Referenzintegrität).
2. Autoritäts-/Zielgruppen-Begründungen müssen wörtliche Teilstrings des Originaltexts sein – authority_evidence_quote / audience_pain_quote / script_span_quote müssen alle wörtlich im source_script auffindbar sein. Bekannte Einschränkung (kein versteckter Fehler): Ein wörtlicher Teilstring beweist nur „diesen Satz gibt es im Originaltext“, aber nicht, dass die semantische Richtung des Satzes im Persona-Feld nicht umgekehrt verwendet wird – z. B. das Extrahieren eines selbstzweifelnden Satzes („Wenn du mir nicht glaubst“) als Autoritätsanker ist ebenfalls ein gültiger Teilstring. Der aktuelle Mechanismus enthält eine begrenzte, geschlossene Liste von Selbstbezüglichkeitsphrasen (Treffer erfordern eine Offenlegung durch Menschen, siehe Axiom 2 in axioms.md), aber Ironie/Zitat-Widerlegungsrahmen-Umkehrungen werden weiterhin nicht erkannt – dies ist die Grenze der Zeichenkettenübereinstimmung, siehe Abschnitt "Mechanismus-Grenzen und Abhilfemaßnahmen" unter Axiom 2 in axioms.md.
3. Szenen müssen auf mikroskopische Koordinaten präzisiert werden – keine allgemeinen Ortsangaben (geschlossene Liste von Verallgemeinerungen wird abgelehnt) + mindestens 2 konkrete Requisiten.
4. Personas und Szenen dürfen keine Waisen sein – jede erstellte Entität muss von mindestens einem Pairing referenziert werden; keine „Matrix-für-vollständigen-Eindruck“-Anhäufung.

Dreiphasen-Workflow

Siehe workflow.md: Phase 1 Persona-Rückentwicklung (Scannen des Skripts nach Autoritäts-/Schmerzsignalen, wörtliches Extrahieren von Evidenzsätzen) → Phase 2 Szenenmodellierung (jeder Szenenhinweis als unabhängige Entität modellieren + mit Persona/Originalsatz verknüpfen + Waisenprüfung) → Phase 3 Ausgabe (JSON zusammenstellen, alle Axiome 1–4 bestehen).

Garantie für unabhängigen Aufruf

Fehlt Kategorie A (source_script) → festgelegter Ablehnungstext zur Nachfrage, keine Vermutung, keine Videodateien als Ersatz. Fehlt Kategorie C (Upstream-100x-segment-Ausgabe) → stillschweigend übersprungen, der Benutzer wird nie aufgefordert, zuerst andere Skills auszuführen.

Verbotene Wörter

Lass mich / ich hoffe / vielleicht / wahrscheinlich / möglicherweise / eventuell / lassen Sie uns; KI-Kundendienst-Ton (as an AI / I'd be happy to / feel free to); Keine Qualifikationen/Zertifizierungen/Testimonials/Wirkungsdaten erfinden, die nicht im Originalskript stehen; Keine kundenspezifischen Produktkategorie-Wörterbücher fest codieren; micro_coordinate verwendet keine Verallgemeinerungen aus der geschlossenen Liste (siehe Axiom 3 in axioms.md: irgendwo / irgendein / irgendein Ort / TBD / somewhere / anywhere usw.).

Routing (empfohlen, nicht zwingend)

• Vorhandenes segmentiertes Skript, Persona/Szene pro Segment statt für das Ganze zuweisen → Segmentierungs-Skill (falls vorhanden, kann segment_ref zurückgefüllt werden)
• Persona-/Szenenbeschreibungen in AI-Videogenerierungs-Prompts umwandeln → Prompt-Assemblierungs-Skill (falls vorhanden)
• Zuerst Suchbegriffe für Referenzbilder generieren, dann Persona/Szene festlegen → Suchbegriff-Skill (falls vorhanden)
• Zurück zum Haupteingang für erneute Triage → 100x-Haupteingang (falls vorhanden)

Alle oben genannten Punkte sind „nach der Ausgabe bedarfsorientierte Empfehlungen“, keine Voraussetzungen; wenn das entsprechende Skill noch nicht erstellt ist, beeinträchtigt dies nicht die unabhängige Arbeit dieses Skills.

Werksselbsttest

Führen Sie node scripts/validate.js --selftest zur Überprüfung aus. Die in schema.json deklarierten strukturellen Einschränkungen (required/additionalProperties/enum/pattern/minItems usw.) werden von ajv (echter JSON-Schema-Draft-07-Validator, als devDependency in package.json deklariert, zuerst npm install ausführen) in scripts/validate.js tatsächlich ausgeführt, nicht durch manuell aufgezählte Felder. Axiom 1 (Referenzintegrität), Axiom 2 (Evidenz-Teilstrings) und Axiom 4 (keine Waisen) sind drei Arten von objekt-/feldübergreifenden Aggregationsregeln, die in Vanilla-JSON-Schema strukturell nicht ausdrückbar sind – diese drei werden durch manuellen Code in scripts/validate.js ergänzt. Darüber hinaus enthält es checkAuthorityHedgeRisk (teilweise Abhilfe für Axiom 2 – Treffer einer geschlossenen Liste von Selbstbezüglichkeitsphrasen erfordern eine Offenlegung in meta.warnings, andernfalls FAIL). Dies ist nur eine Abhilfe, keine vollständige Lösung – semantische Umkehrungen von Evidenzsätzen durch Ironie/Zitat-Widerlegungsrahmen werden weiterhin nicht erkannt; --selftest Punkt 10 enthält bewusst einen aktuellen Regressionstestfall, der „durchgelassen wird“, um diese Grenze zu demonstrieren, nicht um zu behaupten, sie sei bereits geschlossen:

npm install                                                   # Beim ersten Mal ajv installieren
node scripts/validate.js <bundle.json> [bundle2.json ...]   # Ausgabe validieren
node scripts/validate.js --selftest                          # Integrierte Regressionstests ausführen

Quellen

Dieses Skill basiert auf einer unabhängigen Erstellung unter Berücksichtigung von Kriterienstilreferenzen und Feldstrukturspezifikationen. Die genauen Herkunftsnachweise für jedes Kriterium, jedes Felddesign und jede Designentscheidung finden Sie in sources.md.