VoxFlowStudio/skills

VoxFlow Skill — Karte

Verwandle einen Text in eine Reihe von markanten, konsistenten visuellen Kartenbildern. Jede Karte ist eine eigene Webseite; alle Karten teilen sich ein Größen- und Stilsystem; sie werden mit Playwright gerendert und als PNGs exportiert.

Dies ist der statische Kartenbild-Skill. Für andere Oberflächen wechsle zu:

• Artikel → vertikales KartenVIDEO (Slice) — 1080×1920 Reel, 13 Themen → voxflow:slice
• Kurzvideos / KI-Clips / Wissenskarten-Videos → voxflow:video
• Multi-Sprecher-Podcasts → voxflow:podcast
• TTS / Stimmen / Installation / Authentifizierung / Kontingent → voxflow:hub

Schritt 0 · Anmelde-Gate (erforderlich, zuerst durchführen)

Dieser Skill ist Teil von VoxFlow und erfordert ein angemeldetes Konto. Überprüfe vor allem anderen – vor Fragen, Recherche oder Design – die Anmeldung:

voxflow status

• Zeigt das Konto + verbleibendes Kontingent an → angemeldet, fahre mit dem Workflow fort.
• Fehler / Zeigt "nicht angemeldet" → STOPP. Führe voxflow login aus (öffnet den Browser – Google oder E-Mail-OTP), warte, bis der Benutzer fertig ist, und führe dann erneut voxflow status aus. Sammle keine Parameter und generiere keine Karten, bis die Anmeldung erfolgreich ist.
• voxflow: Befehl nicht gefunden → npm install -g voxflow zuerst, dann voxflow login.

Überspringe dieses Gate niemals, generiere niemals Karten für einen nicht authentifizierten Benutzer und erfinde niemals ein Token. Das zwischengespeicherte Token befindet sich unter ~/.config/voxflow/token.json; für CI wird VOXFLOW_TOKEN verwendet.

Übersicht

Erstelle einen Satz von teilbaren visuellen Karten aus Quelltext. Behandle jede Karte als eigene Webseite, halte alle Karten in der gleichen Größe und im gleichen Stilsystem, rendere sie mit Playwright, exportiere Bilder und iteriere über schwache Karten.

Geschmacksbasislinie

references/taste.md ist eine Checkliste mit Einschränkungen, die jede Kartenform, jedes Thema, Layout und jede Designsprache begrenzt. Behandle sie als eine Untergrenze, die zur Designzeit zuschlägt, nicht als ein Eröffnungsritual, das zu Beginn des Workflows rezitiert werden muss.

• Lade references/taste.md nur zu zwei Zeitpunkten, nicht zu Beginn des Workflows:
  • Bei der Auswahl des Themen-Presets und der Designsprache (Workflow-Schritt 4), damit die Wahl nicht gegen harte Einschränkungen verstößt.
  • Während der QA-Bewertung (Workflow-Schritt 7), als eine explizite Überprüfungsdimension.
• Andere Schritte (Parameterefassung, Recherche, Textplanung) müssen references/taste.md nicht erneut laden; die Einschränkungen fließen durch das bereits gewählte Preset und die Sprache in sie ein.
• Das Kernziel ist es, offensichtliche KI-generierte Designspuren zu entfernen.
• Harte Einschränkungen umfassen: keine Standard-Inter-Schriftart, kein reines Schwarz, kein standardmäßiger zentrierter Hero, keine Drei-gleiche-Karten-Komposition, keine generische KI-Nachrichtenstimme und keine gefälschten Daten.
• Geschmack bedeutet nicht Leere. Verwende die Dichteregeln in references/taste.md, damit reale Kartensätze mindestens eine nützliche Informationskarte enthalten, es sei denn, der Benutzer wünscht ausdrücklich ein Nur-Poster- oder Nur-Kino-Set.
• Wenn ein Themen-Preset oder eine Designsprache mit references/taste.md in Konflikt steht, gewinnt die Geschmacksbasislinie, es sei denn, der Benutzer wünscht ausdrücklich den verbotenen Stil.

Eingaben

Sammle oder leite ab:

• content: Quelltext, Gliederung, Notizen, URL, Thema oder Kurzbeschreibung.
• ratio: Standardmäßig 1:1, es sei denn, der Benutzer wünscht 3:4, 9:16 oder ein anderes Verhältnis.
• count: Standardmäßig eine automatische Anzahl basierend auf der Inhaltsdichte; akzeptiere explizite Mengen.
• style: Akzeptiere explizite Stilrichtungen, Markeneinschränkungen, Zielgruppe, Stimmung und Plattform.
• content-language: zh / en / gemischt. Leite aus der Quelle ab; frage nur, wenn es mehrdeutig ist und die Schriftartauswahl beeinflussen würde. Steuert die Sprachüberschreibung in references/fonts.md.
• output: Wähle einen klaren lokalen Ordner wie cards/<slug>/, es sei denn, der Benutzer gibt einen an.

Wenn wichtige Fakten aktuell oder umstritten sein könnten, recherchiere oder überprüfe sie vor der Planung. Halte Quellenangaben für den Benutzer verfügbar, wenn die Recherche den Inhalt beeinflusst. Siehe den Abschnitt Forschung & Faktenbestätigung für wann dies zu einem vollständigen Deep-Research-Durchlauf wird, anstatt zu einer schnellen Überprüfung.

Forschung & Faktenbestätigung

Füge dies zwischen der Parameterefassung und der Designarbeit ein, aber nur, wenn die Eingabe nicht allein als Inhalt der Karten stehen kann.

• Löse Deep Research aus, wenn content eines der folgenden ist: eine Themenphrase, eine einzelne Satz-Kurzbeschreibung, eine URL, deren Inhalt noch nicht gelesen wurde, eine Tweet-lange Idee, eine Frage oder eine Anfrage "erkläre X / behandle X / mache Karten zu X".
• Überspringe Deep Research, wenn content bereits ein in sich geschlossener Artikel, ein Transkript, ein Satz strukturierter Notizen, eine vollständig entworfene Gliederung oder ein Text ist, aus dem der Benutzer eindeutig Karten aus und nicht über bauen möchte.
• Wenn ausgelöst, erstelle eine Faktengliederung vor jeder visuellen Planung:
  • Kernbehauptung oder These.
  • 3-7 unterstützende Punkte mit konkreten Zahlen, Namen, Daten oder Mechanismen.
  • Quellen für jede nicht triviale Tatsache, mit URLs oder Dokumentenverweisen, die in sources.md landen.
  • Offene Fragen oder strittige Punkte, die der Benutzer klären sollte.
• Präsentiere die Faktengliederung dem Benutzer und bitte um Bestätigung, Ergänzungen oder Korrekturen, bevor du zur Themen-/Designsprachauswahl übergehst. Dies ist eine separate Bestätigung von der späteren Konzept-/visuellen Bestätigung.
• Das Ergebnis dieses Schrittes sind die "Knochen" – Behauptungen und Beweise – nicht fertiger Kartentext. Haken, Erklärungen und Takeaways auf Kartenebene werden später während der Inhaltsstrukturierung (Schritt 5) auf Basis der bestätigten Knochen geschrieben.
• Zeichne die hier gesammelten Quellen sofort nach Bestätigung der Faktengliederung in sources.md im Ausgabeordner auf.

Auslöserbeispiele

Führe Deep Research aus, wenn:

• "Eine Reihe von Karten über das MCP-Protokoll erstellen" — bloßes Thema, kein Inhalt.
• "Diesen Artikel in Karten umwandeln: https://example.com/beitrag" — URL, deren Inhalt in dieser Unterhaltung noch nicht gelesen wurde.
• "Eine Reihe von Karten über RAG-Optimierungstipps erstellen, mit Fokus auf Chunking" — Thema + Blickwinkel, keine konkreten Punkte oder Daten.
• "Für welche Szenarien eignen sich Cloudflare Durable Objects? Erstelle ein paar Karten" — Frage oder "erkläre X / behandle X"-Rahmen.
• Ein einzelner Tweet, eine Schlagzeile oder ein einzeiliger Auftrag, der ein Subjekt nennt, aber keine Beweise liefert.

Überspringe Deep Research, wenn:

• Der Benutzer einen vollständigen Artikel, Blogbeitrag, ein Transkript oder einen Interviewtext einfügt (alles ab etwa 500+ Wörtern in sich geschlossenen Quellinhalts).
• Der Benutzer strukturierte Notizen, Besprechungsprotokolle, Kursnotizen oder eine fertige Gliederung bereitstellt, in der Titel und 2-4 Punkte jeder Karte bereits aufgelistet sind.
• Der Benutzer seinen eigenen fertigen Text bereitstellt und nur um eine visuelle Behandlung bittet ("Diesen Absatz als Karte anordnen", "Diesen Text verschönern").
• Der Benutzer explizit sagt: "Nicht recherchieren / Basis dieses Texts verwenden / Nicht erweitern", unabhängig von der Eingabelänge.

Grenzfälle

• Kurzer Auftrag + Ambitionskonflikt – z. B. 200-Wörter-Zusammenfassung plus "zu 7 Karten ausbauen". Der Auftrag ist zu dünn, um die Zielanzahl zu füllen, also löse Forschung aus und zeige auf, dass dem Auftrag Beweise fehlen, bevor du erweiterst.
• Artikel + "Füge noch die neuesten Daten / ein paar Beispiele hinzu" — führe nur einen gezielten Forschungsdurchlauf zu den angeforderten Ergänzungen durch; erforsche die Teile, die der Benutzer bereits geschrieben hat, nicht erneut.
• Aufzählungsliste mit Titeln aber ohne Beweise – z. B. "1. Bessere Leistung 2. Günstiger 3. Sicherer". Löse Forschung aus, um konkrete Zahlen oder Beispiele anzuhängen; sonst wirken die Karten wie KI-Füllmaterial.
• Artikel + eigene Meinung oder Standpunkt des Benutzers – überspringe Forschung zur Quelle, bestätige aber mit dem Benutzer, ob die Meinung wörtlich übernommen oder umstrukturiert werden soll.
• URL, deren Inhalt bereits früher in dieser Unterhaltung abgerufen und besprochen wurde – behandele wie eingefügten Inhalt, überspringe Forschung, aber schreibe die URL dennoch in sources.md.

Wenn die Eingabe mehrdeutig ist, stelle eine klärende Frage ("Soll dieser Inhalt direkt in Karten umgewandelt werden, oder soll ich zuerst recherchieren und dann erweitern?"), anstatt zu raten – eine falsche Forschungsentscheidung verschwendet entweder die Zeit des Benutzers oder das Forschungsbudget des Modells.

Fragen an den Benutzer stelle

Frage einmalig zu Beginn, vor der Konzeptplanung, nach fehlenden Generierungsparametern. Behandle "Fragen an den Benutzer stellen" als eine portable Entscheidungsrichtlinie, nicht als Anforderung, ein bestimmtes Tool aufzurufen. Verschiedene Codierungsagenten bieten unterschiedliche Interaktionsprimitive an, daher muss der Skill funktionieren, wenn strukturierte Fragetools vorhanden, nicht vorhanden oder durch den Betriebsmodus des Agenten nicht empfohlen sind.

• Extrahiere zuerst bekannte Werte für content, ratio, count, theme/style, platform/audience und output/constraints.
• Frage den Benutzer vor der Planung nach Bestätigung der Generierungsparameter, wenn immer noch eine sinnvolle Wahl fehlt. Tue dies auch, wenn der Benutzer sagt: "Hilf mir / Generiere / Erstelle / Gib direkt ein Bild aus / Schnell exportieren"; diese Phrasen fordern Ausführung an, nicht stille Parameterableitung.
• Frage, wenn die Antwort das Ergebnis materiell verändert. Prioritätsreihenfolge: content/source intent, ratio, count, theme/style, platform/audience, output/constraints.
• Frage standardmäßig maximal 3 prägnante Fragen. Verwende bis zu 5 nur, wenn der Benutzer explizit Konfigurationsoptionen wünscht oder die Ausgabe von hoher Bedeutung ist.
• Frage nicht erneut nach Parametern, die in der ursprünglichen Anfrage des Benutzers bereits explizit sind.
• Überspringe den Fragenschritt nur, wenn der Benutzer explizit sagt, keine Fragen zu stellen, oder explizit die Standardparameter genehmigt. Verwende in diesem Fall die Standardeinstellungen und nenne die Annahmen kurz vor oder während der Ausführung.

Kompatibilitätsstrategie

Verwende den besten verfügbaren Fragemechanismus der aktuellen Umgebung:

• Wenn die Umgebung ask_user_question, ask question oder eine gleichwertige native Klärungsfähigkeit unterstützt, verwende diese native Interaktion, um blockierende Fragen zu klären.
• Wenn die Umgebung keine native Fragfähigkeit unterstützt, frage direkt im normalen Gespräch.
• Stelle maximal 2-5 Fragen auf einmal.
• Wenn fehlende Informationen die Aufgabe nicht blockieren, frage dennoch einmal nach Bestätigung der Parameter, die die endgültige Ausgabe beeinflussen. Wenn der Benutzer bereits Standardeinstellungen genehmigt oder um keine Fragen gebeten hat, triff angemessene Annahmen und fahre fort.
• Liste wichtige Annahmen explizit in der endgültigen Antwort, sources.md oder credits.md auf.

Stoppbedingungen

Stoppe und frage vor der Generierung nur, wenn eine dieser Bedingungen zutrifft:

• Es gibt keinen nutzbaren content, kein Thema, keine URL oder kein Quellmaterial.
• Die Quellabsicht ist mehrdeutig und eine falsche Wahl würde die Arbeit verschwenden, z. B. "diesen Text unverändert verwenden" versus "dieses Thema recherchieren und erweitern".
• Das angeforderte Verhältnis / die Plattform ist widersprüchlich oder mit einem einzigen Export nicht erfüllbar.
• Die visuelle Richtung unterliegt Marken-, rechtlichen, Barrierefreiheits- oder exakten Kopiereinschränkungen, die fehlen.
• Die Forschung findet umstrittene Fakten, die die Kernbehauptung ändern würden.

Andernfalls frage einmal nach Bestätigung der sinnvollen Generierungsparameter, fahre dann mit dokumentierten Annahmen fort und zeichne sie in sources.md oder der endgültigen Antwort auf.

Frage zum Verhältnis

Verwende diese Standardoptionen:

• 1:1 quadratische Karte für allgemeines Social Sharing.
• 3:4 vertikale grafische Karte für text-/bildreichere Beiträge.
• 9:16 Story, Reel, Kurzvideo-Cover oder mobile Karte.

Akzeptiere freie Formate wie 4:5, 16:9 oder exakte Pixelgrößen, wenn der Benutzer sie angibt.

Frage zur Anzahl

Verwende diese Standardoptionen:

• Automatische Empfehlung basierend auf dem Inhalt.
• 3 Karten für eine kompakte Erzählung.
• 5 Karten für einen Standard-Erklärer.
• 7 Karten für ein volleres Karussell.

Wähle bei automatischer Empfehlung den kleinsten Satz, der die Idee abdeckt, ohne zu überladen. Bevorzuge 3-7 Karten für Erklärer und 1-3 Karten für Ankündigungen.

Frage zum Thema

Setze den vollständigen Preset-Katalog nicht direkt dem Benutzer aus. Lade references/themes/presets.md und, wenn die visuelle Richtung wichtig ist, references/design-languages.md; empfehle dann 3-5 szenariobasierte Stiloptionen basierend auf Inhalt, Plattform, Zielgruppe und Teilungsziel. Ordne das vom Benutzer gewählte Szenario intern der endgültigen Themen-Preset- und Designsprachenkombination zu.

Wenn du den Benutzer bittest, einen Stil auszuwählen, präsentiere nicht nur eine Empfehlung plus eine vage "oder ändern?"-Frage. Gib 3-5 konkrete Optionen, jede mit:

• einem kurzen benutzerseitigen Stilnamen;
• der Situation, in der es am besten funktioniert;
• einer einzeiligen visuellen Beschreibung;
• der internen Themen-Preset- und Designsprachenzuordnung.

Verwende eine zweischichtige Auswahllogik, damit die Ausgaben angemessen bleiben, ohne in dieselben wenigen Looks zu verfallen:

1. Standardempfehlungsebene:

   • Biete 3-5 gut passende Stile basierend auf Inhaltstyp, Plattform, Zielgruppe und Teilungsziel an.
   • Halte den empfohlenen Satz nah genug an der Aufgabe des Benutzers, dass jede Option ohne umfangreiche Nacharbeit erfolgreich sein kann.
   • Bevorzuge Optionen, die sich im sichtbaren Ergebnis unterscheiden, nicht nur in Token-Namen. Zum Beispiel: konservativer Bericht, Datenposter, soziales Notizbuch, Magazin-Erklärer, mutige Meinung.

2. Variantenstörungsebene:

   • Wenn der Benutzer keinen starken exakten Stil angegeben hat, rotiere innerhalb der kompatiblen Familie, anstatt immer die beste Standardoption auszuwählen.
   • Variiere mindestens zwei dieser Dimensionen über ähnliche Aufgaben hinweg: Themen-Preset, primäre Designsprache, Modifikatoren, Layout-Rezepte, visuelle Anker, Oberflächenmetapher oder Titelkomposition.
   • Halte Störungen semantisch kompatibel mit dem Inhalt. Verwende keine zufällige Neuheit, die gegen das Thema, die Plattform, die Barrierefreiheit oder die sachliche Klarheit kämpft.
   • Zeichne die endgültig ausgewählte Kombination im Konzeptplan oder in sources.md / credits.md auf, damit die Variation überprüfbar ist.

Verwende benutzerseitige Szenariolabel wie:

• Engineering-Infografik: ordne zu engineering-paper, product-manual oder porcelain-research.
• Business-Briefing: ordne zu quiet-report, product-manual oder porcelain-research.
• Mutige Meinung: ordne zu bold-editorial, magazine-eink oder newsroom-paper.
• Soziales Produktnotiz: ordne zu social-notebook, magazine-eink oder bold-editorial.
• Redaktionell / Magazin: ordne zu magazine-eink, dune-gallery, field-notes oder kraft-editorial.

Für Designsprachenoptionen verwende benutzerseitige Szenariolabel wie:

• Technisch aber designed: ordne zu editorial-artifact + cutaway + annotation.
• Magazin-Erklärer: ordne zu image-led-magazine + edge-crop + asymmetric-space.
• Mutige These: ordne zu `swiss-po

…

[gekürzt für die Übersetzung]