| 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
- 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.
- 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.
- 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 :
- 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.
- 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) :
- 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.
- 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.
- 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é.
- 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é).
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.