메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
| 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.