Menu
Utiliser quand l'utilisateur demande le briefing du jour, « ma journée » ou un point du matin. Routine du directeur de restaurant — HACCP, réservations, salle, staffing, productions, stocks — synthétisée en un écran avec les 3 priorités de la journée.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Utiliser quand l'utilisateur configure Iris ou relie son restaurant à sa marque — « installe Iris », « appaire mon restaurant à ma marque », « Iris ne connaît pas mes couleurs », « synchronise ma charte pour les posts ». Crée la liaison établissement FoodEatUp ↔ marque RapidoCMS, prérequis de tout le reste.
Utiliser quand l'utilisateur veut voir, valider ou refuser les publications proposées — « montre le calendrier d'Iris », « qu'est-ce qui est prévu cette semaine », « valide le post de mardi », « refuse celui-là ». Calendrier glissant 7 jours avec la raison de chaque contenu, validation carte par carte, planification confirmée.
Utiliser quand une opportunité Iris validée doit devenir un contenu — « fabrique le visuel du plat du jour », « prépare le post du saumon », « génère la story de lancement ». Fabrique visuel + copy + raison aux couleurs de la maison (gate charte), dépose en brouillon RapidoCMS. Jamais de planification sans validation humaine.
Utiliser quand l'utilisateur veut savoir ce que la com a rapporté et améliorer la suite — « qu'est-ce que le post du saumon a donné », « bilan des publications d'Iris », « est-ce que ça ramène des commandes », « pourquoi Iris ne propose plus ça ». Insights réels, commandes attribuées, capitalisation des prompts gagnants, prise en compte des refus.
Utiliser quand l'utilisateur veut savoir quoi publier et pourquoi — « qu'est-ce qu'Iris propose », « trouve-moi des raisons de publier », « détecte les opportunités de com », « pourquoi poster aujourd'hui ». Lit les données d'exploitation FoodEatUp, score les signaux (urgence × valeur × fraîcheur), déduplique, et sort des opportunités avec leur raison.
Utiliser quand l'utilisateur veut une vidéo d'un plat ou de sa carte — « fais une vidéo virale de mon burger », « anime la photo du plat du jour », « une story vidéo pour le menu de la semaine », « ce plat mérite un reel ». Transforme les VRAIES photos de plats en vidéos courtes via Higgsfield, format réseaux, coûts en crédits confirmés avant.
Based on SOC occupation classification
| name | briefing-du-jour |
| description | Utiliser quand l'utilisateur demande le briefing du jour, « ma journée » ou un point du matin. Routine du directeur de restaurant — HACCP, réservations, salle, staffing, productions, stocks — synthétisée en un écran avec les 3 priorités de la journée. |
${CLAUDE_PLUGIN_ROOT}/reference/directives-outils.md et appliquer ses
règles pendant toute l'exécution (IDs, confirmations, données, formats, erreurs).establishment_id (le demander si absent) avant tout appel.Dérouler dans l'ordre des priorités maison (HACCP > client > rentabilité) :
get_daily_brief
(establishment_id) : le brief agrégé côté serveur (alertes du jour,
établissement actif). Il ouvre la collecte mais ne la remplace pas — les
étapes suivantes vérifient le détail dans chaque registre.list_notifications (establishment_id
seul ; pas de filtre serveur : filtrer les non lues dans la réponse) —
elles ouvrent le briefing : ce sont les alertes déposées par le système
et les routines (dont Loop Engine).list_haccp_temperatures (date du jour) : relevés
faits ? valeurs hors seuil ? list_haccp_reception : réceptions à contrôler ?
Toute non-conformité passe EN TÊTE du briefing.floor_plan_status
(compteurs par statut + commande active par table) remplace tout appel
séparé aux tables/zones. list_reservations (date du jour) reste la
source des couverts, gros groupes et notes (allergies, VIP) —
l'outil de disponibilité ne renvoie pas les réservations du jour.
Puis créneaux chauds du midi : reservation_availability teste UN
créneau à la fois (date, time HH:MM, party_size) — sonder 12:00 /
12:30 / 13:00 avec la taille de groupe typique et annoncer la capacité
restante (« complet à 12:30, reste 2 tables à 13:00 »).list_plannings (jour) : qui est présent par service ;
croiser avec la charge (couverts attendus) et signaler un sous/sur-staffing.list_production_plans (date du jour) : quoi
produire, en quelle quantité, à quelle heure.list_production_alerts : ingrédients manquants
pour les productions à venir.list_low_stocks : articles sous le seuil.create_notification
(establishment_id, title court, message factuel, type ∈
warning | danger) pour qu'elle atteigne toute l'équipe dans
FoodEatUp. Une confirmation PAR notification ; IDs récapitulés.📋 BRIEFING — {date} — {établissement}
🔔 NOTIFICATIONS NON LUES : n — les warning/danger citées une par une
🎯 3 PRIORITÉS DU JOUR
1. … (toujours la conformité s'il y a une non-conformité HACCP)
2. …
3. …
🌡 HACCP : relevés OK/KO, non-conformités, réceptions attendues
🍽 SERVICE : X couverts midi / Y soir, groupes & notes, état salle
(floor_plan_status), créneaux midi restants (12:00/12:30/13:00)
👥 ÉQUIPE : présents par service, alerte staffing éventuelle
🔥 PRODUCTION : plans du jour, ingrédients manquants
📦 STOCK : articles bas → commande à prévoir ?
Les 3 priorités sont ARBITRÉES, pas listées : une seule phrase chacune, actionnable, choisie selon l'ordre HACCP > expérience client > rentabilité.
create_notification), toujours après confirmation, une par
une. Chaque priorité
pointe vers le skill qui permet d'agir (haccp-conformite-quotidienne,
service-salle, production-stock, reappro-fournisseurs) — l'action ne se
lance que si l'utilisateur le demande.