Feast CLI
Feastalytics プラットフォームをターミナルから操作します。feast CLI は、アプリ内 AI エージェントが使用するものと同じツール面(キャンペーン、自動化、オファー、ファネル、メンバーズプログラム)を、ログインユーザーとして本番 API を叩くプレーンなコマンドとして公開します。
CLI は、どのツールが存在し、何を受け付けるかの信頼できる情報源です。ツールセットは新しいエンドポイントがタグ付けされるたびに増えるため、常に実行時に発見するようにし、推測しないでください。あなたの仕事は、適切なツールを選び、正しい組織にスコープし、有効な入力を渡すことです。
前提条件
feast CLI がインストールされ、PATH が通っている必要があります:
npm install -g @feastalytics/cli # またはアドホックに実行: npx @feastalytics/cli <command>
一度認証すれば、トークンは ~/.config/feast-cli/credentials.json にキャッシュされ、自動的にリフレッシュされます:
feast login # ブラウザを開いて認可(デフォルト)
feast login --password [username] # ヘッドレス / CI: ユーザー名 + パスワードプロンプト、ブラウザ不要
コマンドがログインしていないかセッションの期限切れを報告した場合は、feast login を再実行してください。
最新状態の維持
CLI もこのスキルも自動更新はしません。コマンドが stderr に更新通知を出力した場合:
Update available: feast 0.1.1 → 0.2.0
両方を更新し、その旨を 1 行でユーザーに伝えてください:
npm install -g @feastalytics/cli@latest # `feast` がグローバルインストールで PATH 上にある場合のみ
npx skills add feastalytics/cli -g -a '*' -y # このスキルをリポジトリからリフレッシュ
グローバルインストールではなく npx 経由で CLI を呼び出している場合は、npm install -g をスキップし、以降のセッションでは代わりに npx @feastalytics/cli@latest <command> を使用してください。npx はそうしないとキャッシュされたコピーを再利用します。
CLI を更新したら、スキルも必ず更新してください。両者は同じリポジトリから出荷されますが、トリガーが異なるため、新しい CLI バージョンは通常、このスキルのガイダンスも変更されていることを意味します。グローバルインストールが権限で失敗した場合は、sudo で再試行せず、ユーザーに伝えて npx @feastalytics/cli@latest にフォールバックしてください。
コアループ: 発見 → 説明 → 呼び出し
ツール名や入力の形状を推測しないでください。動作中の CLI をイントロスペクトします:
feast tools # 利用可能なすべてのツール、そのドメイン、変更を伴うかどうかを一覧表示
feast describe <tool> # 1 つのツールの完全な説明と入力 JSON スキーマ
feast call <tool> --org <organizationId> --input '<json>'
馴染みのないツールを呼び出す前に、必ず describe してください。スキーマは正確な必須フィールドを教えてくれ、CLI は送信前に --input をローカルで検証するため、不正なペイロードは混乱するサーバーエラーではなく、明確なメッセージとともに迅速に失敗します。
組織: API に推測させない
ほとんどのツールは 1 つの組織に対して作用します。ユーザーは複数の組織に属していることがよくあるため、ターゲットとする組織は重要であり、明示的に指定する必要があります。
feast whoami # ログインユーザーと、操作可能なすべての組織(名前付き)を表示
ターゲット組織は --org <organizationId> で指定します:
- ユーザーが組織名を指定した場合、
feast whoamiでその ID に解決し、その ID を渡します。 - ユーザーが 1 つの組織にのみ属している場合、CLI は自動的にそれを使用します。フラグは不要です。
- 複数の組織に属しており、
--orgを省略した場合、CLI は黙って選択するのではなく、拒否し、組織を一覧表示します。これは意図的です。間違った組織に対してアクションを起こすことは、尋ねるのを止めるよりも悪い結果をもたらします。これが発生した場合は、組織の一覧をユーザーに提示し、どれを意味しているか確認してください。
読み取りと書き込み
クエリツール(一覧表示、説明、読み取り)は安全で読み取り専用です。変更ツール(作成、更新、クローン、削除、適用)は本番データを変更します。
- 変更操作には
--orgが明示的に必要です。 - 実行する前に、CLI はサーバー側で組織を解決し、その名前を出力するため、間違った
--orgは不透明な ID ではなく、間違ったレストランとして表示されます。その行を読んでください。 - 確認プロンプトはありません。 変更操作は呼び出した瞬間に実行されます。二度尋ねることも、元に戻すこともできません。
最後の点は、単なるデータベースではなく、現実世界に影響を及ぼすツールにとって最も重要です。電話番号の購入はアカウントに請求されます。クリエイターの訪問の承認や提出の判断は、その人にすぐにテキストを送信し、取り消しは効きません。キャンペーンの公開はそれを本番環境に投入し、定期プロモーションの価格設定は実際の Stripe プロダクトを作成します。自動化の編集を保存すると、ゲストが受け取るものが変更されます。これらを不可逆的なものとして扱い、ユーザーの意図を呼び出しの前に明確にしてください。呼び出し後にゲートはありません。
書き込みの前に読み取りを優先してください。例:updateCampaign の前に listCampaigns で正しい campaignId を見つける、フローを作成する前に describe/listAutomationFlows を行うなど。
良い入力の構築
--input は JSON 文字列(または大きなペイロードの場合は --input-file <path>)を受け取ります。describe で取得したスキーマから構築してください。ツールが別のエンティティを ID(キャンペーン ID、ロケーション ID、フロー ID)で参照する場合、その ID をでっち上げるのではなく、まず関連する一覧/読み取りツールで検索してください。
フィールドのドメイン固有の意味(自動化の連鎖方法、ファネル画面の内容、オファーの構造)については、スキーマだけでは不十分な場合、references/domains.md のガイダンスを参照してください。
ワークフロー
多くのタスクは複数ステップからなり、アプリが通常強制する順序が存在します。最も重要なルール:自動化はフローの中に存在します。自動化を追加する前に、必ずフローを見つけるか(listAutomationFlows)、または作成してください(createAutomationFlow)。孤立した自動化を作成しないでください。 同じ「親 ID を最初に解決し、それからアクションを起こす」というパターンが、キャンペーン、ファネル、オファーでも繰り返されます。
複数ステップのタスクに着手する前に、そのワークフローファイルを読んでください。 各ファイルには、必要な呼び出し順序と、結果を単に有効にするのではなく良いものにするためのドメインルールが記載されています。これらはツールスキーマには含まれていません。最初に読んでください。ツールの説明から順序を再構築しないでください。
| これを実行する場合 | 読むファイル |
|---|---|
| キャンペーンの作成、クローン、設定、戦略バックログ内のオファー | references/workflows/campaigns.md |
| 自動化に関わるすべて — 作成、編集、シミュレーション、ドラフトの昇格 | references/workflows/automations.md |
| ファネル画面の編集、ファネルテンプレートの適用、新しい画面のステージング | references/workflows/funnels.md |
| Meta 広告コピーの作成 — ゲスト向けまたはクリエイター募集 | references/workflows/facebook.md |
| クリエイターソーシング — 応募者の承認、コンテンツのレビュー、会話 | references/workflows/creators.md |
| メンバーズプログラム報酬、ウォレットパス設定の読み取りまたは保存 | references/workflows/members-program.md |
| オンボーディングタスクボードの操作、ブランドアイデンティティ | references/workflows/onboarding.md |
| ゲスト/メンバーの検索とアクティビティ | references/workflows/guests.md |
タスクがまたがる場合は、複数を読んでください。新しいキャンペーンは通常、campaigns.md に加えて automations.md と funnels.md を意味します。
一部の機能は意図的に公開されていません:SMS によるゲストまたはクリエイターへの返信、ライブメンバーへの自動化の実行、報酬の更新/削除、パス画像の生成、および 2 つの承認決定を超えるクリエイターパイプラインの大部分。ワークフローファイルには、どれが該当するかが記載されています。feast tools でリストされていないツールのワークフローに対して呼び出しをでっち上げないでください。その部分はまだ利用できないことをユーザーに伝えてください。
触れたものにリンクする
CLI を通じて行った作業は、どこかのプロダクトに反映されます。リンクを提供するのは簡単なことなので、積極的に提供してください。何かを作成、変更、公開した後は、短いマークダウンリストで締めくくってください:どこで見られるか、どこで編集できるか、どこでプレビューできるか。誰かがあなたの作業を確認しなければならないからではなく、通常、そのものを開くことが次のステップだからです。誰かがものがどこにあるか、または設定方法を尋ねた場合、クリックごとの手順ではなく、リンクを先に提示してください。
これらの URL は事前にわかっていません — リンクを書く前に references/links.md を読んでください。 ダッシュボードの形状は、このスキルの他の場所にあるゲスト向けリンクから推測できるものとは異なるため、明らかに正しいと思われる URL こそ、確認すべきケースです。間違ったリンクはリンクがないよりも悪いです。信頼できるように見えて 404 になります。
そのファイルには、パネル名とタブ名を含むダッシュボードルート、組織自身のサブドメイン上のゲスト向けページ、ファネルドラフトループを完了するプレビュールート、および実際に分析を抑制するクエリパラメータと単に訪問をプレビューとしてタグ付けするだけのものの違いが記載されています。
動作例
ユーザー: 「Plum Vietnamese 組織の Plum ロケーションに 5 ドル引きのオファーを追加して。」
feast whoami # Plum Vietnamese の組織 ID を見つける
feast describe dfyCreateOffer # オファーの入力形状を学ぶ
feast call dfyGetMenuHierarchy --org <orgId> --input '{"locationId":"<id>"}' # ロケーション/メニュー ID を見つける
feast call dfyCreateOffer --org <orgId> --input '{ ... }' # 作成する(最初に確認)
このパターンは一般化できます:組織を特定し、ツールを学び、参照されている ID を解決し、そしてアクションを起こします。
失敗した場合
- 「ログインしていない / セッションの期限切れ」→
feast login(またはヘッドレス/CI 環境ではfeast login --password [username])。 - 「複数の組織に属しています」→
feast whoamiで ID を取得し、--orgで選択してください。 - 「入力がツールスキーマと一致しません」→
feast describe <tool>を再確認し、指定されたフィールドを修正してください。 - 期待したツールが
feast toolsにリストされていない → まだ公開されていない可能性があります。呼び出しをでっち上げず、ユーザーに伝えてください。