feastalytics/cli

Feast CLI

Pilotez la plateforme Feastalytics depuis le terminal. Le CLI feast expose la même surface d'outils qu'utilise l'agent IA intégré à l'application (campagnes, automatisations, offres, entonnoirs, programme membres) sous forme de commandes simples qui appellent l'API de production en tant qu'utilisateur connecté.

Le CLI est la source de vérité pour quels outils existent et ce qu'ils acceptent — découvrez-les toujours à l'exécution plutôt que de les supposer, car l'ensemble des outils s'agrandit au fur et à mesure que de nouveaux points de terminaison sont tagués. Votre travail consiste à choisir le bon outil, le limiter à la bonne organisation et lui fournir une entrée valide.

Prérequis

Le CLI feast doit être installé et accessible dans le PATH :

npm install -g @feastalytics/cli    # ou exécutez ad-hoc avec : npx @feastalytics/cli <commande>

Authentifiez-vous une fois — les jetons sont mis en cache dans ~/.config/feast-cli/credentials.json et rafraîchis automatiquement :

feast login                        # ouvre un navigateur pour autoriser (par défaut)
feast login --password [nom_utilisateur]  # sans interface graphique / CI : invite nom d'utilisateur + mot de passe, pas de navigateur

Si une commande signale que vous n'êtes pas connecté ou que la session a expiré, relancez feast login.

Rester à jour

Ni le CLI ni cette compétence ne se mettent à jour automatiquement. Lorsqu'une commande imprime un avis de mise à jour sur stderr :

Update available: feast 0.1.1 → 0.2.0

mettez les deux à jour, puis informez l'utilisateur en une ligne que vous l'avez fait :

npm install -g @feastalytics/cli@latest      # seulement si `feast` est déjà dans le PATH via une installation globale
npx skills add feastalytics/cli -g -a '*' -y # rafraîchit cette compétence depuis le dépôt

Si vous avez invoqué le CLI via npx plutôt qu'une installation globale, sautez la commande npm install -g et utilisez npx @feastalytics/cli@latest <commande> pour le reste de la session — npx réutilise une copie en cache sinon.

Mettez à jour la compétence chaque fois que vous mettez à jour le CLI : les deux sont livrés depuis le même dépôt mais sur des déclencheurs différents, donc une nouvelle version du CLI signifie généralement que les conseils de cette compétence ont également évolué. Si l'installation globale échoue en raison de problèmes de permissions, ne réessayez pas avec sudo — informez l'utilisateur et revenez à npx @feastalytics/cli@latest.

La boucle principale : découvrir → décrire → appeler

Ne devinez pas les noms d'outils ou les formes d'entrée. Introspectez le CLI en direct :

feast tools                 # liste tous les outils disponibles, leur domaine et s'ils modifient
feast describe <outil>      # description complète + schéma JSON d'entrée pour un outil
feast call <outil> --org <organisationId> --input '<json>'

Décrivez toujours un outil inconnu avec describe avant de l'appeler — le schéma vous indique les champs exacts requis, et le CLI valide votre --input localement avant d'envoyer quoi que ce soit, donc une charge utile erronée échoue rapidement avec un message clair plutôt qu'une erreur serveur confuse.

Organisations : ne laissez jamais l'API deviner

La plupart des outils agissent sur une organisation. Un utilisateur appartient souvent à plusieurs, donc celle que vous ciblez compte et doit être explicite.

feast whoami                # affiche l'utilisateur connecté et chaque org (avec noms) qu'il peut gérer

Transmettez l'org cible avec --org <organisationId> :

• Si l'utilisateur nomme une org, résolvez-la en son identifiant avec feast whoami et passez cet identifiant.
• Si l'utilisateur appartient à une seule org, le CLI l'utilise automatiquement — pas de drapeau nécessaire.
• S'il appartient à plusieurs et que vous omettez --org, le CLI refuse et liste les orgs plutôt que d'en choisir une en silence. C'est intentionnel : agir sur la mauvaise org est pire que s'arrêter pour demander. Lorsque cela arrive, présentez la liste à l'utilisateur et confirmez laquelle il veut dire.

Lectures vs. écritures

Les outils de requête (lister, décrire, lire) sont sûrs et en lecture seule. Les outils de mutation (créer, mettre à jour, cloner, supprimer, appliquer) modifient les données de production.

• Les mutations nécessitent --org explicitement.
• Avant d'en exécuter une, le CLI résout l'organisation côté serveur et affiche son nom, donc un --org erroné apparaît comme le mauvais restaurant plutôt qu'un identifiant opaque. Lisez cette ligne.
• Il n'y a pas d'invite de confirmation. Une mutation s'exécute au moment où vous l'appelez. Rien ne demande deux fois, et rien ne l'annule.

Ce dernier point est le plus important pour les outils qui atteignent le monde réel plutôt que seulement la base de données. Acheter un numéro de téléphone facture le compte. Approuver une visite de créateur ou décider d'une soumission envoie un SMS à cette personne immédiatement et ne peut pas être rappelé. Publier une campagne la met en ligne, et tarifer une promotion récurrente crée de vrais produits Stripe. Enregistrer des modifications d'automatisation change ce que les invités reçoivent. Traitez-les comme irréversibles, et assurez-vous de l'intention de l'utilisateur avant l'appel, car il n'y a pas de garde-fou après.

Préférez la lecture avant l'écriture : par exemple, listCampaigns pour trouver le bon campaignId avant updateCampaign, ou describe/listAutomationFlows avant de créer un flux.

Construire une bonne entrée

--input prend une chaîne JSON (ou --input-file <chemin> pour les charges utiles plus grandes). Construisez-la à partir du schéma obtenu via describe. Lorsqu'un outil référence une autre entité par son identifiant (un identifiant de campagne, de lieu, de flux), recherchez d'abord cet identifiant avec l'outil de liste/lecture approprié plutôt que de l'inventer.

Pour la signification spécifique au domaine des champs — comment les automatisations s'enchaînent, ce que contient un écran d'entonnoir, comment les offres sont structurées — consultez les conseils dans references/domains.md lorsque le schéma seul ne suffit pas.

Workflows

De nombreuses tâches sont multi-étapes et ont un ordre requis que l'application impose normalement. La règle la plus importante : les automatisations vivent à l'intérieur de flux — trouvez toujours un flux (listAutomationFlows) ou créez-en un (createAutomationFlow) avant d'ajouter des automatisations ; ne créez jamais une automatisation orpheline. La même règle "résoudre d'abord les parents/identifiants, puis agir" se répète pour les campagnes, les entonnoirs et les offres.

Avant d'agir sur une tâche multi-étapes, lisez le fichier de workflow correspondant. Chacun contient l'ordre d'appel requis et les règles de domaine qui rendent le résultat bon plutôt que simplement valide — ni l'un ni l'autre ne se trouvent dans les schémas d'outils. Lisez-le d'abord ; ne reconstruisez pas la séquence à partir des descriptions d'outils.

Pour ceci	Lisez cela
Créer, cloner ou configurer une campagne ; offres dans le backlog stratégique	references/workflows/campaigns.md
Tout ce qui touche aux automatisations — créer, modifier, simuler, promouvoir un brouillon	references/workflows/automations.md
Modifier les écrans d'entonnoir, appliquer un modèle d'entonnoir, mettre en scène un nouvel écran	references/workflows/funnels.md
Écrire du contenu publicitaire Meta — destiné aux invités ou au recrutement de créateurs	references/workflows/facebook.md
Sourcing de créateurs — approuver des candidats, examiner leur contenu, conversations	references/workflows/creators.md
Récompenses du programme membres ; lire ou enregistrer la configuration du pass de portefeuille	references/workflows/members-program.md
Travailler sur le tableau de bord d'intégration ; identité de marque	references/workflows/onboarding.md
Rechercher des invités/membres et leur activité	references/workflows/guests.md

Lisez-en plus d'un lorsque la tâche les chevauche — une nouvelle campagne signifie généralement campaigns.md plus automations.md et funnels.md.

Certaines choses sont délibérément non exposées : répondre à un invité ou à un créateur par SMS, déclencher une automatisation sur un membre actif, mise à jour/suppression de récompense, génération d'image de pass, et la majeure partie du pipeline créateur au-delà des deux décisions d'approbation. Les fichiers de workflow le précisent. N'inventez pas d'appel pour un workflow dont les outils ne sont pas listés par feast tools — dites à l'utilisateur que cette partie n'est pas encore disponible.

Lien vers ce que vous avez touché

Le travail que vous effectuez via le CLI atterrit quelque part dans le produit, et un lien est une chose peu coûteuse à offrir — alors offrez-les librement. Après une action où vous avez créé, modifié ou publié quelque chose, terminez par une courte liste en markdown : où le voir, où le modifier, où le prévisualiser. Non pas parce que quelqu'un doit vérifier votre travail, mais parce qu'ouvrir la chose est généralement l'étape suivante de toute façon. Lorsque quelqu'un demande où se trouve une chose ou comment la configurer, commencez par le lien plutôt que par des instructions clic par clic.

Vous ne connaissez pas ces URL — lisez references/links.md avant d'en écrire une. La forme du tableau de bord n'est pas celle que vous extrapoleriez à partir des liens destinés aux invités ailleurs dans cette compétence, donc une URL qui semble évidente est exactement le cas à vérifier. Un mauvais lien est pire que pas de lien : il semble fiable mais génère une 404.

Ce fichier contient les routes du tableau de bord avec leurs noms de panneaux et d'onglets, les pages destinées aux invités sur le propre sous-domaine de l'organisation, la route de prévisualisation qui complète la boucle de brouillon d'entonnoir, et quels paramètres de requête suppriment réellement l'analytique par rapport à simplement marquer une visite comme prévisualisation.

Exemple travaillé

Utilisateur : "ajoutez une offre de réduction de 5 $ à l'emplacement Plum dans mon org Plum Vietnamese."

feast whoami                                    # trouver l'identifiant de l'org Plum Vietnamese
feast describe dfyCreateOffer                    # apprendre la forme d'entrée de l'offre
feast call dfyGetMenuHierarchy --org <orgId> --input '{"locationId":"<id>"}'   # trouver les identifiants emplacement/menu
feast call dfyCreateOffer --org <orgId> --input '{ ... }'                       # la créer (confirme d'abord)

Le modèle se généralise : identifier l'org, apprendre l'outil, résoudre les identifiants référencés, puis agir.

En cas d'échec

• "Non connecté / session expirée" → feast login (ou feast login --password [nom_utilisateur] dans un contexte sans interface graphique/CI).
• "Vous appartenez à plusieurs organisations" → choisissez-en une avec --org, en utilisant feast whoami pour obtenir l'identifiant.
• "L'entrée ne correspond pas au schéma de l'outil" → relisez feast describe <outil> et corrigez les champs nommés.
• Un outil attendu n'est pas listé par feast tools → il n'est peut-être pas encore exposé ; n'inventez pas d'appel, dites-le à l'utilisateur.