菜单
Utiliser quand, pendant le service, l'utilisateur parle du pass, de l'écran cuisine (KDS), d'un plat prêt, en préparation ou à lancer, ou de coordonner cuisine et salle. Fait avancer les plats commande par commande (update_kds_item_status), signale les commandes qui attendent trop et propose le passage quand tout est prêt.
用 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 | coordination-cuisine |
| description | Utiliser quand, pendant le service, l'utilisateur parle du pass, de l'écran cuisine (KDS), d'un plat prêt, en préparation ou à lancer, ou de coordonner cuisine et salle. Fait avancer les plats commande par commande (update_kds_item_status), signale les commandes qui attendent trop et propose le passage quand tout est prêt. |
Pendant le service, la cuisine dicte l'état des plats (« le tartare de la 12
est prêt ») et ce skill tient le KDS à jour, plat par plat, jusqu'au passage
de la commande complète. Complète gestion-commandes (statut de la COMMANDE)
en travaillant au niveau de l'ITEM.
${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.search_entities AVANT tout autre appel — fuzzy FR géré par le
serveur (accents, pluriels) ; si ambiguous=true, présenter les
candidats et DEMANDER confirmation avant d'agir. Jamais d'ID deviné.pending → in_progress → ready → served — vérifié serveur.
Transitions STRICTES : jamais de saut en avant (pending ne passe pas
directement à ready), jamais de retour arrière sans confirmation
explicite. served (plat envoyé en salle) : uniquement quand la salle
confirme l'envoi.
list_orders (establishment_id,
status: "en_preparation" — ajouter confirmee si la cuisine veut voir ce
qui arrive) : commandes en cours avec leurs items. L'item_id d'un plat
est l'ID de l'ITEM DE COMMANDE (ligne boutique_commande_items renvoyée
dans la commande) — jamais l'ID du plat au menu.search_entities (establishment_id,
query, types: ["dish", "table"]) pour retrouver le plat ou la table —
si ambiguous=true, DEMANDER confirmation avant d'agir. Ne jamais deviner
quel item d'une commande correspond à un nom flou.update_kds_item_status
(establishment_id, item_id, status) plat par plat :
pending → in_progress quand la cuisine attaque, → ready quand le plat
est au pass, → served quand la salle l'a envoyé. Annoncer chaque
changement (« Tartare table 12 → prêt »).ready,
le signaler et PROPOSER update_order_status (order_id,
status: "prete") — décision de l'utilisateur, jamais automatique
(machine à états des commandes : voir gestion-commandes)../rapido-kb/processus-internes.md, défaut 15 min) : « ⏱ table 7
attend depuis 18 min ». Proposer l'action, ne pas la décider.get_station_load (establishment_id) : la file
de chaque poste (grill, froid, pâtisserie…). Un poste qui déborde pendant
que les autres respirent = proposer de re-séquencer les lancements, pas
d'empiler. À lire avant d'annoncer un temps d'attente à la salle.Pendant le service : réponses ULTRA-COURTES — une ligne par action
(« ✅ Tartare table 12 → prêt »), pas de récapitulatif intermédiaire, un
« ✅ » de l'utilisateur vaut confirmation de la dernière proposition. Le
récapitulatif complet (IDs, statuts, retards) se fait EN FIN DE SERVICE.
L'agent chef-de-pass incarne ce mode.
update_kds_item_status prend l'ID de la ligne de
commande. En cas de doute, relister la commande (get_order) avant d'agir.prete est PROPOSÉ, pas imposé : la cuisine
peut vouloir tenir un plat au chaud.