tjdgus4560/cardnews-maker-skill

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

Transformez un sujet, un article source (URL) ou un fichier brouillon en une série d'images de card-news 800×800 soignées. L'utilisateur apporte un nouveau sujet à chaque fois ; vous lisez/dérivez le contenu, le structurez en cartes, les générez, puis exécutez une boucle d'auto-relecture et de correction avant de livrer le résultat.

L'apparence est fixe (donc chaque série semble faire partie d'une même famille), mais le thème de couleurs s'adapte au sujet à chaque fois. La mise en page, la typographie, l'espacement et la boucle de révision restent constants.

Quand demander vs. quand décider

L'utilisateur souhaite explicitement que vous lui demandiez tout ce qui est vraiment ambigu plutôt que de deviner. Utilisez AskUserQuestion (proposez d'abord une option recommandée) lorsque la réponse modifierait significativement le résultat et n'est pas déductible. Sinon, décidez et énoncez brièvement votre choix.

Décidez vous-même (ne demandez pas) :

• Nombre de cartes — adaptez au contenu, généralement 8 à 15 (couverture + corps + clôture).
• Thème de couleurs — choisissez-en un qui correspond au sujet/à la marque (voir les références).
• Mise en page par carte (carte de corps standard vs. carte statistique vs. diagramme/liste de contrôle).
• Rédaction en coréen, plages de surbrillance, étiquettes d'accroche.

Demandez à l'utilisateur (en cas d'ambiguïté) :

• Ambiguïté de la source : seulement un sujet d'une ligne sans source et le champ est large → demandez s'il faut effectuer une recherche web, ou quel angle/profondeur ils souhaitent.
• Titre de couverture lorsqu'aucun titre fort ne se dégage clairement (par défaut : proposez-en un + offrez une meilleure alternative, laissez choisir).
• Public/ton si le sujet peut être abordé de plusieurs façons (par exemple, briefing cadre vs. explication pour débutant) et que cela change matériellement le texte.
• Tout ce que l'utilisateur signale comme « 판단 애매 » — présentez-le comme une question.

Lorsqu'une préférence récurrente est décidée, il est acceptable de la noter pour que les exécutions futures soient plus fluides — mais ne bloquez jamais l'ensemble du travail sur une question à laquelle vous pouvez répondre par une valeur par défaut raisonnable.

Flux de travail

1. Obtenir le contenu

• URL → récupérez-la (WebFetch) et extrayez la thèse, les points clés, la terminologie, les chiffres/citations notables, et les principaux enseignements.
• Texte / fichier brouillon → lisez-le ; traitez un brouillon fourni chapitre par chapitre comme la structure principale. Vous pouvez le peaufiner légèrement, mais conservez la structure de l'utilisateur.
• Sujet d'une seule ligne uniquement → si le champ est large et qu'il n'y a pas de source, demandez si une recherche web est souhaitée ou quel angle ils veulent avant d'inventer du contenu.

Restez fidèle à la source. Évitez la surinterprétation. Lorsque vous ajoutez l'angle « ce que nous devrions apprendre / 시사점 », formulez-le comme des leçons tirées de la source, et non comme des prescriptions personnelles. Reformulez tout impératif « faire X / 하라 » en observations (« X est important », « X devient fort quand »).

2. Planifier la série

Décidez du nombre de cartes et du rôle de chaque carte. Un arc typique : couverture → accroche/introduction → contexte → concepts clés (une idée par carte) → une carte statistique ou diagramme si cela facilite la transmission → message de clôture (+ lien source).

Utilisez une idée par carte. Si le texte d'une carte déborde, scindez-la.

Choisissez un thème de couleurs adapté au sujet et lisez references/design-system.md pour les tokens exacts, la mise en page des cartes et les motifs de composants. Lisez references/card-patterns.md pour les variantes de cartes prêtes à l'emploi (couverture, corps, statistique, diagramme, liste de contrôle, clôture).

3. Construire le HTML

Utilisez scripts/build.js comme point de départ — il encode déjà le système de mise en page (CSS de base, chip d'accroche, titre, séparateur, corps avec plages de surbrillance, pied de page, décoration de vague fluviale) et produit un fichier HTML par carte dans cards/. Copiez-le dans le répertoire de travail et modifiez les définitions de cartes et les couleurs du thème pour ce sujet. Ne réécrivez pas le moteur de mise en page à partir de zéro.

4. Rendu en PNG

Exécutez scripts/render.js (Playwright + Chromium, deviceScaleFactor 2 → images PNG 800×800 nettes dans out/). Configuration unique si Playwright n'est pas installé : npm install playwright && npx playwright install chromium.

5. Boucle d'auto-relecture et de correction (toujours faire ceci)

C'est obligatoire, pas optionnel — c'est ce qui rend le résultat final soigné.

• Relisez les PNG générés (outil Read) et inspectez chaque carte.
• Vérifiez : collision du texte du corps avec le pied de page, déséquilibre des espaces vides, débordement de texte / sauts de ligne maladroits, contraste/lisibilité, accroche et pied de page cohérents, numéros de page et nombre total corrects.
• Corrigez les problèmes dans build.js, regénérez le rendu, et revérifiez les cartes affectées.
• Ne livrez que lorsque l'ensemble est propre. Voir references/review-checklist.md pour la liste complète et les correctifs courants.

6. Livrer

Où sauvegarder — choisissez l'emplacement de sortie en fonction du contexte, afin que les résultats atterrissent là où l'utilisateur les chercherait :

1. Si vous travaillez dans un projet/dépôt (la session a une racine de projet — par exemple un dépôt git, ou l'utilisateur opère clairement dans un répertoire de travail spécifique) : sauvegardez tout sous cette racine de projet, dans <racine-du-projet>/cardnews/<sujet>/. Mettez-y aussi les artefacts intermédiaires (le build.js de travail, cards/*.html, out/*.png) pour que la série soit reproductible et versionnable avec le projet. C'est le comportement par défaut dès qu'un contexte de projet existe.
2. S'il n'y a pas de contexte de projet (une demande ponctuelle, ad-hoc, sans dépôt de travail) : sauvegardez dans un emplacement global approprié au système d'exploitation — <home>/cardnews/<sujet>/ (fonctionne sous Windows, macOS, Linux de manière identique ; évitez de coder en dur Downloads).
3. Si l'utilisateur nomme un emplacement, respectez-le plutôt que les règles ci-dessus.

Indiquez où vous avez sauvegardé les fichiers. La sortie par défaut est PNG uniquement (plus le HTML intermédiaire lors de la sauvegarde dans un projet, selon la règle 1). Générez le PDF A4 uniquement sur demande (ou proposez-le proactivement) en utilisant scripts/make_pdf.py, qui place chaque carte sur une page A4 avec zéro marge gauche/droite (la carte remplit la largeur de la page) et des marges haut/bas égales — lisez son commentaire d'en-tête pour le comportement.

Conservez les fichiers de travail (build.js etc.) dans un dossier de projet pour que l'utilisateur puisse modifier le texte et relancer node build.js && node render.js.

Valeurs par défaut (style maison de cette compétence)

• Taille : 800×800 carré, échelle de rendu 2×.
• Structure par carte : chip d'accroche (numéro + étiquette) → titre → séparateur → corps avec plages de surbrillance sélectives → pied de page unifié (source · NN / total).
• Couverture & clôture : dégradé pleine page dans la couleur du thème, motif de vague ; la carte de clôture porte le lien source.
• Sortie : PNG par défaut ; PDF A4 sur demande.
• Langue : texte en coréen (les termes techniques / identifiants restent dans leur forme originale).

Ressources

• references/design-system.md — thèmes de couleurs, tokens CSS, anatomie des composants.
• references/card-patterns.md — variantes de cartes copiables avec exemples.
• references/review-checklist.md — ce qu'il faut vérifier et comment corriger chaque problème.
• scripts/build.js — générateur de cartes HTML (moteur de mise en page + définitions de cartes).
• scripts/render.js — moteur de rendu Playwright HTML→PNG.
• scripts/make_pdf.py — assembleur de PDF A4 (marge latérale nulle, marge haut/bas).