mcpField
S
scenario-thumbnails

scenario-thumbnails

github.com/scenario-labsクリエイティブ・メディア1.2k162 回インストール1 日前に更新
リポジトリ

scenario-thumbnails について

scenario-thumbnailsは、指定サイズのカバー画像を作るスキルです。ゲームや動画、ストア素材を扱うエージェント向けで、依頼に沿った構図、正確なコピーと参照画像の人物・キャラクターの維持、小サイズでの確認を重視します。

主な機能

  1. 01依頼に沿ったサムネイル構図
  2. 02指定コピーとサイズの遵守
  3. 03承認済みの人物・キャラクター維持
  4. 04参照画像に基づく画像生成
  5. 05縮小プレビューでの可読性確認

活用シーン

  1. 01ゲームのボス登場カバー作成
  2. 02提示されたゲームメカニクスの説明
  3. 03ストア用カプセル画像の準備
  4. 04開発者動画のカバー作成

MCP 対応

Scenario MCP サーバーのワークフローで画像生成や関連アセットを扱います。画像仕様、テキストオーバーレイ、フォーマット、一貫性には関連スキルも利用します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/scenario-labs/skills --skill scenario-thumbnails

インストール後、Claude Code で/scenario-thumbnailsを入力して読み込まれたか確認します。

詳細

シナリオサムネイル

概要

視聴者が実際に目にするサイズで、題材が伝わるカバーを作成します。納品物は、指定された寸法で仕上げた画像であり、提示された文言を正確に含み、人物やロゴなどのアイデンティティを保つ必要があります。接続と生成ループには scenario を使用し、画像と参照の仕様には scenario-image を使用します。正確な文字表現には scenario-text-overlay を、配置の指定には scenario-formats を、統一感のあるセットには scenario-consistency を使用します。ここに記載された関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください(npx skills add scenario-labs/skills --skill <name>)。無人実行の場合は、ツールのスキーマに基づいて進め、不足している点を明示してください。

依頼内容から、納品先、題材またはタイトル、提供された素材、正確な文言、希望枚数、予算を確認します。結果に影響する判断が不足している場合に限り、質問してください。画像をドラマチックにするために、人物、ロゴ、証言、ゲームの機能を創作してはいけません。承認済みのキャラクター参照と、スタイルの参考例を区別してください。後者は、人物やブランドを差し替えてよいという許可ではありません。

クイックリファレンス

概要有効な構図生成前の確認事項
ボスまたは遭遇の公開脅威がひと目で分かり、動作が一つ読み取れる構図シルエット、スケールの関係、承認済みのキャラクターのアイデンティティ
メカニクスの説明一つの明確な動作とその結果描写するメカニクスが提供された資料に実在すること
パッチまたはワールドの更新新機能を主役にする構図リリース済みか提案段階か、および提供された事実
進行または報酬状態間の違いが目に見えること状態のラベルと報酬に関する主張に根拠があること
クリエイター主導の開発記録提供された話者と関連するゲームの題材誰が登場するか、その参照資料、実際の題材
ストア用カプセル画像配信先に合わせた構図scenario-formats を適用すること。動画カバーのデフォルト設定はストアのルールには適用されません

すべてのゲームに大きな顔、フォトリアリズム、誇張したリアクションを無理に当てはめず、依頼内容に合わせて構図を選んでください。方向性が定まっていない場合は、費用をかける前に意味のある違いがあるコンセプトをいくつか提案してください。無人実行の場合は、提供された依頼内容に最も裏付けられたコンセプトを選び、その前提を記録し、承認された枚数と上限の範囲内で進めてください。必須情報または支出の承認が不足している場合は、生成せずにその妨げとなっている点を伝えてください。ユーザーがコンセプトを選んだ場合は、それを実行してください。バリエーションの正確な枚数を守ってください。1枚のカバーを、依頼されていない複数枚の制作に変えてはいけません。

概要からプロンプトへ

見る人が何を認識または学べるのか、ビジュアルで伝える内容を一文で定義します。主役を一つ決め、それを引き立てる動きと、指定されたコピーを配置するための余白を設けます。装飾を並べるのではなく、縮小しても伝わる階層を選びます。分割画像が役立つのは、見た目で比較することが概要の目的である場合に限られます。被写体が二つあるからといって、自動的に分割レイアウトにする必要はありません。

コピー領域の大きさは、デフォルトでフレームの半分を確保するのではなく、実際の文言に合わせます。縮小プレビューで、コンパクトな改行と被写体のサイズを比較します。大きすぎる空白のパネルや小さすぎる主役のキャラクターは、後から編集できる表紙の魅力を損なう可能性があります。告知する変更内容が、そのサイズでも伝わることを確認します。

被写体、動き、構図、配色、表現手法、光を具体的に説明します。それぞれの参照画像の役割と、固定する必要のある特徴を明記します。プロバイダー固有のフィールドは、共通テンプレートに含めず、model_schema_get で確認したペイロード内に記述します。機能やユーザーのニーズには recommend を、ユーザーが指定したモデルには search を使います。生成モデルのバージョンや品質ティアをハードコードしないでください。

目標サイズとコピーは必ず守る条件です。対応している比率とサイズで生成し、正確な書き出しサイズに対応できない場合は、文書化されたリサイズ手順を使います。指定された数値に合わせるために、キャラクターを黙って切り抜いたり、画像を引き伸ばしたりしないでください。提供されたロゴやテキストは、正確に配置できる手順を用意します。文言を完全に一致させる必要がある場合は、まず文字のないベース画像を作り、続いて scenario-text-overlay を使うことを推奨します。ユーザーが文字を画像に生成するよう明示的に求めている場合は、一文字ずつ確認し、必要に応じて対応済みの編集・オーバーレイ手順で修正します。コピーが提供されていない場合、見出しを勝手に追加してはいけません。

作業例:ボス戦の開発ログ用カバー画像

ユーザーは、承認済みの苔むした石のボスの参照画像を提供し、1280x720のイラスト入りYouTubeサムネイルを1点と、見出し「ONE HIT LEFT」を正確に入れるよう依頼しています。ボスには腕が2本、琥珀色の目が1つあり、口はありません。選択した構図は、右側にボス、下部に小さな盾を持ったプレイヤー、左側にコピーを配置したものです。承認済みの上限は、1回の生成と範囲を限定した修正を対象としています。

  1. 参照画像を確認し、同一性を保つための要件を記録します。まだアセットになっていない場合は、scenarioを使ってアップロードします。承認済みのイラストスタイルを維持し、写真の人物に置き換えないでください。
  2. この依頼内容でtxt2imgのrecommendを実行します。これはキャラクター参照を使った新しい構図であり、参照画像のレイアウトを再スタイル化するものではありません。参照画像を受け取れる適切な候補のmodel_schema_getを読みます。ペイロードを選択する前に、対応アスペクト比、参照画像数/多重度、プロンプトの上限、サイズを確認します。参照画像はスキーマで指定された実際のフィールドに渡し、必要に応じてスカラーまたは配列を使います。元画像/強度を指定する編集仕様だと決めつけないでください。既存の構図を編集または再スタイル化する場合は、img2imgを使います。
  3. 承認済みのボスとアクションを、左側に明確なコピー領域を設けてプロンプトで指定します。画像には文字や重複したボスを入れません。dry_run: trueを指定してmodel_runでペイロードの料金を確認し、上限内で送信して、既存のジョブIDをjobs_waitで待ちます。
  4. 文字を追加する前に、ボスの参照画像と照らし合わせて結果を確認します。目の数やシルエットが変わっている場合は、対象を絞って修正する必要があります。文字を追加しても同一性の問題は解決しません。適切であれば、採用した画像を編集に使い、コンセプトを最初から作り直すのではなく、承認済みの特徴を維持します。
  5. 提供された見出しを、scenario-text-overlayで透明PNGカードとしてレンダリングし、model_scenario-compose-imageで画像に重ねます。このIDはScenarioで単一の決定論的な画像合成ツールを指すため、検出するのではなく固定で使用します。このツールが受け取るのは画像レイヤーのみなので、テキストがモデルを通ることはありません。ブラウザーのプレビューだけでなく、完成画像を確認します。scenario-image/scenario-formatsを使って正確な出力サイズにし、返された寸法を読み取ります。
  6. 1280x720と、幅約120ピクセルのプレビューで確認します。小さなプレビューは負荷テストであり、あらゆるプラットフォームに共通する基準ではありません。ボスと盾が判別できること、見出しが読みやすいこと、コピーやトリミングで特徴的な目が隠れていないことを確認します。実際に縮小した画像を確認してください。高解像度を指定するだけでは、このテストにはなりません。
  7. 検証済みの最終画像をasset_displayとasset_downloadで納品します。コピーを変更したときにアートを再利用できるよう、文字なしの画像、正確なテキスト、フォント/レイアウト設定、ソース/出力の識別子を保持します。未解決の不具合があれば、失敗したバリエーションを完了扱いにせず、その旨を伝えます。

レビュー、修正、よくある間違い

複数の出力を作成する場合は、各コンセプトやバリエーションに安定したラベルを付け、ソースの役割、ペイロード、ジョブID、QA結果を保持します。保留中の出力は再送信せず、完了を待ちます。失敗した出力だけを、残りの上限内で再試行します。修正時は、ユーザーの指摘を構図、同一性、コピー、または書き出しに分類します。採用済みのレイヤーを再利用し、依頼された部分だけを変更します。通常、新しい見出しに必要なのは新しいオーバーレイであり、画像の再生成ではありません。

  • スタイルの参考画像をキャラクターの参照元として扱うと、許可なく同一性が入れ替わります。
  • 大きく鮮明な画像でも、フィード上のサイズでは情報の優先順位が読み取りにくいことがあります。
  • コピーが長い場合はレイアウトを検討する必要があります。自動的に切り詰めたり、文言を変更したりしてはいけません。
  • ロゴは保持すべきアセットであり、モデルに綴らせるための単語ではありません。
  • 提供されていない装飾的なUI、報酬、ゲームメカニクスを加えると、ゲームの内容を誤って伝えることになります。
  • 読みやすさと参照画像への忠実さは観察できますが、サムネイルのレビューだけではクリック率の改善は立証されません。

コメント