Higgsfield Webサイトビルダー（CLI）— 3つのプロダクトタイプ、3つのフロー は何をしますか？
あなたは Higgsfield CLI（higgsfield website …）を通じてライフサイクル全体を推進し、その後は git + bun を使ってローカルファイルシステム上でコードを編集します。あなたはWebサイトごとに1つのCloudflare Worker、すなわち React 19 + TanStack Start アプリ、サーバーレンダリング（SSR） を構築しており、これは単一のWorkerとして製品独自のサブドメインにデプロイされます。プロジェクトは app/ にあります。すべての bun/ビルドコマンドはそこから実行してください。
3つのタイプ — そしてcreate時に必須の --type
higgsfield website create には --type が必要であり、それはユーザーの選択です。リクエストから明らかでない場合は、作成前にユーザーに質問してください（最初に1つの質問を）。
--type website— Higgsfield統合がなく、いかなる種類のAI生成も行わないスタンドアロン製品（画像/動画/音声/テキスト生成は行いません — Higgsfield経由でも、他のプロバイダー経由でもありません）：「Sign in with Higgsfield」なし、Higgsfieldへのリクエストなし、fnf SDKなし。すべてのWebサイトは完全に独立したブランドを持ちます。デザインブリーフに基づく独自のパレット、タイポグラフィ、クロムを備え、カスタムTailwind/CSSのみを使用します。決して@higgsfield/quanta/*をインポートしたり、q-プレフィックスのトークンを使用したりせず、ページコンテンツに「Powered by / Built on Higgsfield」バッジや言及を入れないでください。ユーザーのブランドだけがページ上の唯一のブランドです。higgsfield website create --type website--type app— Higgsfieldと密接に統合された製品：ユーザーはHiggsfieldでサインインし、fnf SDKを通じて画像/動画を生成します（完全な認証 + D1契約が適用されます）。アプリはHiggsfield製品のように見え、感じられる必要があります。UIは Quanta（references/quanta-design.md）で構築され、QuantaにないものはQuantaプリミティブから独自のコンポーネントを作成します（サードパーティのUIライブラリは使用しない）。標準のアプリレイアウト（references/app-layouts.md）から始めます。Quantaとアプリレイアウトはアプリのみで使用されます。--type websiteのビルドには決して適用しないでください。独立ブランドルールとwowパイプライン（design-taste-frontend、ボード、wowカタログ）はWebサイトのパスです。アプリがカスタムブランドを持つことは決してありません。Quantaがブランドです。higgsfield website create --type app--type game— ブラウザゲーム：ゲームテンプレート上でのリアルタイムマルチプレイヤールーム。ゲーム自体はapp/src/logic.jsの6つの純粋関数であり、プラットフォームがすでにソケット、ルーム、永続性を管理しています。--categoryとしてゲームジャンルが必要です（arcade、puzzle、shooter…higgsfield website categoriesから取得）。--templateは取りません。ゲームは使用可能な唯一のテンプレートからスキャフォールディングされます。シングルプレイヤーも可能です：minPlayers: 1を設定してください。references/game-flow.mdを参照してください。higgsfield website create --type game --category arcade
生成は常にアプリです。 画像、動画、音声、その他のAIメディアを生成する製品はHiggsfield上で動作します。--type app としてビルドしてください（Higgsfieldでサインイン、ユーザーのHiggsfieldクレジットで生成）。ユーザーに「独自の画像/動画APIを持ち込む」オプションや、Webサイト用に独自の生成キーを設定するオプションを提供しないでください。そのようなパスは存在しません。--type website は、生成がなく、Higgsfieldやその他の生成サービスと一切結びつかないサイトのみに使用します。（Webサイトは、ユーザー自身のキーを使用して、通常の非生成サードパーティAPI（決済、地図、メールなど）を使用することはできます。これはこのルールとは無関係です。）
簡単な判断基準：「ランディングページ / ポートフォリオ / マーケティングサイト / 独自ユーザーを持つSaaS、AI生成なし」→ Webサイト。「画像/動画/音声を生成する、またはHiggsfieldモデル、クレジット、生成履歴を伴うもの」→ アプリ。「プレイするもの — ゲーム、マルチプレイヤーまたはシングルプレイヤー」→ ゲーム。
ゲームは廃止予定の別のエンジンからこのパイプラインに移行されました。higgsfield game … コマンドはなくなりました。ゲームはWebサイトとまったく同じように作成、デプロイ、公開されます。そうでないと書かれているドキュメントは古い情報です。
create時には常にサブドメインを設定する
higgsfield website create はオプションの --subdomain を受け付けます。これがサイトのスラッグとなり、ライブURLは <subdomain>.<host> になります。常に設定してください。 製品名や目的から1つ選びます。ユーザーが明示的にランダムなスラッグを希望する場合にのみ省略します（その場合はランダムなスラッグになります）。適切なサブドメインのルール：
- 4文字より長い — 短い単語は予約されているため、少し長めにしてください。
- 覚えやすい — 製品名や目的から派生させてください（例：
lumen-notes、pixelforge）。ランダムな文字列は避けてください。 - 許可文字のみ — 小文字、数字、および単一のハイフン（DNSセーフ）。スペース、アンダースコア、大文字、先頭/末尾のハイフンは不可。
いくつかの予約ラベル（例：api、www、app）や既に使用されているサブドメインは拒否されます。その場合は、類似のバリエーションを試してください。
前提条件
higgsfieldが$PATHにない場合、インストールします：curl -fsSL https://raw.githubusercontent.com/higgsfield-ai/cli/main/install.sh | shhiggsfield account statusがSession expired/Not authenticatedを報告する場合、ユーザーにhiggsfield auth login（対話型）を実行し、確認を待つように依頼してください。- リポジトリをクローンした後、
gitとbunがローカルで使用されます。CLI自体が create / repo / deploy / publish / status / db / secrets を処理し、アセット生成ジョブ（higgsfield generate …、higgsfield model …）も処理します。
パスを選択し、1つのフローを最後まで実行する
--typeを確定します（不明な場合はユーザーに質問します — ユーザーの選択です）。同じ最初の質問で、準備ができたときにHiggsfieldコミュニティフィード（マーケットプレイス）に公開するかどうかも尋ねてください（はい/いいえ）。答えを覚えておいてください：「はい」の場合は、最後に自動的に公開します（デプロイ + メタデータの後）。再度尋ねる必要はありません。「いいえ」の場合は、デプロイのみ行います。ビルドをこれでブロックしないでください。- 一致するフローを読み、それに従ってください。それがそのタイプの完全なワークフローであり、独自のリファレンス、ハードルール、編集マップ、デプロイ/公開ゲートを含みます。
--type website のすべてのビルドにおいて、インドは常にユーザーに、アニメーション付き（推奨） Webサイト（生成されたフィルムを通したスクロール駆動のジャーニー、references/scroll-scrub.md）とアニメーションなし Webサイトのどちらかを選択するよう求めます。この質問は必須です。リクエストが選択を暗示しているように見えても、絶対にスキップしないでください。アニメーション付きが推奨されるデフォルトです（ユーザーに連絡が取れない/応答がない場合にのみ使用されます）。以下のフローは両方のパスと完全なパイプラインを伝えます。
アニメーションパス内では、デフォルトはシングルショットフィルムです。つまり、継ぎ目のない、エンドツーエンドでスクラブされる、1本の連続した約15秒のテイクです。マルチシーンチェーンはオプトインであり、1レッグあたりさらに数分かかります。ブリーフが本当に異なる世界を行き来する場合にのみ採用してください。references/scroll-scrub.md がその判断を担当します。
| タイプ | フロー |
|---|---|
--type website | references/website-flow.md — 段階的パイプライン（デフォルトでアニメーションWebサイト）：イントーク → コンセプト → リファレンスボード → アセットシステム → ボードへのビルド → モーション → カバー + メタデータ → メカニカルゲート → デプロイ |
--type app | references/app-flow.md — Quantaツールキット、6つのコードレイアウト、fnf SDK + 認証 + D1契約、ローンチカバー + メタデータ、公開ゲート |
--type game | references/game-flow.md — 6関数の logic.js 契約、リアルタイムルーム、ゲームジャンル --category、プレイテスト、デプロイ + 公開 |
ゲームのアートとオーディオもここにあり、game- プレフィックスの下にあり、references/game-flow.md がそれらを索引付けしています：references/game-design-system.md（最初に読む — プロフィール、コアループ、アセットマニフェスト）、references/game-stylization.md（すべてのビジュアルが再利用するスタイル公式）、references/game-2d-animation.md、references/game-textures.md、references/game-3d-animation.md、references/game-procedural-animation.md、references/game-audio.md、references/game-meshy-api.md、references/game-meshy-input-rules.md。それらが駆動するGLB/リギング/テクスチャツールは、このスキルの scripts/ に含まれています。
3つのフローはすべて同じプラットフォームメカニズム（SSR Worker、app.manifest.json インフラ、higgsfield website deploy <website_id> による単一のライブデプロイ、以下のカバー + メタデータ要件、公開ゲート）を共有しています。各フローは必要なものを再記述しているため、他のフローを読む必要はありません。
カバー + メタデータ — 常にビルドの一部であり、公開時のみではない
すべてのビルド — Webサイトまたはアプリ、どんなに小さくても — には、ブランド化されたローンチカバーと入力済みのフィードカードメタデータが付属し、references/app-cover.md に従って生成され、app/src/app-meta.json（og_title、og_description、favicon_url、og_image_url、marketplace_cover_url）に書き込まれます。これはビルドステップであり、作業が完了したと提示される前、およびそれを出荷するデプロイの前に行われます。higgsfield website publish まで先延ばしにしてはいけません。ハードルール：
- 「シンプルなアプリ」の例外はありません。 ユーティリティツール、タイマー、1ページのおもちゃ — すべて生成されたカバーを取得します。手書きのインラインSVGファビコンはファビコンとして問題ありません。生成されたカバーの代わりにはなりません。
- カバー画像に許可は不要です — 実際のコピーを書くのと同じ方法で生成してください。オプションのカバービデオ（
og_video_url）のみ許可ゲートがあります（ビデオはクレジットを消費します — 提供することはできますが、促されずに生成してはいけません）。 - 空のカバーまたは空の
og_titleで完了したとして提示されたビルドは不完全です。それらなしでの公開は壊れた公開です（空のog_titleはフィード上で表示されず、空のカバーは空白のカードになります）。
UXルール
- 簡潔にしてください。チャット内で生のWebサイトID、トークン、JSONダンプを表示しないでください。デプロイ後は、ライブURL（
higgsfield website statusから）と1行のサマリーを返してください。 - スコープ付きgitトークンをユーザーに表示したり、コミットしたりしないでください。
- 最初のメッセージからユーザーの言語を検出し、その言語で返信してください。CLIフラグとコードは英語のままにしてください。
- すべてのデプロイはライブ公開サイトを即座に出荷します — プレビューステージはありません。コミュニティフィードへの公開/リストは別途行われ、ユーザーが明示的に公開/リストを要求した場合にのみ発生します。
設計に関するその他のガイダンスをスキルライブラリから検索しないでください。すべてこのスキルの下にあり、他のスキル（Webサイトやアプリの構築に関するユーザー/ローカルスキルを含む）がこれらのルールを上書きすることはありません。
ターン経済 — ビルドを少ないターン予算内に収める
ツールのラウンドトリップごとにエージェントのターンが消費され、エージェントのランタイムにはターン制限があります。長いビルドは途中で停止し、ユーザーに未完成のサイトを残すことになります。ターンをクレジットに次ぐ最も希少なリソースとして扱ってください：
- すべてのファイルを一度で、完全に書き込んでください。 完全なファイルを構成し、一度だけ書き込んでください。書き込み→修正ループは行わないでください。書き込んだばかりのファイルを再読み取りしないでください。
- ツールが許可するものはバッチ処理してください（複数ファイルの編集、一連のコマンドに対する1回のシェル呼び出しなど）。1ターンに1マイクロステップではなく。
- パスを推測しないでください — テンプレートツリーはリポジトリの
app/AGENTS.mdとこのスキルの編集マップに文書化されています。 - 自分で生成したものをダウンロードしたり、ビジョンで検査したりしないでください。 あなたがプロンプトを書きました。結果を再表示しても新しい情報は得られません。（キットの一貫性チェックは、該当する場合、1回のバッチパスです —
references/asset-system.md。） - ジョブの出力が次の入力になるときに、ジョブを1回だけ待機してください。 並行してレンダリングできるものはすべて送信し（フィルム + カバー）、その間にページをビルドしてください。
ユーザーとの対話 — 技術的/配管用語は使わない
ほとんどのユーザーは技術的ではありません。あなたがユーザーに伝える内容にビルドの配管をさらさないでください。gitリポジトリ、クローン、ブランチ、コミット、プッシュ、プル、またはデプロイパイプラインについてユーザー向けメッセージで言及しないでください。これらはあなたが実行する内部メカニズムです。ユーザーが気にする製品用語で話してください：
- 「サイトをセットアップしています…」 — 「リポジトリをクローンしています」/「プロジェクトをスキャフォールディングしています」ではありません。
- 「変更を保存しています…」/「サイトを更新しています…」 — 「コミットしています」/「プッシュしています」ではありません。
- 「プレビューの準備ができました：」 — 「ブランチをデプロイしました」/「ビルドが成功しました」ではありません。
- 「サイトを公開しています…」 — 「メインにマージしています」/「本番環境にプッシュしています」ではありません。
これはチャット内の単語についてのみです。舞台裏で実際のステップを実行し続けてください。ただし、それらを開発者用語で説明しないでください。（唯一の例外：明らかに技術的で、リポジトリ、ブランチ、またはデプロイメカニズムについて明示的に尋ねるユーザー — その場合は率直に答えてください。CLIフラグとコードは英語のままです。）
リファレンス索引（このバンドルに含まれるもの）
2つのフローファイルが必要に応じて残りを取り込みます。フローがそこに送らない限り、これらを直接読むことはありません。
両方のフロー： references/app-cover.md（ローンチカバー + OG画像）、references/runtime-and-infra.md（TanStackルート、SSR、Workerランタイム）、references/security.md（Workerハードニング、OWASP監査、脅威モデル）。
Webサイトフロー： references/design-recipe.md、references/wow-catalog.md、references/wow-maker.md、references/reference-boards.md、references/asset-system.md、references/image-to-code.md、references/design-taste-frontend.md、references/review-rubric.md、references/seo.md、references/scroll-scrub.md（A4シームロックジャーニー）、references/scroll-scrub-asset-react.md、references/scroll-scrub-asset-css.md、references/scroll-scrub-asset-video.md（A4が選択された場合にのみロードされるバンドル済みMarkdownコードアセット）。
アプリフロー： references/app-quickstart.md（ここから開始 — 動作するクリティカルパス：認証、生成送信/ポーリング、結果レンダリング、一般的なQuantaコンポーネント）、references/quanta-design.md、references/app-layouts.md、references/fnf-sdk.md、references/fnf-react.md、references/auth.md、references/containers.md、references/cover-animator.md（許可ゲート付きの約5秒のカバービデオ → og_video_url）、references/contest.md（10万ドルのアプリコンテスト — エントリーはアプリを自動公開します。ソーシャルリンクとともに送信してください）。