krea-build

Krea Build — 開発者向け統合パターン

このスキルは、Krea を統合するアプリを構築するためのものです。単発の生成向けではありません。それは兄弟スキルの krea-generate です。こちらは利用可能な Krea のサーフェス（認証済み CLI または接続済み MCP ツール）を使用します。

このスキルは、ユーザーが次のような場合に使用します:

• Krea API を直接呼び出す TypeScript/Python/Go クライアントを作成している
• ユーザーがコンテンツを生成できるフロントエンドを構築している（SvelteKit、Next.js など）
• CI または本番環境で実行されるコンテンツパイプラインを設計している
• Krea の出力をポートフォリオ、ドキュメント、ツールに埋め込んでいる

自己更新チェック（オプトイン）

セッションごとに 1 回、兄弟ディレクトリ ../../krea-generate/scripts/update-check.sh が存在する場合はそれを実行します。新しいバージョンがリリースされている場合は UPGRADE_AVAILABLE <local> <remote> を出力します。それをユーザーに一度通知してから続行します。スヌーズは 24h→48h→7d です。無効にするには touch ~/.krea-skills/update-check-disabled を実行します。

このスキルと兄弟スキルの使い分け

状況	使用するもの
「X の画像を生成して」	krea-generate
「Krea を使うムードボードアプリを構築して」	krea-build（これ）
「Krea を呼び出す TypeScript ヘルパーを書いて」	krea-build
「単発のパイプラインを今すぐ実行して」	krea-generate
「React フォームに Krea 生成を追加して」	krea-build
「ショットリストと Krea 動画ジョブを中心としたアニメーション制作 UI を構築して」	krea-build、クリエイティブワークフローの契約として krea-animation を使用
「商品広告と Meta アクティベーション用のプロデューサーダッシュボードを構築して」	krea-build、ワークフローの契約として krea-marketing を使用

重要なワークフロールール: チャットでプロトタイプし、アプリで製品化する

Krea アプリを構築する際の単一の最も高くつく間違いは、実証されていない生成出力を前提にアプリコードを書いてしまうことです。常に次のようにします:

1. プロトタイプ — 利用可能な Krea のサーフェスを使って krea-generate または krea-marketing で生成を手動実行し、実際の出力がどのようになるかを確認します。
2. 確認 — 結果をユーザーに提示します。プロンプト、モデル、パラメーターが適切になるまで反復します。
3. 製品化 — 出力が承認されたら、URL とパラメーターをアプリにハードコードします。

ステップ 1〜2 を飛ばして、プレースホルダーのプロンプトを使った SvelteKit ページをいきなり書き始めると、生成が失敗したり予期しない結果を返したときにアプリが壊れて見えます。チャットでの検証は数秒で済みますが、壊れたアプリのデバッグには数分かかります。

完全なワークフローについては references/integration-patterns.md を参照してください。

アーキテクチャの推奨: サーバーサイドのみ

Krea API キーは決してブラウザに露出させてはいけません。すべての Krea 呼び出しはサーバーを経由します:

• SvelteKit: +page.server.ts、+server.ts、または +page.server.ts の actions
• Next.js: API ルート（app/api/*/route.ts）、サーバーアクション、または getServerSideProps
• Express/Hono/Fastify: 標準的なサーバールート

クライアントはサーバーにリクエストを送ることで生成をトリガーし、サーバーが Krea を呼び出し、完了するまでポーリングし、結果をストリーミングで返します。

認証、ポーリング、エラー

この 3 つはすべて references/api-client.md にあり、再利用可能な TypeScript と Python のスニペットが含まれています。主要な形は次のとおりです:

• 認証: Authorization: Bearer ${KREA_API_KEY} ヘッダー。
• 送信: POST /generate/image/<model-id> に { prompt, ... } を付けて送信 -> { job_id } を返します。
• ポーリング: GET /jobs/<job_id> を 3〜10 秒ごとに、status が終了状態になるまで実行します。
• エラー: 完全な表については references/validation.md を参照してください。

フロントエンド統合

一般的なパターンを処理する、そのまま貼り付けられる TypeScript については references/frontend-snippets.md を参照してください:

• 進行状況 UI 付きの生成フォーム
• クリックで拡大できる画像プレビュー
• 状態を持つ複数画像ギャラリー
• ローディング状態付きの動画プレーヤー
• ハードコードされたアセット配列（「製品化」ステップ）

バリデーションの規律

ユーザーが指定したプロンプト、画像 URL、パラメーター値は、Krea に転送する前にサーバーサイドで検証する必要があります。バリデーションチェックリストとコンテンツモデレーションの扱いについては references/validation.md を参照してください。

リファレンスドキュメント

• references/integration-patterns.md — プロトタイプ→製品化のワークフロー、アプリの構成、チャットファーストにすべきタイミング
• references/api-client.md — 認証、ポーリング、リトライ、エラーハンドリング（TS + Python）
• references/validation.md — 入力チェック、コンテンツモデレーション、よくある API エラー
• references/frontend-snippets.md — SvelteKit/React/Vue 向けのコピー&ペースト可能な TS

クイックスタート

ユーザーがまったく新しいアプリを作り始めていて、「Krea をどう統合すればいいですか」と尋ねてきた場合:

1. references/api-client.md を読んで、認証+ポーリングの形を把握します。
2. references/frontend-snippets.md にある TypeScript ヘルパーを src/lib/krea/index.ts（またはプロジェクトに合う任意の場所）に配置します。
3. そのヘルパーを呼び出すサーバールートを構築します。
4. そのサーバールートにアクセスするクライアントコンポーネントを構築します。
5. ユーザー向けの生成ごとに、まず krea-generate または krea-marketing を使ってチャット内でプロンプトをプロトタイプし、その後、承認されたバージョンをハードコードします。