tjdgus4560/cardnews-maker-skill

Card-News-Maker (카드뉴스 메이커)

Verwandle ein Thema, einen Quellartikel (URL) oder eine Entwurfsdatei in eine Reihe von gestalteten 800×800 Card-News-Bildern. Der Benutzer bringt jedes Mal ein neues Thema mit; Du liest/extrahiere den Inhalt, strukturierst ihn in Karten, renderst sie und führst dann eine Selbstprüfungs- und Korrekturschleife durch, bevor du auslieferst.

Das Erscheinungsbild ist festgelegt (damit jede Serie wie eine Reihe wirkt), aber das Farbthema passt sich jedes Mal dem Thema an. Layout, Typografie, Abstände und die Überprüfungsschleife bleiben konstant.

Wann fragen vs. wann entscheiden

Der Benutzer möchte ausdrücklich bei allem, was wirklich mehrdeutig ist, gefragt werden, statt dass du rätst. Verwende AskUserQuestion (biete zuerst eine empfohlene Option an) wenn die Antwort das Ergebnis bedeutend verändern würde und nicht ableitbar ist. Andernfalls entscheide und nenne deine Wahl kurz.

Entscheide selbst (nicht fragen):

• Anzahl der Karten — dem Inhalt anpassen, normalerweise 8–15 (Cover + Körper + Schluss).
• Farbthema — wähle eines passend zum Thema/zur Marke (siehe Referenzen).
• Layout pro Karte (Standard-Body-Karte vs. Statistik-Karte vs. Diagramm/Checkliste).
• Koreanische Textgestaltung, Hervorhebungen, Kicker-Labels.

Den Benutzer fragen (wenn unklar):

• Quellen-Mehrdeutigkeit: Nur ein einzeiliges Thema ohne Quelle und der Umfang ist breit → frage, ob im Web gesucht werden soll oder welchen Blickwinkel/welche Tiefe sie wünschen.
• Der Titel des Covers, wenn kein starker einzelner Titel entsteht (Standard: einen vorschlagen + eine bessere Alternative anbieten, sie wählen lassen).
• Zielgruppe/Ton, wenn das Thema in verschiedene Richtungen gehen könnte (z. B. Executive Brief vs. Einsteiger-Erklärung) und dies den Text wesentlich verändert.
• Alles, was der Benutzer als "판단 애매" kennzeichnet — als Frage aufwerfen.

Wenn eine wiederkehrende Präferenz festgelegt wird, ist es in Ordnung, sie zu notieren, damit zukünftige Durchläufe reibungsloser verlaufen — aber blockiere niemals den gesamten Auftrag mit einer Frage, die du mit einer sinnvollen Vorgabe beantworten kannst.

Arbeitsablauf

1. Inhalt holen

• URL → abrufen (WebFetch) und die These, Kernpunkte, Terminologie, bemerkenswerte Zahlen/Zitate sowie die wichtigsten Erkenntnisse extrahieren.
• Text / Entwurfsdatei → lesen; einen bereitgestellten Entwurf pro Kapitel als primäres Grundgerüst behandeln. Du darfst leicht verfeinern, aber die Struktur des Benutzers beibehalten.
• Nur einzeiliges Thema → wenn der Umfang groß ist und keine Quelle vorliegt, frage, ob im Web gesucht werden soll oder welchen Blickwinkel sie wünschen, bevor du Inhalte erfindest.

Bleibe quellentreu. Vermeide Überinterpretation. Wenn du den Aspekt "was wir lernen sollten / 시사점" hinzufügst, rahme ihn als Lehren, die aus der Quelle gezogen werden, nicht als persönliche Empfehlungen. Formuliere alle "do X / 하라"-Imperative in Beobachtungen um ("X가 중요하다", "X일 때 강해진다").

2. Deck planen

Entscheide die Kartenanzahl und die Rolle pro Karte. Ein typischer Bogen: Cover → Aufhänger/Einführung → Kontext → Kernkonzepte (eine Idee pro Karte) → eine Statistik- oder Diagrammkarte, wo sie das Verständnis fördert → Abschlussnachricht (+ Quellenlink).

Verwende eine Idee pro Karte. Wenn der Text einer Karte überlaufen würde, teile sie auf.

Wähle ein Farbthema passend zum Thema und lies references/design-system.md für die genauen Tokens, das Kartenlayout und die Komponentenmuster. Lies references/card-patterns.md für vorgefertigte Kartenvarianten (Cover, Body, Statistik, Diagramm, Checkliste, Schluss).

3. HTML erstellen

Verwende scripts/build.js als Ausgangspunkt — es enthält bereits das Layoutsystem (Basis-CSS, Kicker-Chip, Überschrift, Trennlinie, Text mit Hervorhebungen, Fußzeile, Wellen-Dekoration) und gibt eine HTML-Datei pro Karte in cards/ aus. Kopiere es in das Arbeitsverzeichnis und bearbeite die Kartendefinitionen und Themenfarben für dieses Thema. Schreibe die Layoutengine nicht von Grund auf neu.

4. In PNG rendern

Führe scripts/render.js aus (Playwright + Chromium, deviceScaleFactor 2 → scharfe 800×800 PNGs in out/). Einmalige Einrichtung, falls Playwright nicht installiert ist: npm install playwright && npx playwright install chromium.

5. Selbstprüfungs- und Korrekturschleife (immer durchführen)

Dies ist erforderlich, nicht optional — es ist das, was die Ausgabe fertig wirken lässt.

• Lies die gerenderten PNGs zurück (Read-Tool) und prüfe jede Karte.
• Überprüfe auf: Textkörper, der mit der Fußzeile kollidiert, Ungleichgewicht der Leerräume, Textüberlauf / ungünstige Zeilenumbrüche, Kontrast/Lesbarkeit, konsistenter Kicker & Fußzeile, korrekte Seitenzahlen und Gesamtzahl.
• Behebe Probleme in build.js, render erneut und überprüfe die betroffenen Karten.
• Liefere erst aus, wenn der gesamte Satz sauber ist. Siehe references/review-checklist.md für die vollständige Liste und häufige Korrekturen.

6. Ausliefern

Wo speichern — wähle den Ausgabeort je nach Kontext, sodass die Ergebnisse dort landen, wo der Benutzer sie suchen würde:

1. Wenn du innerhalb eines Projekts/Repos arbeitest (die Sitzung hat einen Projektstamm — z. B. ein Git-Repo, oder der Benutzer arbeitet eindeutig in einem bestimmten Arbeitsverzeichnis): speichere alles unter diesem Projektstamm, in <Projektstamm>/cardnews/<thema>/. Lege die Zwischenartefakte ebenfalls dort ab (das Arbeits-build.js, cards/*.html, out/*.png), sodass das Kartendeck reproduzierbar und versionierbar zusammen mit dem Projekt ist. Dies ist die Standardeinstellung, wenn ein Projektkontext existiert.
2. Wenn kein Projektkontext vorhanden ist (eine einmalige, ad-hoc-Anfrage ohne Arbeits-Repo): speichere an einem globalen, OS-üblichen Ort — <home>/cardnews/<thema>/ (funktioniert unter Windows, macOS und Linux gleichermaßen; vermeide hartcodiertes Downloads).
3. Wenn der Benutzer einen Ort nennt, bevorzuge diesen gegenüber den obigen.

Gib an, wo du die Dateien gespeichert hast. Standardausgabe ist nur PNG (plus das Zwischen-HTML beim Speichern in einem Projekt, gemäß Regel 1). Erstelle das A4-PDF nur auf Anfrage (oder biete es proaktiv an) mit scripts/make_pdf.py, das jede Karte auf eine A4-Seite mit null linkem/rechtem Rand (Karte füllt Seitenbreite) und gleichen oberen/unteren Rändern legt — lies den Kopfkommentar für das Verhalten.

Behalte die Arbeitsdateien (build.js usw.) in einem Projektordner, damit der Benutzer den Text anpassen und node build.js && node render.js erneut ausführen kann.

Vorgaben (Hausstil dieser Fähigkeit)

• Größe: 800×800 quadratisch, 2× Render-Maßstab.
• Struktur pro Karte: Kicker-Chip (Nummer + Label) → Überschrift → Trennlinie → Text mit selektiven Hervorhebungen → einheitliche Fußzeile (Quelle · NN / Gesamt).
• Cover & Schluss: randloser Farbverlauf im Themenfarbton, Wellenmotiv; Schlusskarte trägt den Quellenlink.
• Ausgabe: PNG standardmäßig; A4-PDF auf Anfrage.
• Sprache: Koreanischer Text (Fachbegriffe / Bezeichner bleiben in Originalform).

Ressourcen

• references/design-system.md — Farbthemen, CSS-Tokens, Anatomie der Komponenten.
• references/card-patterns.md — kopierbare Kartenvarianten mit Beispielen.
• references/review-checklist.md — was zu überprüfen ist und wie jedes Problem behoben wird.
• scripts/build.js — HTML-Karten-Builder (Layout-Engine + Kartendefinitionen).
• scripts/render.js — Playwright HTML→PNG-Renderer.
• scripts/make_pdf.py — A4-PDF-Zusammenstellung (null Seitenrand, oben/unten Rand).