アニメーションステッカーメーカー

アニメーションステッカーメーカー は何をしますか？

1枚の参照画像と1つのモーションプロンプトから、短い透明アニメーションステッカーを生成します。アイデンティティロック、モーションプラン、フレームタイミング、バリデーション計画、エクスポート設定は内部で導出し、ユーザーに定型的な制作選択を求めません。

すべてのスクリプトおよび参照パスは、このSKILL.mdが配置されているディレクトリを基準として解決します。

入力と境界

以下のみを必要とします：

1. reference_image：明確な主要被写体を含む1枚の静止画像。
2. prompt：意図する表情、動作、テキスト、ループ、ターゲットプラットフォームを説明する自然言語。

人物、ペット、マスコット、イラスト、オブジェクト、ロゴに対応します。画像に複数の plausible な被写体が含まれ、プロンプトで特定されていない場合は、生成前に1回だけ質問します。複数被写体の安定した演技、シーンアニメーション、カメラモーションは保証しません。

1回の呼び出しで1つのステッカーを生成します。複数ステッカーシリーズの場合は、共有のアイデンティティ仕様、パックの順序、リリース名、ブランドアセットを所有プロジェクトに保持し、このスキルをステッカーごとに個別に呼び出します。プロジェクト固有のパックオーケストレーションを汎用スキル機能に変換しないでください。

これは、標準をサポートするホスト向けの1つのAgent Skillsパッケージです。ホスト固有の2つ目の命令フォーマットは維持しないでください。ホストは、被写体のアイデンティティを保持できる、参照条件付きラスター生成または編集機能を提供する必要があります。ホストネイティブの機能を使用し、利用できない場合は、生成前に明確な機能エラーメッセージを表示して失敗します。agents/openai.yamlはオプションのOpenAI UIと起動メタデータであり、ワークフロー契約の一部ではありません。

決定論的処理にはPython 3.10以降とrequirements.txtのパッケージを使用します。OpenCVを必須依存関係にしないでください。

デフォルト出力

プロンプトで明示的に上書きされない限り、以下の構造を作成します：

output/<name>/
├── sticker.webp
├── source/
│   ├── frames/
│   │   ├── 000.png
│   │   └── ...
│   ├── rendered-frames/      # オプションのバリデーション済み高フレームトラック
│   ├── reference.json        # ベース名、ハッシュ、画像メタデータ
│   └── motion.json
├── validation/
│   ├── contact-sheet.png
│   └── report.json
└── exports/                  # プラットフォームまたは追加フォーマットが要求された場合のみ
    └── <platform>/

ユーザーが別のローカル出力先を指定しない限り、ワークスペースローカルのoutput/<name>/を使用します。<name>は、被写体と主要な意味的ビートから、ファイルシステムに安全な短いスラッグとして導出します。すでに存在する場合は-2、-3などを使用し、デフォルトでは既存のパッケージを上書きしません。ユーザーが明示的なリリース名または公開名を指定した場合は、それを尊重します。

連続階調、イラスト、または生成されたラスターソースには1024×1024 RGBAを使用します。ネイティブのピクセルアートやその他の厳密な低解像度グリッドの場合は、論理ソースキャンバスを保持し、motion.resamplingをnearestに設定します。非整数の1024×1024再描画を強制しないでください。4～8ユニークフレーム、フレームごとの持続時間、合計約1.2～2.0秒の長さ、最も明確な意味的フレームに400～700msのホールドを使用します。デフォルトでループします。ターゲットプラットフォームで要求または必要とされない限り、preview.gifを作成しないでください。

ワークフロー

1. リクエストの正規化

• 1枚の参照画像と1つのモーションプロンプトが利用可能であることを確認します。主要被写体、1つの意味的ビート、正確なテキスト、ループ意図、および指定されたターゲットプラットフォームを抽出します。
• 被写体が曖昧な場合は、1回質問します。参照画像、プロンプト、または必要なホスト機能がない場合は、生成を開始する前に明確なブロッカーを表示して停止します。
• プラットフォームが指定されていない場合は、プラットフォームニュートラルなパッケージを生成します。指定されたプラットフォームは、パッケージがバリデーションに合格した後のオプションのエクスポートブランチです。
• ファイルを作成する前に、上記の衝突ルールを使用して出力スラッグを選択します。

2. アイデンティティのロックとモーションの計画

references/motion-plan.mdを読んでください。参照画像をフルサイズおよび小アイコンサイズで検査し、認識可能な特徴を固定、柔軟、または削除可能に分類し、最終フレームを生成する前にmotion.jsonを書き出します。

1つの主要な意味的ビート、少数のアンカーポーズ、決定論的遷移、正確なテキストレイヤー、フレーム持続時間、およびループ動作にコミットします。決定論的変換で安全に取得できないものだけを生成します。motion.resamplingは意図的に選択します：連続階調またはイラストのラスター作品にはlanczos、ネイティブのピクセルアートまたはその他の厳密な論理グリッドにはnearest。

この段階は、アイデンティティロックが明示的であり、要求された各意味的要素に計画されたフレームまたは決定論的レイヤーがある場合にのみ完了します。

3. アンカーとクリーンなRGBAアセットの生成

生成する前に、ホストのラスター生成または編集手順を読んでください。新しいアンカーを要求するときは常に元の参照画像を含め、透明背景またはフラットな高距離作業色上の孤立した被写体を要求し、必要最小限のアンカーのみを生成します。

すべてのアンカーを直ちにアイデンティティロックと照合します。一時フレームを構築する前にアイデンティティのズレを拒否します。拒否されたフルアンカーに使用可能なローカル表情や小道具が含まれている場合は、承認されたアイデンティティ安定ベースにのみそれを流用します。コンポーネントのソース、抽出ルール、および承認ベースをモーションプランに記録します。拒否されたフル画像を承認済みとして再ラベル付けしないでください。

既存のクリーンなアルファを保持します。それ以外の場合はreferences/transparency.mdを読み、被写体パレットから遠く離れた作業色を選択し、scripts/chroma_key.pyを実行します。プロンプトまたはプラットフォームで独立したシャドウ制御が必要な場合は、シャドウを個別に保持します。

この段階は、すべてのフルフレームアンカーが使用可能であり、すべての流用コンポーネントに境界のある決定論的役割があり、各アセットに不透明な背景、カラースピル、明るいフリンジ、クリップされた突出部、またはキャンバスエッジとの接触がない場合にのみ完了します。

4. オーサリングアニメーションの合成

オーサリングされたユニークフレームごとに1つのRGBA PNGを作成します。要求されたモーションが変形を伴わない限り、アスペクト比を保持します。正確なテキストを決定論的レイヤーでレンダリングし、各フレームに1つの目的を与えます。均等にタイミング調整されたモーションよりも、予備動作、アクション、1つの明確な意味的ホールド、および短い回復を優先します。

コンパニオンオブジェクトが被写体を押す、座る、運ぶ、または触れる場合は、そのフットプリント下のローカルシルエットに合わせて調整します。表面が湾曲、ノッチ、または変形している場合、被写体のグローバルバウンディングボックスエッジを接触面として使用しないでください。

この段階は、シーケンスがファイル名や説明なしで読み取れ、ループに意図しないジャンプ、フラッシュ、または位置リセットがない場合にのみ完了します。

5. パッケージ化と技術的バリデーションの実行

以下を実行します：

python <skill-dir>/scripts/package_sticker.py \
  --frames-dir <working-frames> \
  --motion <motion.json> \
  --reference-image <reference-image> \
  --output <output/name>

ソースキャンバスが1024x1024と異なる場合は--expected-size <WIDTHxHEIGHT>を渡します。--include-referenceは、ユーザーが元の画像の埋め込みを希望する場合のみ使用します。それ以外の場合は、ベース名、ハッシュ、寸法、モード、フォーマット、バイトサイズをコピーせずにバインドします。非標準のタイミングまたはフレームカウントフラグは、プロンプトがデフォルトを明示的に上書きする場合のみ使用します。技術的バリデーションに失敗した場合、プラットフォームエクスポートに進まないでください。

レポート契約と決定論的チェックについてはreferences/validation.mdを読んでください。パッケージをトランザクションに保ち、パッケージ化されたsource/motion.jsonを自己完結型の真実のソースとして扱い、アーティファクトフィンガープリントを保持し、technical_validationをvisual_validationから分離して保ちます。

motion.renderが存在する場合、その明示的な順序付きフレームをオプションの個別にバリデーションされたレンダートラックとして扱います。オーサリングされたキーフレームをデフォルトとして保持し、決してレンダートラックを静かに作成または選択しないでください。そのタイミング、リソース、およびエクスポートルールについては、モーションおよびプラットフォームのリファレンスを読んでください。

この段階は、WebP、正規化されたソース、参照メタデータ、モーションプラン、コンタクトシート、主要技術レポート、および該当するすべてのレンダートラックレポートが存在し、該当するすべての技術チェックに合格した場合にのみ完了します。

再パッケージ化が成功するたびに、新しいレポートが作成され、ビジュアルバリデーションは保留中となります。アーティファクトが変更された後は、以前のビジュアル合格を保持しないでください。変更されたアーティファクト間で以前のビジュアルパスを決して保持しないでください。

6. 検査、記録、およびオプションのエクスポート

references/validation.mdとreferences/review-page.mdを読んでください。検査または共有の直前に、新しいレビューページを生成します：

python <skill-dir>/scripts/generate_review.py <validation-report.json> \
  --reference-image <original-reference-image> \
  --language <en|zh>

パッケージにバインドされた参照が含まれている場合は--reference-imageを省略します。中国語での会話の場合はzhを選択し、それ以外の場合はenを選択します。実際のエンコードされたレビュー対象、意味的ホールドマーカー、チェッカー/明/暗背景上のアルファ、実寸および50倍ズームビュー、フレーム露出シートを検査します。オーサリングフレームまたはレンダーフレームは比較証拠です。デコードされたWebP/GIFがパッケージまたはエクスポートページを制御します。

scripts/record_visual_validation.pyで結果を記録します。レポートはその正確なアーティファクトフィンガープリントを保持する必要があり、deliverable_readyは技術的バリデーションとビジュアルバリデーションの両方に合格した場合にのみtrueとなります。最終ステータスを共有レビューページに表示する必要がある場合は、記録後にページを再生成します。レビューページは使い捨ての派生HTMLであり、証拠や納品物ではありません。

プラットフォームが要求された場合は、references/platform-exports.mdを読み、現在の公式制約を確認し、バリデーション済みパッケージからexports/<platform>/の下にのみエクスポートします。デフォルトでオーサリングキーフレームを使用します。宣言されたレンダートラックは、要求された出力を実質的に改善する場合にのみ明示的に選択します。要求された各エクスポートには、独自の技術的およびビジュアルバリデーションが必要です。

納品前に、納品される正確なパッケージ、レンダートラック、およびエクスポートレポートに対してscripts/doctor.pyを実行します。Doctorは読み取り専用です。該当するビジュアルバリデーションが保留中の間はincompleteが想定されます。ターゲット選択とJSON出力についてはreferences/doctor.mdを読んでください。

決定とリカバリのルール

• ルーチンのタイミング、位置、スケール、作業色しきい値、圧縮、出力スラッグの詳細は、ユーザーに中断することなく決定します。
• 安全で可逆的な問題による技術的またはビジュアル障害は、その安全な調整のみを使用して、1回の集中的な自動修正パスを受けることができます。再パッケージ化し、レビューページを再生成し、再検査します。再パッケージ化ごとにビジュアルバリデーションがリセットされます。
• 修正がまだ失敗する場合、または修正がアイデンティティ、意味、アンカー生成、または明示的な公開出力を変更する場合は、停止してユーザーに質問します。失敗した技術ゲートをビジュアル判断で上書きしないでください。
• ユーザーが参加する場合は、新しいレビューページを共有し、会話でフィードバックを収集します。ユーザーがPythonを実行したり、フォームを送信したりする必要はありません。

納品ハンドオフ

現在の会話言語を使用し、常に以下のフィールドを報告します：

• status：ready、incomplete、またはblocked。
• パッケージパスと一次バリデーションレポートパス。
• レンダートラックレポートパス（存在する場合）。
• レビューページパス（生成された場合）。
• 要求された各エクスポートとそのレポートパス。
• 納品された各正確なレポートに対するDoctor結果。
• 未解決の注意点、保留中のビジュアルチェック、外部参照要件、またはプラットフォーム固有の制限。

その正確なレポートにtechnical_validation、visual_validation、およびdeliverable_ready: trueが含まれており、Doctorが納品された境界に対してhealthyを報告するまで、アーティファクトを準備完了と呼んではなりません。Review HTMLをパッケージアーティファクト、バリデーション証拠、または納品物として提示しないでください。

エスカレーションルール

欠落した選択が意図された被写体、要求された意味、または不可逆的な公開出力を変更する場合にのみ、ユーザーに質問します。曖昧な主要被写体については1回質問します。必要な入力またはホスト機能が利用できない場合は、明確に停止します。安全なプロジェクトレベルの調整は、上記の境界リカバリルール内で自動的に行います。