contenu-conforme-marque

name	contenu-conforme-marque
description	Utiliser quand l'utilisateur demande de respecter la charte, le ton de la marque ou les couleurs de la marque — et en amont de toute génération de contenu ou de template. Charge l'identité de marque et l'impose partout.

Contenu conforme à la marque

Étape 0 — Références (obligatoire)

Charger ${CLAUDE_PLUGIN_ROOT}/reference/directives-outils.md (règles communes) et ${CLAUDE_PLUGIN_ROOT}/reference/charte-graphique.md — la charte complète les valeurs live de l'API (marges de protection, usages interdits, do/don't) et sert de repli si get_brand ne renvoie pas une valeur.

En multi-marques, résoudre d'abord la marque cible avant toute lecture (agent gestionnaire-marques — jamais de défaut silencieux), puis lire get_brand et les assets de la marque (list_all_files, convention "<Marque> — <type> — <variante>"). La KB reste la source de vérité ; en cas d'écart KB ↔ serveur, le signaler. Le cycle de vie des marques (création/édition/suppression) : skill gestion-marques.

Workflow

1. Charger l'identité (aucun paramètre requis) :
   • get_brand → couleurs, logo, éléments visuels de la marque ;
   • get_company → informations société (nom, activité, coordonnées) ;
   • get_profile → profil utilisateur.
2. Imposer ces éléments dans TOUT contenu produit ensuite :
   • visuels generate_image : intégrer les couleurs de la marque dans le prompt ; ne pas laisser le générateur choisir une palette arbitraire ;
   • captions et textes de posts (create_draft_tool) : respecter le ton de la marque (le déduire de get_brand/get_company ; si le ton n'y figure pas, le demander une fois et le réutiliser) ;
   • pages de cartes digitales (edit_card_page) : background et styles CSS inline aux couleurs exactes de la marque, logo via image_url ;
   • templates de posts (create_post_template) : mêmes contraintes.
3. Vérifier avant livraison : couleurs exactes (codes hex de get_brand, pas d'approximation), logo présent quand pertinent, ton homogène.

Résolution live des URLs & divergence KB ↔ CMS

L'ordre des sources ne change pas : ./rapido-kb/charte-graphique.md (PRIORITAIRE) → get_brand/get_company (live) → repli générique (signalé). Ce qui s'ajoute, au moment de l'exécution :

1. Résoudre les URLs RÉELLES des assets à utiliser (logo, visuels) : get_brand (logo + assets[]) puis list_all_files pour l'file_url publique exacte — ne jamais improviser une URL ni réutiliser un chemin de mémoire. C'est cette URL réelle qui part dans le prompt (studio-visuel-marque) ou le media_url/image_url.
2. Détecter la divergence KB ↔ CMS sur couleurs, logo, slogan : comparer la valeur KB (source de vérité) à la valeur get_brand (serveur). En cas d'écart, le SIGNALER explicitement (« ta KB dit #0052FF, la marque CMS dit #1A73E8 ») et proposer la synchronisation via gestion-marques (edit_brand) — jamais d'écrasement silencieux, dans un sens comme dans l'autre. Tant que l'utilisateur n'a pas tranché, appliquer la KB (prioritaire) et le dire. Le skill peut donc corriger, pas seulement constater : la correction passe par edit_brand (ou create_brand si la marque n'existe pas côté CMS), et le hook de validation de charte du plugin exige alors une confirmation humaine même quand les valeurs sont bien formées — toute modification de charte engage les contenus produits ensuite.

Assets de marque (logos officiels)

La marque porte désormais ses ASSETS (schémas vérifiés serveur) :

0. Consulter la bibliothèque d'abord — list_all_files (search par mot-clé, type ∈ image, video, doc) : le logo est peut-être déjà uploadé — ne pas créer de doublon.
1. Uploader les logos officiels — upload_file_tool (type: "image", name explicite ex. « logo principal — fond transparent », file_url publique). Privilégier les versions à FOND TRANSPARENT (PNG) : ce sont elles que les générations réutilisent proprement.
2. Les rattacher à la marque — add_asset (asset_id renvoyé par la bibliothèque + brand_id de get_brand). Une variante par usage : principal, monochrome, fond clair, fond foncé.
3. Les référencer dans TOUTE génération : visuels, cartes, templates — le logo vient des assets de marque, jamais d'une URL improvisée ni d'une génération IA (un logo généré est toujours déformé).
4. remove_asset (asset_id) sur confirmation uniquement (hook garde-destructif en filet) — retirer un logo de la marque impacte toutes les productions suivantes.

Pipeline vidéo (kit « Mika ») : les logos utilisés par la chaîne vidéo (video-marketing) viennent DÉSORMAIS des assets de marque CMS — plus du repo GitHub. Toute mise à jour de logo se fait donc ICI (add_asset), et le kit vidéo la récupère automatiquement.

Multi-marques : créer/modifier/supprimer une MARQUE (couleurs, typo, slogan, logo) = skill gestion-marques — ce skill-ci APPLIQUE la marque, il ne la définit pas.

Garde-fous

• Appeler get_brand UNE fois par session et réutiliser le résultat — pas besoin de le rappeler à chaque contenu.
• Si un élément de marque manque (pas de logo, pas de couleurs définies), le signaler à l'utilisateur et lui demander l'élément plutôt que d'inventer.
• Ne jamais écraser la charte : si l'utilisateur demande explicitement de s'en écarter, le faire mais le mentionner dans le récapitulatif.