Communitygithub.com

JP Magazine Poster

Compétence Codex pour générer des cartes sociales de style éditorial japonais moderne.

Qu'est-ce que JP Magazine Poster ?

Cette compétence transforme un sujet, un texte source ou un ensemble d'images fourni par l'utilisateur en affiches de style magazine japonais. Elle est conçue pour fonctionner avec Codex et nécessite Node.js, Playwright (optionnel pour l'export PNG), et un accès à des modèles de génération d'images ou à des outils SVG. Le workflow inclut un seul tour de clarification (sous forme de questions structurées) pour déterminer le style, le nombre d'affiches, les sources d'images, etc. Les choix par défaut sont appliqués si l'utilisateur ne précise pas tout. Les images sont sélectionnées par ordre de priorité : images fournies par l'utilisateur, génération bitmap via modèle/outil, puis SVG en dernier recours. L'export final produit un fichier HTML par affiche, un PNG (si Playwright est disponible), et un manifeste JSON. La compétence impose des règles de qualité strictes (pas de fichiers .svg dans le HTML final, respect des contraintes de mise en page des gabarits, validation automatique après rendu) pour garantir un résultat professionnel.

Compatible avec~Claude Code✓Codex CLI~Cursor
npx skills add Buds-2025/jp-magazine-poster

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait JP Magazine Poster ?

Workflow

Utilisez cette compétence pour transformer un sujet, un texte source ou un ensemble d'images de l'utilisateur en fichiers d'affiches de style magazine japonais.

  1. Lisez references/template-contract.md avant de sélectionner les gabarits ou de remplir les zones.
  2. Avant le travail de production, posez exactement un tour de clarification sous forme de formulaire :
    • Résumez la demande actuelle de l'utilisateur en 1 à 3 phrases courtes.
    • Demandez des choix manquants ou à confirmer concernant le style/thème, le nombre d'affiches, les sources d'images, la sélection du gabarit, le ton du texte, le répertoire de sortie, et tout contenu à utiliser ou à éviter impérativement.
    • Privilégiez des questions numérotées compactes avec des options concrètes lorsque c'est utile.
    • Ne posez la question qu'une seule fois. Ne bouclez pas pour plus de clarification après la réponse de l'utilisateur.
    • Si l'utilisateur laisse encore des lacunes, procédez avec des valeurs par défaut raisonnables et consignez ces hypothèses dans le cahier des charges ou le manifeste.
  3. Comprenez le thème de l'utilisateur et le nombre de sorties demandé à partir de la demande initiale et de cette seule réponse.
  4. Choisissez les gabarits :
    • Utilisez les identifiants de gabarit explicites fournis par l'utilisateur.
    • Utilisez les 8 gabarits lorsque l'utilisateur demande tous les styles.
    • Sinon, choisissez le moins de gabarits possible qui correspondent à la forme du contenu.
  5. Créez un contenu concis pour chaque zone :
    • title : pas de ponctuation finale. Les propositions courtes peuvent utiliser des virgules à l'intérieur du titre.
    • goldenQuote : doit se terminer par un point de fin de phrase en chinois ou en anglais.
    • detail : ponctuation normale et contexte factuel de la source.
    • Remplacez les guillemets chinois par des crochets angulaires, sauf si l'utilisateur demande explicitement le texte original cité.
    • Évitez les lignes d'un seul caractère et les lignes d'un seul caractère suivi de ponctuation.
  6. Choisissez les images par ordre de priorité strict :
    • Chemins ou URLs d'images fournies par l'utilisateur.
    • Appelez un modèle ou un outil disponible sur le système pour générer des images bitmap adaptées au thème, puis enregistrez les fichiers raster sélectionnés dans le répertoire de sortie avant le rendu.
    • Dessinez des illustrations SVG raffinées uniquement après que les images fournies par l'utilisateur sont absentes et que les modèles/outils de génération d'images disponibles sont indisponibles, échouent, ou ne peuvent pas renvoyer de fichiers bitmap locaux au projet. Consignez cette raison dans assumptions ou manifest.
    • Le SVG ne peut être utilisé que comme source de dessin interne et doit être pixellisé en PNG avant le rendu HTML final.
  7. Écrivez un cahier des charges JSON d'entrée et exécutez :
node scripts/render_poster.js --spec input.json --out output/<run-name>
node scripts/validate_poster.js --html output/<run-name>/*.html

Si la validation échoue, raccourcissez ou réécrivez le texte, ajustez les sauts de ligne explicites, changez le focus de l'image, puis refaites le rendu et la validation.

Exigences de qualité

  • Ne commencez pas le rendu, la génération d'images ou l'adaptation du texte tant que le formulaire de collecte en un tour n'a pas été posé et répondu, sauf si l'utilisateur dit explicitement de sauter les questions.
  • Les détails manquants après la collecte en un tour doivent être comblés par des valeurs par défaut pratiques plutôt que par des questions supplémentaires.
  • Le HTML final ne doit pas référencer de fichiers .svg ou data:image/svg+xml.
  • Les sources d'images doivent suivre la priorité stricte : images fournies par l'utilisateur, puis génération bitmap disponible sur le système, puis dessin SVG raffiné en dernier recours.
  • Les images générées, dessinées ou de repli doivent être écrites sous forme de fichiers PNG/JPEG/WebP dans le répertoire de sortie avant d'être placées dans les zones d'image.
  • Ne traitez pas l'art de remplacement de gabarit ou la pixellisation SVG comme équivalents à la génération bitmap par modèle/outil. Si la génération par modèle/outil est ignorée ou échoue, enregistrez la raison exacte.
  • L'export PNG par défaut est à l'échelle 2x pour une sortie de révision plus nette.
  • Les notes de l'objet-carte du gabarit 03 doivent être très courtes car chaque carte a une hauteur de ligne fixe de 216px.
  • Les zones d'image du gabarit 06 doivent conserver .jp-photo-zone { width: 100%; max-width: 100%; } afin que l'image de gauche ne puisse pas empiéter sur la colonne de texte de droite.

Format du cahier des charges

Entrée minimale :

{
  "theme": "white",
  "templates": ["vertical-02"],
  "sourceText": "Sujet ou texte source de l'utilisateur",
  "assumptions": ["Valeurs par défaut utilisées après la collecte en un tour."],
  "images": [
    {
      "slot": "single-photo-feature",
      "src": "D:/path/to/image.png",
      "fit": "cover",
      "focus": "center 50%"
    }
  ],
  "content": {
    "title": "Titre de l'affiche",
    "goldenQuote": "Une phrase éditoriale claire.",
    "details": ["Détail un.", "Détail deux."]
  }
}

Remarques :

  • theme accepte white, midnight, light ou dark.
  • templates accepte des identifiants de gabarit tels que vertical-02, des noms de gabarit tels que vertical-single-photo-headline, ou all.
  • content.details peut être un tableau de chaînes ou d'objets avec heading, title et body.
  • images[].slot doit correspondre à un data-slot-id ou data-relation-id listé dans le contrat du gabarit.

Sortie

Le script de rendu crée :

  • Un fichier HTML par affiche.
  • Un fichier PNG par affiche lorsque Playwright est installé et que Chromium est disponible.
  • manifest.json avec le gabarit, le thème, la source de l'image, les chemins des fichiers de sortie, et le statut de validation/export.
  • generated-images/*.png lorsque des images générées, de repli ou issues de SVG sont pixellisées.

Conservez la mise en page originale du gabarit intacte. Ne modifiez pas les tailles de police, les hauteurs de ligne, les largeurs, les marges de sécurité, les paramètres de grille, ou la structure visuelle pour forcer le contenu à tenir. Corrigez le contenu à la place.

Skills associés