mcpField
B
broll-match-engine

broll-match-engine

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

broll-match-engine について

トーク動画の発話ビートにBロール候補を割り当てるスキルです。根拠の強さを考慮したビート単位の計画を作り、不要な場合はAロールを維持する判断も示します。

主な機能

  1. 01ビート単位のマッチ計画作成
  2. 02適合度と証拠力による素材順位付け
  3. 03Aロールを維持する場面の判定
  4. 04代替素材とキーワード表示の提案

活用シーン

  1. 01発話ビートごとのカット割り計画
  2. 02主張を裏付ける映像の選定
  3. 03適切なBロールがないビートの特定

インストール

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

$npx skills add https://github.com/postplusai/postplus-skills --skill broll-match-engine

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

_postplus_shared/00-core/shared-runtime/scripts/
download_videos_from_manifest_with_ytdlp.mjs
postplus_workspace.mjs
_postplus_shared/00-core/shared-runtime/scripts/lib/
hosted_execution_protocol.mjs
local_skill_cli.mjs
creative_format.mjs
postplus_cli_config.mjs
network_runtime.mjs
hosted_media_generation_bridge.mjs
postplus_workspace_runtime.mjs
hosted_billing_summary.mjs
execution_approval.mjs
postplus_cloud_client.mjs
skill_runtime.mjs
_postplus_shared/40-creative/b-roll-family/references/
edit-enhancement-contract.md
skill-architecture.md
contracts.md
scripts/
run_match_broll_plan.mjs

詳細

B-roll マッチエンジン

以下の共有パブリックスキルルールに従ってください:

  • postplus-shared パブリックスキルルール

このスキルは、ユーザーがトーキングヘッド編集を候補となる B-roll 素材のカバレッジに対応付けたい場合に使用します。

このスキルは、曖昧なクリエイティブな要約ではなく、構造化されたマッチプランを生成する必要があります。

デフォルトの出力:

  • broll-plan.json

任意の補助出力:

  • マークダウンのマッチサマリー
  • ビートレビューテーブル
  • 候補ランキングテーブル

用途

  • どの発話ビートに B-roll が必要かを判断する
  • ビートを利用可能な最適な証拠クリップに対応付ける
  • カットアウェイするのではなく A-roll にとどまるべきタイミングを判断する
  • 不足している証拠の瞬間を特定する
  • マッチ結果にキーワード強調やモーションヒントのメタデータを付与する

トリガーシグナル

ユーザーが次のようなことを求めた場合にこのスキルを使用します:

  • これらの発話行にどの B-roll をマッチさせるべきか
  • 素材をマッチしてほしい
  • スクリーンフッテージや証拠ビジュアルにどこでカットするか
  • このトーキングヘッド動画に B-roll をより適切に追加する方法
  • B-roll プランを出してほしい

ユーザーがまだ使用可能な B-roll インベントリを持っていない場合は、このスキルを使用しないでください。

その場合は、まず次にルーティングしてください:

  • skills/40-creative/b-roll-family/broll-catalog-builder

これらのリファレンスを読む

  • ファミリーアーキテクチャ: ../references/skill-architecture.md
  • 共有コントラクト: ../references/contracts.md

役立つ場合は、これらの既存のローカルスキルを使用してください:

  • 専用のビジュアル分析ワークフロー
  • skills/40-creative/editing-decision-engine

中核原則

キーワードの重複だけでマッチングしないでください。

良いマッチは以下に依存します:

  • ビートの意味
  • 証拠の必要性
  • ビジュアルサポートの種類
  • ペーシングの必要性
  • B-roll の強度

最良の素材は、必ずしも最も字面上類似しているものではありません。

時には正しい選択は次のとおりです:

  • UI 証拠クリップ
  • ワークフローブリッジクリップ
  • ペースリセットクリップ
  • または B-roll をまったく使わない

推奨入力

必須:

  • normalized-transcript.json
  • broll-catalog.json

強く推奨:

  • chunked-<mode>.json

任意だが価値が高い:

  • A-roll セマンティック分析
  • 参照編集パターン
  • ターゲットプラットフォーム
  • 意図する出力の長さ

ワークフロー

1. ビート単位を構築する

生のトランスクリプトセグメントよりも、字幕チャンクや編集ビートを優先してください。

各ビートについて、以下を記録します:

  • 発話テキスト
  • タイミング
  • ビートの役割
  • ビジュアルの必要性
2. B-roll の必要性を評価する

すべてのビートがカットアウェイに値するわけではありません。

各ビートについて、次を決定します:

  • 顔にとどまる
  • サポート B-roll を使用する
  • 主要な証拠 B-roll を使用する
  • 軽いビジュアルリセットのみを使用する
3. 候補素材をランク付けする

B-roll を必要とする各ビートについて、候補を次の基準でランク付けします:

  • セマンティック適合度
  • サポート役割の適合度
  • 証拠の強度
  • ペーシングの適合度
  • ビジュアルの明瞭さ
  • 使用可能範囲の品質

すべての候補には、平易な言葉での理由を含める必要があります。

4. マッチ結果をパッケージ化する

broll-plan.json を次の内容で構築します:

  • ビートメタデータ
  • B-roll 必要性の決定
  • 候補リスト
  • フォールバック
  • キーワードオーバーレイの提案
  • モーションヒント

最小スクリプト

最初の実装スクリプト:

  • scripts/run_match_broll_plan.mjs

現在の初版の動作:

  • chunked-<mode>.json を読み込む
  • broll-catalog.json を読み込む
  • 字幕チャンクをビート単位として扱う
  • 発話テキストから beatRole と visualNeed を推論する
  • 以下に対する保守的なヒューリスティクスを用いて B-roll 候補をランク付けする:
    • 発話キーワード
    • カタログの semanticTags
    • カタログの supportRoles
  • broll-plan.json を書き出す

例:

node ${CLAUDE_SKILL_DIR}/scripts/run_match_broll_plan.mjs \
  --chunks /abs/path/chunked-basic.json \
  --catalog /abs/path/broll-catalog.json \
  --output <work-folder>/broll-plan.json

パブリックスキル実行コントラクト

  • ビートチャンク、候補ランキング、および中間マッチプランは <work-folder>/.postplus/broll-match-engine/ に保持する
  • 最終的なユーザー向け broll-plan.json またはレビューエクスポートのみを .postplus/ の外に保持する
  • より広範な編集計画の前に、1 つのトランスクリプトと 1 つのカタログに対する 範囲を限定した最初のパスから始める
  • 必要な上流入力が欠落しているか無効な場合は、その場しのぎのシェル接着剤に 切り替えるのではなく、直ちに停止する
  • マッチングの前に、トランスクリプトのビートにタイムスタンプが含まれ、 カタログ候補に semanticTags が含まれていることを確認する。いずれかが 欠落している場合は、マッチを推測するのではなく、欠落しているフィールドを 直接報告する

出力基準

優れた出力は、人間の編集者が次の問いに答えられるようにするべきです。

  • どこを切り落とすか
  • 何を残して切るか
  • そこにどれくらい留まるか
  • 優先するクリップが弱い場合の代替策は何か

出力が実際の編集を導けないなら、それは十分に具体的ではありません。

初版の境界

推奨するもの:

  • 説明可能な候補のランキング
  • ビート単位の JSON
  • 任意の markdown レビュー

必須としないもの:

  • 完全自動のタイムライン組み立て
  • NLE へのエクスポート
  • 完全な意味マッチングの保証
  • モーショングラフィックスのレンダリング

レビューのルール

常に区別してください:

  • 必須の証拠
  • 有用な補助
  • 任意のつなぎ

インベントリに強力な証拠映像が含まれていない場合、プランはそのことを直接述べるべきです。

コメント

Markdown 対応