Communityコーディング&開発github.com

atakoylan125-sketch/AI-Filmmaking-Skills

ManimGX を使用したトップダウン・ステージング:シーン内のすべての位置を計画し、アニメーション化されたフロアプランマップとしてレンダリングします。

AI-Filmmaking-Skills とは?

このAIスキルは、映像制作におけるステージング(配置・動線設計)を専門に支援します。ユーザーがプロのショットリストから一文の簡単な指示までどのような形でシーンを入力しても、それを元にキャラクター、カメラ、光源の位置関係をトップダウンのアニメーションマップとして可視化します。特に「180度軸」や「スクリーン方向」の整合性を自動的にチェックし、覆い焼きやミラーリングといった撮影上の問題を検出・報告します。ワークフローは、ユーザーからの情報が不足している場合に最大2往復の選択式質問で補い、レイアウト案をユーザーが確認・修正した後にのみレンダリングを実行するため、意思決定の透明性が高いのが特徴です。出力はMP4動画と編集可能なJSONシーンスペックの2点で、Python CLI経由でスタンドアロンに動作します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/atakoylan125-sketch/AI-Filmmaking-Skills/tree/HEAD/skills/staging-with-manimgx

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

ManimGX によるステージング

配置のみ。このスキルはストーリー、台詞、演技を作成しません。また、特定のカメラシステム、動画生成ツール、制作ツールに依存しません。一つの問いに答えます:すべての物体と人物はどこにあり、どのように動き、光はどこから来て、各カメラはどこに立ち、どこを見るのか? 出力は短い動画で、監督のフロアプランのスタイルをとります。完成したマップが1秒表示され、次にマップが構築され、移動経路、カメラが視野角コーンとともに一つずつ現れ、最後に180度軸とアイラインが表示されます。

ユーザーは、完全なショットリストを持つプロフェッショナルである場合も、一言だけの初心者である場合もあります。どちらも最終的には同じ品質のマップを生成します。違いはそこに至るまでの道筋です。完全なブリーフは直接提案レイアウトへ進みます。不十分なブリーフは最初に短いガイド付きの情報収集ラウンドを経るため、スキルが推測するのではなくユーザー自身が配置を決定できます。質問は初心者にステージングのブリーフに必要な要素を教える役割も果たします。すべての道は、レンダリング前にユーザーが承認または修正する計画で終わります。

ステージングの技術(ショットサイズ、カメラ高さ、レンズの感覚、配置ルール、空間的一貫性、各ショットの説明方法)は references/staging-craft.md にあります。カメラの選択、計画の作成、最終確認の前にこれを読んでください。

現在のシーンのみを対象に作業してください。以下の質問テンプレート、サイズ表、スペック例は形状と構文を示すものであり、内容を示すものではありません。実際のシーンにそれらの場所、小道具、名前、位置、色を流用しないでください。

完全なブリーフ — 7つのスロット

ブリーフは以下の7つに答えた時点で完全と見なします。他の作業を行う前に、受け取ったすべてのブリーフをこれらと照合してください。

#スロット特定するものマップに必要な理由
1場所場所の種類、規模、性格(小さいか大きいか、狭いか開けているか、スタイルや時代)とその固定された形状:壁、ドア、窓、ブロッキングに重要なオブジェクトマップ全体の縮尺と存在する小道具を設定する
2位置誰がどこにいるか、姿勢(立っている、座っている、横たわっている、ひざまずいている…)、誰が誰の方を向いているか、距離ドット、姿勢タグ、方向矢印。ここから180度軸が描かれる
3方向キャラクターにとっての主要な特徴(窓、ドア、壁、道路)の方向を、キャラクター基準で明示:「窓は彼女の右側」これがないとマップが反転して表示され、すべての背景が間違ってしまう可能性がある
4照明重要な光源の数、物理的な位置、光が来る方向、ハードかソフトか各顔のどちら側が照らされるか、どのショットが逆光になるかを決定する
5周囲アクションの反対側にあるものすべてのリバースショットの背景になる
6ショットショットの数、順序、サイズ、レンズ、アングル(Aのクローズアップ、中央のツーショット、Aの肩越しにB…)これらがカメラになる
7ビート誰が、どこからどこへ、いつ動くか(立ち上がる、交差する、入る、出る、向きを変える)、各ショットで何が起こるか移動は位置、向き、時にはシーンの途中で軸を変える。移動はパスとして描画される

スロットは、ブリーフがそれを明示しているか、曖昧さがない場合(「彼らはボックス席の向かいに座っている」は位置スロットを満たす)に「埋まっている」とカウントされます。スロット7は誰かが動く場合にのみ重要です。すべてのビートが台詞で誰も動かない場合は、質問の必要はありません。

情報収集ラウンド — ブリーフが不十分な場合

  1. ブリーフを7つのスロットで採点します。ただし、このチェックリスト自体をユーザーに見せてはいけません。
  2. すべて埋まっている場合は情報収集をスキップし、ワークフローに進みます。ユーザーが「質問しないで」(「sorma」「direkt yap」「just do it」)と明示した場合もスキップします。その場合は不足部分をデフォルト値で補います。デフォルト値は計画にリストアップされます(ワークフローステップ4)。
  3. 不足がある場合は、ユーザーの言語で質問します。
    • 1メッセージあたり最大3問、最大2往復まで。 順序:場所 → 位置 → ショットが先(マップの構造を決めるため)、次に方向 → 照明 → 周囲、ビートは最後。
    • 場所と位置の両方が不足している場合、最初のメッセージではこれら2つだけを質問します。他のすべての質問の選択肢はこれらの回答に依存するためです。
    • すべての質問は選択式とし、このシーン用に作成した2~4個の選択肢と、最後に「あなたが決めてください」オプション(ユーザーの言語で、例:「Sen öner」)を用意します。ユーザーは常に独自の答えを入力することもできます。
    • あなたが選ぶであろう選択肢には「(推奨)」とマークし、理由を一言添えて初心者がそのまま選べるようにします。
    • すべての質問に、なぜその情報がマップに重要なのか、一行で説明します。
    • 環境に構造化された選択式質問ツールがある場合はそれを使い、なければ番号付きで選択肢をアルファベットで示した平文で質問します。
    • ブリーフが既に答えていることを質問してはいけません。ストーリー、台詞、演技について質問してはいけません。それはこのスキルの役割ではありません。
    • ユーザーがプロフェッショナルらしく(レンズ、ショットサイズ、「Aの肩越しにB」、軸)記述した場合は、明示された選択をそのまま受け入れます。本当に不足しているスロットについてのみ質問し、彼らが下した決定を再び問いただしてはいけません。
  4. 回答後も、未決定のままか「あなたが決めてください」と答えたスロットには、適切なデフォルト値を設定します。その後ワークフローに進みます。ステップ4の計画で、ユーザーがこれらのデフォルト値を確認または修正します。

質問テンプレート

各質問の形状を示します。実際のシーンに合わせて文言と選択肢を書き換えてください。そのまま貼り付けないでください。

  • 場所 — 「これはどこで起こりますか?そしてその場所はどのような感じですか?」 → ブリーフから作成した選択肢、例:小さくて窮屈な室内・広くて開けた室内・屋外・あなたが決めてください。理由:マップの縮尺と存在する小道具を設定します。
  • 位置 — 「彼らはどのように配置されていますか?」 → 場所と人物に合った選択肢で、位置と姿勢を組み合わせます(両方座って向かい合っている・並んでいる・一人座って一人立っている・あなたが決めてください)。理由:180度軸は主要な2人のキャラクターの間に引かれます。
  • 方向 — 「のどの側に<窓/ドア/壁>がありますか?」 → の左・の右・の後ろ・の後ろ。理由:これがないとマップが反転して表示され、すべての背景が変わります。
  • 照明 — 「主な光源はどこから来ますか?」 → この場所に存在する光源(<窓/ドア>側から・天井の照明から・シーン内の実用的な光源から・そのうちの一人の後ろから(逆光)・あなたが決めてください)。光源が特定された場合のみ、ハードかソフトかを尋ねます。理由:各顔のどちら側が照らされるかを決定します。
  • 周囲 — 「彼らの反対側には何がありますか?」 → 場所に合った選択肢。理由:すべてのリバースショットの背景です。
  • ショット — 「どのようにカバーしたいですか?」 → リストを提示します(数、順序、サイズ)・クラシックカバレッジ:ワイド、2つの肩越し、2つのクローズアップ・ワンショット連続・あなたが決めてください。理由:これらがカメラになります。
  • ビート (動きの可能性がある場合のみ) — 「シーン中に誰か動きますか?」 → いいえ、全員そのままです・<このシーンで示唆される動き、それ用に書かれたもの>・はい(誰が、どこからどこへ、いつ動くか教えてください)・あなたが決めてください。理由:動きはパスとして描画され、軸を変更する可能性があります。

ワークフロー

  1. シーンを読み取る — ブリーフと情報収集の回答。以下を抽出します。

    • 場所、その固定された構造、ブロッキングに重要な小道具(壁、ドア、窓、家具、車両、通路)
    • すべてのキャラクター:どこにいるか、姿勢、何を向いているか
    • すべての動き:誰が、どこから、どこを通って、どこへ、最終的な向きと姿勢
    • 重要なすべての光源(太陽、窓、ランプ、実用的な光源):物理的な位置、光が来る方向、誰に当たるか
    • 主要な関係性 — 最も会話したり見合ったりするペア。そのペアが180度軸を定義します。動きによって形状が変わる場合は、その動きの後のショットの軸を決定します。
    • ショット。ユーザーがあなたに任せた場合やクラシックカバレッジを選んだ場合は、自分で構築します(「カバレッジ」セクション参照)。

    レイアウトを始める前に、自分自身に3つの質問をします:シーン中に物理的に変化するものは何か(誰が動くか、何が拾われるか、何が開くか)、観客が同時に見なければならないものは何か(2人が同じフレーム、顔とその背後にあるドア)、ショット間で固定されなければならないものは何か(照らされた窓、テーブル、シーンの鍵となるオブジェクト)。その答えによって、どの小道具に名前を付けるか、どのショットをツーショットにする必要があるか、軸をどこで維持すべきかが決まります。

  2. 実際のサイズを使ってメートル単位でレイアウトします(下のサイズ表参照)。マップの慣例:+yはメイン/オープニングカメラから見た「シーンの奥行き」方向、+xは右。メインカメラはアクションの南側に置き、北を向きます。

  3. シーンスペックをJSONで作成し(スキーマは下記、完全なJSONスキーマは references/scene.schema.json)、ワーキングディレクトリに保存します。次に、レンダリングせずに検証します: uv run <skill-dir>/scripts/staging_render.py scene.json --check (<skill-dir> はこのSKILL.mdを含むフォルダ)。解決されたレポート(カメラ位置、警告)または単一の spec error: … 行が出力されます。修正して再チェックし、合格するまで繰り返します。

  4. プレビューと承認 — レンダリング前に行います。 以下を実行: uv run <skill-dir>/scripts/staging_render.py scene.json -o <name>.mp4 --preview (数秒)。これにより <name>.preview.png(完成マップ)と <name>.report.json が書き出されます。まず自分でプレビューを確認し、明らかな問題を修正します(画像を表示できない場合は、レポートを確認してその旨をユーザーに伝えます)。次に、ユーザーにプレビュー画像と、ユーザーの言語での簡潔な計画を提示します:

    • 環境 — 空間のサイズ、主要オブジェクトとその位置(相対的な言葉とメートル)
    • キャラクター — 位置、姿勢、向き。次に各動きを順に
    • 照明 — 各光源、その位置、誰のどの側面を照らしているか
    • カメラ — 表形式:番号、サイズ、レンズ、位置(例:「Aの右前方2.9m、アイレベル」)、何が見えるか、このカメラの理由(カバレッジにおける役割)
    • ショット説明 — 全カメラについて、references/staging-craft.md のテンプレートを用いてフレームの簡潔な平文説明を生成:誰と何がフレーム内でどの側にいるか、背後にあるもの、光が来る側、アイライン方向、軸側。中立的で事実に基づく:スタイルやムードの言葉、特定の画像・動画ツール向けの表現は避けます。
    • 180度軸 — どのペアか、カメラが留まる側、ミラーリングまたは軸を越えるショット
    • 前提 — ユーザーではなくあなたが選択したすべての値にその旨を明記
    • 代替案 — ユーザーが言及しなかった2~3のカメラオプションと、それぞれのトレードオフを一行で(references/staging-craft.md の「代替案の提案」参照)。ユーザーが選択した場合のみ適用します。 承認または修正を依頼します(「ドアを別の壁に」「ショット3をクローズアップに」「彼女は座ったまま」)。修正をスペックに適用し、再度プレビューして変更計画を提示します。承認されるまで繰り返します。ユーザーが明示的にレビューなしでのレンダリングを要求した場合のみこのステップをスキップし、その場合は納品時に前提をリストアップします。
  5. レンダリング バンドルされたエンジン scripts/staging_render.py を使用(このスキルのフォルダからの相対パスであり、書き換えたりコピーしたりしないでください): uv run <skill-dir>/scripts/staging_render.py scene.json -o <name>.mp4 --quality h クイックドラフトには --quality l を使用します。動画は完成マップで1秒間始まり(--poster 1.0、デフォルト)、その後段階的構築にクロスフェードします。この最初のフレームはソーシャルプラットフォームでのサムネイルにもなるため、結果全体が表示される必要があります。--poster 0 はユーザーが単純なビルドアップを求めた場合のみ使用します。 各キャラクター、光源、カメラ(位置、距離、水平視野角、フレーム内の誰と何がどの側に見えるか、各光がどのフレーム側から来るかを示す frame ブロック)と warnings を含むJSONレポートが出力されます(<name>.report.json としても保存)。また、完成マップ <name>.last.png が保存されます。

  6. 結果を納品前に確認します。 <name>.last.png を開いて確認します(画像を表示できない場合はレポートに頼り、その旨を伝えます)。すべてのラベルが読めること、カメラアイコンが人物の上にないこと、コーンが正しい被写体を指していること、移動経路が読めること、凡例が途切れていないことを確認します。次に、references/staging-craft.md の最終空間チェックを実行します:ショット間での左/右とアイラインの一貫性、すべての出入りが可能であること、固定オブジェクトとキーライトがすべてのショットで同じ物理的位置にあること、マークされていない軸の交差がないこと。warnings を読みます — 自動ミラーリングされたショットや軸を越えるカメラはユーザーに伝えなければなりません。スペックを修正して再レンダリングします(最大2回まで)。

  7. 納品 動画とスペックJSON(数値を変更してレイアウトを編集可能)および承認済みのショット説明(最終スペックに更新)を納品します。ユーザーの言語で、どのデフォルトが残っているか(情報収集で未決定のままかユーザーが返したもののみ)、および軸に関する警告を2~3行で伝えます。マップのラベルは、ユーザーが別の指定をしない限り英語です。

カバレッジ(ショットが任された場合)

シーンをカバーする最小限のセットを、撮影台本の順序で、最大8ショット構築します:

  1. ワイドを確立 — 全員がフレーム内(target: すべての名前のリスト、`size:

関連スキル