cut-as-code

Cut as Code のエントリーポイント

cut-as-code による動画作業では、必ずここをエントリーポイントとして使用してください。担当するのはルーティングとプロジェクト状態の復元のみです。選択された各スキルが、編集上の判断、レビューゲート、スクリプト、レンダリングの詳細、およびセルフチェックを担当します。

1. プロジェクトの状態から開始する

最初に一致した行を適用してください。下の行は評価しないでください。

状態	アクション
ユーザーが既存のプロジェクトに対する特定の操作を指定している	その操作に必要な状態のみを確認してから、担当スキルを読み込みます。一般的なヒアリングは省略します。
明示されたプロジェクトルートに work/project.json がある	work/project.json、work/timeline.json、および選択された操作のプラン／エビデンスのみを読み取ります。記録された状態から再開します。担当スキルが一意に定まらない場合は、ルーティングのみを確認する質問を1つします。
ユーザーがプロジェクトなしでソースファイルまたはURLを提示し、明確な成果物を指定している	/video-understand を読み込んでプロジェクトと共有エビデンスを初期化し、その後、要求された操作に進みます。
プロジェクト／ソースが特定できない、または意図する成果物が特定できない	不足しているプロジェクト／ソースと希望する結果を尋ねる、簡潔な質問を1つします。スキルの作業はまだ開始しません。

プロジェクトルートは明示されている必要があります。リポジトリのルートを動画プロジェクトとして扱ってはいけません。共有マニフェストとして扱うのは work/project.json のみです。進捗はディレクトリの有無ではなく、操作の status、revision、based_on、check、およびレンダリング状態から判断します。検証済みの作業を再実行してはいけません。依存関係が欠落している、または古くなっている場合は、まずその依存関係を完了してから、要求された操作を再開します。

ルーティングは読み取り専用です。タスクの振り分け先を決定する際、操作を修復、リセット、承認、削除、または有効化してはいけません。

2. 成果物に基づいて振り分ける

会話中にたまたま言及されたキーワードではなく、要求された出力に基づいて振り分けます。

要求された結果	担当スキルまたはワークフロー
プローブ、文字起こし、客観的分析、意味の理解、または新規プロジェクトの初期化	/video-understand
テンポを引き締める、短縮する、弱い部分を削除する、または初回／ラフカットを作成する	/video-understand の後に /video-cut
色を補正する、ルックを作成／選択する、またはLUTを納品／適用する	/video-color-grade。ユーザーがProject Protocolでの納品を明示的に望んでいない場合に限り、スタンドアロンの経路を使用します
文字起こしのタイミングに合わせたビジュアルカットアウェイを追加する	/video-understand の後に /video-add-b-roll
出典のあるモーショングラフィックスまたは意味的なアニメーションオーバーレイを追加する	/video-understand の後に /video-add-motion-graphics
タイトル、ローワーサード、統計情報、引用、章、または行動喚起を追加する	/video-understand の後に /video-add-content-cards
字幕、キャプション、またはカラオケ字幕を追加する	/video-understand の後に /video-add-captions
ソースの時間軸上で、元の映像と実際の最終ピクセルを比較する	検証済みのメイン納品物が完成した後に /video-edit-compare
短尺動画の範囲を選択、レビュー、計画する	/video-understand の後に /video-to-shorts。要求されたコンテンツカードや字幕を追加する前に実施します
承認済みの横長または縦型の短尺動画を最終化し、抽出する	検証済みのメイン納品物が完成した後に /video-to-shorts を再開します
既存のProject Protocol納品物をコンパイルまたはレンダリングする	選択された各アクティブな操作がそれぞれのゲートに合格した後、/video-understand の build_render_plan.py と render_project.py を使用します

「この動画を編集して」のような一般的な依頼だけでは、/video-cut を一意に選べません。既存のプロジェクト状態または前後の依頼から希望する出力が明確でない限り、ルーティングを確認する質問を1つします。

3. 複数の操作を調整する

ユーザーが依頼した操作だけを固定し、ルートテーブルをデフォルトのパッケージにしないでください。共通の理解に関する前提作業は一度だけ実行してください。選択したメインシーケンスの操作は、正規の順序で実行してください。

cut -> color-grade -> b-roll -> captions -> content-cards -> motion-graphics

依頼に Shorts、コンテンツカード、またはキャプションが含まれる場合は、次の段階的なフローを使用してください。

/video-understand
-> /video-to-shorts plan and candidate review only
-> /video-add-captions
-> /video-add-content-cards
-> /video-add-motion-graphics
-> compile and render the shared main delivery once
-> /video-to-shorts finalize and extract approved derivatives

Shorts の計画を始める前に、/video-cut など、タイムラインを変更する操作を完了してください。work/timeline.json が変更されると、候補の承認は無効になります。Shorts の計画では、共有プランとレビュー状態を書き込みますが、final.mp4 や final/shorts/ 以下には何も作成してはいけません。その後、キャプション、コンテンツカード、モーショングラフィックスの順に、それぞれの共有プランとオーバーレイへの寄与を追加します。2 つだけを選択した場合も、同じ順序を適用します。キャプションが最初、コンテンツカードが 2 番目、モーショングラフィックスが最後です。各引き継ぎの前に work/project.json を読み直してください。work/project.json、work/timeline.json、操作プラン、または共有レンダーアーティファクトに書き込む可能性がある場合、リーフスキルを並行して実行してはいけません。選択した有効な操作がすべて検証された後に、メインの成果物を一度だけビルドしてレンダリングしてください。/video-edit-compare と /video-to-shorts の最終化／抽出フェーズのみを、検証済みの成果物に対して実行してください。Shorts は sequences.main.operations の外に置きます。

/video-add-content-cards と /video-add-motion-graphics では、キュー全体を通じて、主要人物または前景の人物、話者、プレゼンター、インタビュー対象者、あるいは意味的に重要な人物の顔と頭部の輪郭が見える領域を確保してください。背景にのみ映り、物語上または視覚上の焦点ではない偶発的な人物は対象外です。不確かな場合は保護してください。オーバーレイが保護対象の顔や頭部に重なる場合は、まず位置を変更し、その後にサイズを調整するかデザインを変更してください。適合する配置が見つからない場合は、そのキューをスキップしてください。

担当スキルで許可されている場合、すべてスキップする結果やキューがゼロの結果も有効です。操作を有効なままにするためだけに、埋め合わせの作業を作り出してはいけません。

4. 引き継いで、離れる

作業を始める前に、選択したスキルの SKILL.md 全体と、必要なすべてのサブスキルを読んでください。操作が 1 つの場合は、一度だけ引き継いで、このエントリーポイントを離れてください。複数の操作を実行する依頼の場合は、一度に 1 つずつ担当スキルに進みます。そのスキルのセルフチェック後、プロジェクトの状態を復元し、受付をやり直さずに固定済みの次の操作へ進んでください。

ルートがすでに明確な場合、ユーザーに承認を求めてはいけません。ユーザーとのやり取りが必要なのは、入力の不足、実際のルーティングの曖昧さ、認証情報、または担当スキルが求める編集・レビュー上の判断がある場合に限ります。ユーザーが明示的に委任しない限り、必要な人間の判断をエージェントの判断で代用してはいけません。

例

「理解済みのこのプロジェクトで、キャプションを追加して編集を続けて」と依頼された場合、現在のプロジェクトとタイムラインのリビジョンを読み取り、/video-add-captions に進みます。再度文字起こしをしたり、編集し直したり、キャプションのルートでよいか尋ねたりしてはいけません。無関係な保留中の操作によってルートは変わりませんが、有効な未検証の操作がある場合、最終的な共有レンダーが妨げられることがあるため、コンパイラーに報告させてください。

失敗時のルール

• プロジェクトの状態が無効な場合は、検証で見つかった問題を正確に報告してください。既存の状態を上書きして再初期化してはいけません。
• リーフスキルまたは前提作業が不足している場合は、そこで停止して名称を示してください。記憶を頼りに再構築してはいけません。
• ソースまたはプロジェクトのパスが不足している場合は、ルーティングに関する 1 つの質問で確認してください。
• 依頼された出力が競合する場合は、今回の実行でどの成果物を対象にするか尋ねてください。
• 既存のユーザー変更やアーティファクトは保持し、記録された状態に基づいて作業してください。