KaigorodovTuskul/editorial-design-agent-skill

Édition Design — direction artistique originale, pas de remplissage de template

Objectif non négociable

Créer des publications cohérentes, distinctives et adaptées au contenu, avec l'ambition éditoriale d'un véritable studio de direction artistique. Le modèle est le directeur artistique. Ne réduisez pas le design à la sélection d'un des neuf types de diapositives prédéfinies. Le chemin original build <json> est un vestige de régression hérité, et non la stratégie de génération recommandée.

Vous devez réellement créer et réviser du HTML/CSS/SVG original, le rendre dans Chromium, observer le résultat, corriger les problèmes et vérifier les artefacts. Une compétence, un fichier de marque ou un script de lint ne peut pas remplacer une direction visuelle originale ni l'inspection des pages rendues. Hallmark est requis pour une version professionnelle, mais ce n'est pas un moteur de publication ni un substitut à cette compétence.

0. Début d'un nouveau projet interactif — thème et typographie

Au début d'un nouveau projet interactif, demandez une seule fois la palette et la police, avec une réponse simple : Utiliser les valeurs par défaut. La palette par défaut est Crystal Cobalt Enterprise — une direction design fondée sur des références avec du cobalt/ noire, cyan/violet clair retenus, des surfaces analytiques pâles, un artwork en verre prismatique original et quatre modes de direction artistique. La police par défaut est Geologica Roman (CRSV=0). Alternatives : Azure Iris Unified, Arctic Editorial, Deep Navy, Monochrome ; et Geist Sans, IBM Plex Sans, Onest, Manrope. Les contraintes de marque priment. Si la conversation a déjà établi une palette/police, héritez-en sans redemander. Les builds headless utilisent les valeurs par défaut et les persistent avec un indicateur de choix inféré.

Utilisez des instructions de production réelles, pas seulement des adjectifs descriptifs : pour Crystal Cobalt, lisez references/styles/crystal-cobalt-enterprise.md, references/quality/crystal-cobalt-hallmark.md et seeds/crystal-cobalt/README.md. Tout l'art réutilisable original se trouve sous seeds/crystal-cobalt/ ; n'incorporez jamais le logo d'AEB, son soleil ou son anneau de verre original spécifique. Utilisez la référence jointe comme inspiration stylistique et créez de nouvelles formes, compositions et marques originales.

Utilisez node bin/editorial.mjs seeds crystal-cobalt-enterprise pour lister les assets, ou node bin/editorial.mjs seed <project-dir> --theme crystal-cobalt-enterprise pour copier les assets de la graine dans le dossier assets/seeds/crystal-cobalt/ d'un projet. Le pipeline de build inclut également automatiquement les assets de la graine du thème sélectionné. N'aplatissez pas la diapositive en raster : maintenez des champs de texte HTML modifiables au-dessus du fond statique pour le PPTX hybride.

Les polices ne sont pas fournies. Avant la publication, confirmez l'installation exacte de la police correspondante dans le navigateur et le rendu PPTX ; les substitutions bloquent la publication, sauf approbation avec des preuves de parité régénérées.

1. Le contenu est l'entrée du design

Lisez les sources réelles (PDF de référence utilisateur, copie approuvée, modèle financier XLSX, tableaux, photographies et kit de marque). N'inventez pas de chiffres factuels, de logos ou de faits d'entreprise. Pour les modèles financiers de feuille de calcul, notez que openpyxl ne recalcule pas les formules. Étiquetez les valeurs de démonstration comme non vérifiées. Le design peut restructurer et resserrer la prose, mais ne doit pas changer le sens numérique, les unités, les dates, les avertissements, les dénominateurs, les signes ou la provenance de la source.

Avant de coder, cartographiez intérieurement le rythme narratif du document, par exemple : thèse d'ouverture → baseline négative → pivot stratégique → moteurs → scénarios → pont → décision. Créez un concept visuel distinct pour la publication : hiérarchie typographique, logique d'espacement, marques de graphiques, rythme calme/fort et un ou deux motifs signatures ancrés dans le contenu. N'empruntez pas littéralement la palette ou la grille de la source de référence sauf demande expresse. Réutilisez son ambition éditoriale, pas ses pixels.

2. Règles de direction artistique (liberté avec discipline)

• Écrivez des mises en page originales en HTML. Les grilles libres, le positionnement CSS, les formes CSS et les SVG conçus par l'auteur sont autorisés. Il n'y a aucune anatomie de diapositive fixe et aucune famille de modèles imposée par page.
• La composition suit l'affirmation. Une thèse d'une ligne peut occuper une demi-page. Un nombre peut être monumental. Un pont financier doit conserver son sens quantitatif. Ne mettez pas tout dans des cartes KPI, n'utilisez pas des grilles identiques page après page, et ne remplissez pas les espaces vides sans discernement.
• Un monde visuel, différentes compositions. Construisez une alternance rythmée d'asymétrique/calme/dense, clair/foncé, dominé par le texte/dominé par les données. Évitez les silhouettes identiques consécutives.
• L'ambition créative est requise, pas seulement tolérée. Utilisez une asymétrie frappante, une typographie expressive, des compositions SVG personnalisées, des formes superposées, des dégradés contrôlés, de l'illustration technique, de l'iconographie et des effets de texture subtils lorsque cela est utile. Rendez la richesse visuelle intentionnelle et spécifique au contenu ; ne transformez pas chaque diapositive en un héros à dégradé ondulé identique. Si une page semble générique malgré sa validité mécanique, reconcevez son concept visuel plutôt que d'ajouter une décoration aléatoire. Les images, si présentes, doivent être authentiques/sous licence ou clairement artistiques.
• Évitez la fausse précision, les affirmations financières inventées, la lueur indigo-violet par défaut, les icônes omniprésentes, les matrices de cartes décoratives, le cyrillique cassé, les graphiques de données insuffisamment remplis et les petits avertissements. Les dégradés intentionnels de marque nommée sont autorisés : Crystal Cobalt utilise explicitement du cobalt, du cyan et parfois un éclairage violet/magenta ; le conflit Hallmark 2a en amont doit être documenté dans l'audit brut. Préférez la lumière directionnelle structurée et la profondeur localisée aux taches floues uniformes. Autorisez les illustrations et les marques SVG lorsqu'elles clarifient l'histoire. Les icônes nécessitent une signification sémantique et une cohérence visuelle.
• Avant de coder, rédigez une partition visuelle d'une page (visual-plan.json ou notes) : un élément focal et une silhouette uniques par diapositive ; attribuez les modes de surface appropriés du thème sélectionné (Crystal Cobalt : atmospheric-dark, analytical-light, data-night, mixed-strategic ; Azure Iris : lighter, refined, darker) ; décrivez son motif signature et son rôle dans les données. Pour un deck de sept diapositives, visez au moins cinq silhouettes visiblement différentes ; ne forcez pas toutes les pages dans une seule composition. Sélectionnez dans le vocabulaire du thème sélectionné dans references/styles/ ou inventez un traitement original plus fort.
• Barrières de variation : les pages adjacentes ne doivent pas partager la même géométrie primaire, le même traitement héroïque, le même motif graphique et la même densité ; dans un deck, incluez à la fois des pages exceptionnellement sobres et fortement graphiques. Réservez au moins une composition qui brise la disposition attendue titre à gauche/graphique à droite. Utilisez un motif distinctif sur 2 à 3 pages maximum avant d'en varier l'expression. Ce sont des règles de révision de design, pas des affirmations numériques non fondées.
• Politique d'icônes : utilisez des icônes SVG en ligne intentionnelles et stylistiquement cohérentes, ou des pictogrammes fins conçus par l'auteur. Utilisez zéro icône pour une page purement typographique ou axée sur les données, 1 à 3 lorsqu'elles améliorent la hiérarchie, et jamais une icône au-dessus de chaque KPI uniquement pour la décoration. N'utilisez pas d'émojis comme substituts d'icônes.
• Effets et dégradés : autorisez plusieurs familles esthétiques dans la publication : par exemple, soie/ ruban irisé, traits de cartes de contour, champs de lumière découpés, calques techniques translucides, masquage typographique, panneaux légèrement dégradés, textures de grille fines et marques SVG liées aux données. Évitez de répéter le même effet sur chaque page. Gardez les SVG décoratifs hors des éléments de texte modifiables afin que le PPTX hybride les conserve dans le fond statique exact.
• Construisez un projet source avec project.json, des slides/01-*.html ... indépendants et assets/*.css. Chaque diapositive source est un document HTML complet hors ligne contenant exactement une <section class="slide"> de 1920×1080.
• Chaque texte/chiffre visible devant rester modifiable doit être un élément HTML explicite unique avec data-editable="true". Pour une fidélité PPTX maximale, rédigez chaque ligne affichée dans un élément séparé, sans spans de texte stylisés imbriqués, et avec CSS white-space:nowrap. Les figures SVG complexes et les décorations graphiques restent un fond statique. Les étiquettes de graphiques doivent être des éléments de texte HTML séparés si elles doivent être modifiables.
• Gardez le texte non rogné, y compris les avertissements, et assurez-vous que le texte natif peut tenir si les polices sont substituées. Utilisez des unités et des références réelles.

3. Dépendance obligatoire à Hallmark

Installez la révision en amont épinglée via npm run setup:hallmark ou un équivalent examiné manuellement dans vendor/hallmark. Lisez son SKILL.md ainsi que seulement les fichiers de référence pertinents (craft.md, layout.md, gates.md, data-viz.md). Le brief et le profil de design client priment sur les thèmes Hallmark aléatoires. Exécutez réellement Hallmark sloplint --genre editorial --render --json sur les pages créées, capturez le résultat et examinez ses conclusions. Les exceptions spécifiques à la publication aux règles de mise en page propres aux sites web peuvent être enregistrées avec des identifiants de règle et des raisons explicites, mais l'absence de Hallmark ne peut jamais compter comme PASS. Ne faites pas comme si l'outil s'était exécuté.

4. Rendu avec le moteur déterministe inclus

python examples/editorial-reference/build_example.py # démonstration optionnelle uniquement
node bin/editorial.mjs build-html <project-directory> --out <output-directory> --allow-unverified
node bin/editorial.mjs verify <output-directory>

build-html copie les fichiers HTML originaux conçus par l'auteur ; il ne les fait pas passer par un modèle de diapositive générique. Python Playwright/Chromium capture (i) des PNG/PDF complets et (ii) des fonds statiques de même taille de pixel avec seulement le texte [data-editable] masqué, plus les coordonnées DOM par élément, la police/style calculés et les résultats géométriques. PptxGenJS place ensuite ces fonds derrière le texte natif. Il s'agit d'un PPTX hybride modifiable, pas d'une reconstruction native complète de PowerPoint. Lors du déploiement, exigez une vérification --strict et les bonnes polices. Le HTML source, les captures d'écran et le manifeste d'édition par diapositive restent reproductibles.

5. QA visuelle : limitée mais réelle

La première prévisualisation créée n'est pas prête pour la livraison. Effectuez deux cycles de révision visuelle réels, en utilisant Playwright MCP si disponible, sinon le lecteur Playwright fourni. À chaque cycle, inspectez la planche contact et les diapositives pertinentes en pleine résolution. Le cycle 1 critique la hiérarchie, le rythme, l'unicité, le débordement, la densité, les graphiques et la clarté, puis applique un lot de corrections. Le cycle 2 rend à nouveau toutes les diapositives modifiées et audite les corrections/régressions. Un troisième cycle est conditionnel aux échecs P0/P1 ; n'exécutez jamais de boucles illimitées. Utilisez un sous-agent de critique à contexte frais uniquement s'il est réellement disponible et utile de manière substantielle. N'inventez pas d'outillage /goal : utilisez-le uniquement dans les harnais qui l'implémentent.

Les vérifications automatisées du DOM et des polices s'exécutent sur chaque diapositive. Utilisez les captures d'écran de manière stratégique (une planche contact plus les diapositives problématiques détaillées) pour contrôler l'utilisation des tokens. Enregistrez les deux révisions avec editorial review ... et les sommes de contrôle des captures d'écran. Pas de notes de révision sans inspection réelle. Interrompez l'exécution après le cycle 3 si des défauts persistent, avec un état NOT_READY honnête.

6. La fidélité PPTX est un bloqueur de publication

Ne prétendez jamais que le PPTX est identique au PDF simplement parce que des objets texte et des images de fond existent. Chaque build doit rouvrir le PPTX dans un rendu compatible réel, pixelliser toutes ses pages à la taille de référence HTML, comparer avec les golden HTML/PNG (et inspecter les différences graves). Utilisez :

python python/verify_pptx.py outputs/project/publication-editable.pptx --out outputs/project --visual --strict

Les vérifications comparent l'image entière, les régions de texte et le fond séparément et enregistrent les PNG réels des pages PPTX ainsi que les images de différence. Une couche exportée est une image pleine diapositive sans texte modifiable ; les calques de texte natifs doivent préserver ses coordonnées, sa famille, sa couleur et son poids. N'utilisez pas le réajustement automatique PowerPoint, car il modifie silencieusement la typographie. Évitez le texte natif enveloppé : une ligne créée → un objet texte natif. Les mêmes polices doivent être installées sur l'appareil récepteur. Les données source et l'illustration du graphique de fond ne se mettent pas à jour lorsque les nombres sont modifiés dans PowerPoint.

Limitation fondamentale : le texte natif PowerPoint rendu arbitrairement ne peut pas être garanti bit pour bit identique au texte Chromium sur toutes les machines et suites bureautiques. Promettez une tolérance testée sur un rendu nommé, pas une équivalence pixel-parfaite universelle. Échouez au portail lorsque la fidélité est en dessous du seuil. Ne substituez pas un texte modifiable transparent au-dessus d'un texte déjà cuit dans le fond : la valeur modifiée ne remplacerait pas visiblement l'ancienne.

7. Livraison et publication

L'utilisateur doit recevoir le PDF, le PPTX hybride, le HTML source, la planche contact et les preuves de QA (render-report.json, hallmark-report.json, pptx-verify-report.json, les diffs de parité et release-status.json). READY nécessite un véritable audit Hallmark, des polices installées/approuvées, de vrais cycles de révision visuelle, des affirmations financières vérifiées et un test de va-et-vient PPTX réussi, plus une approbation humaine pour la distribution aux investisseurs. Un démonstrateur peut être NOT_READY, et doit être étiqueté comme tel.

Lisez docs/art-direction.md et la spécification du thème sélectionné avant chaque nouvelle publication éditoriale. Documents supplémentaires : docs/architecture.md, docs/design-grammar.md, docs/quality-gates.md, docs/hybrid-pptx.md, docs/hallmark-integration.md.