Viral Flow → 承認を得た2つのCapCut編集版

ホスト互換性

このスキルは、Codex、Claude Code、またはカスタムスキル対応のClaudeで同じように使用できます。バンドルされている参照ファイルやスクリプトは、このスキルフォルダからの相対パスで解決してください。agents/openai.yamlはCodex用のオプショナルなメタデータであり、Claudeでは不要です。Codexのツール名を想定せず、ホストが実際に持つツールを使用してください。

実行を約束する前に、ソース動画、ローカルのWhisper、ユーザーのCapCutへのアクセス権を確認してください。クラウドシェルはユーザーのMacではありません。クラウド上のファイルアクセスやコード実行を、ローカルのCapCut制御と誤って扱わないでください。もしトランスクリプトのみが利用可能な場合は、それらから暫定的なフローを準備し、ソースのタイミングや音声は未確認であることを明記し、不足しているメディアやローカルツールへのアクセスを求めてから、カット準備ができた結果を約束してください。決してローカルのフッテージを黙ってクラウド文字起こしに送信したり、Whisperが実際に実行されていないのに実行されたと主張したりしないでください。Claudeのウェブチャットでは、提供されたトランスクリプトはテキストレビューをサポートできますが、CapCut編集にはユーザーのコンピュータに接続され、必要な権限を持つホストが必要です。

成果物と永続的なデフォルト

ユーザーのフッテージに基づいた、2つの異なる、首尾一貫した動画フローを提供してください。2つのでっち上げたスクリプトではありません。ユーザーの言語（デフォルトは広東語・繁体字中国語）で作業してください。

このワークフローには、作成者が要求した実際の承認境界があります。 分析 → 2つの完全なテキストフローを提示 → 承認を受ける → CapCutで編集 → 2つの動画を出力

承認前は、読み取り、文字起こし、フッテージの検査、提案の準備のみを行ってください。編集プロジェクトの作成、タイムラインのカット、提案された編集のレンダリング、ラフカットの出力は行わないでください。「2バージョン」というリクエストは、この境界を無効にするものではありません。ユーザーからの明示的な後続の指示があれば変更できます。フックのみの承認は、完全な改訂フローの承認にはなりません。承認された部分は保持し、要求された部分を修正し、再度依頼があった場合は両方の完全なフローを再提示してください。現在の両方のフローが明示的に承認された後は、再度尋ねることなく編集・出力を完了してください。1つだけ承認された場合は、そのバージョンのみを編集してください。

デフォルトの成果物はフローオンリー編集です。元の音声と映像をそのまま使用し、テキスト、キャプション、タイトル、グラフィック、Bロール、音楽、新しいナレーション、AI音声、新しいエフェクトは追加しません。ソースフッテージに既存の要素はそのまま残します。これらのデフォルトは、リクエストがあった場合にのみ変更してください。文章レビュー用ドキュメントは、画面上のキャプションではありません。

このIPでは、各バージョンは以下の順で始まります。

ソースからの強力で完全な話し言葉のフック。
元の話し言葉「Soft voice, wild truth」。
その動画の録音でそれに続く特定の英語の文。
ストーリー本文、理解の変化、具体的な現在への影響、そして締めくくりのペイオフ。

比較動画の英語の文を、関連のないトピックに再利用しないでください。不足しているブランドラインを合成しないでください。もし存在しないか不明瞭な場合は、本文のドラフトを完了させ、正確なギャップを特定し、依存する編集を完了する前に元のクリップまたは明示的な例外をユーザーに求めてください。

1. リファレンスとソースの役割を確立する

フローを提案する前に、references/viral-format.mdを読んでください。そこには、ベンチマークのストーリーテリングメカニズムと、作成者のフィードバックから得られた教訓が保持されています。リファレンス動画と編集する新しい動画は異なる入力です。ユーザーがそれらの役割を修正した場合は、すぐに記録を更新し、間違ったファイルからパフォーマンスを推測しないでください。

新しいベンチマークが提供された場合は、その全内容を検査し、おおよそのビートをマッピングし、タスクフォルダに簡潔なreference-profile.mdを保存してください。ソースの同一性、長さ、フック、好奇心/回答のシーケンス、対立、感情の転換、ペイオフ、共有オーディエンス、視覚的な役割、および証拠の限界を含めます。ユーザーが報告した高いシェア率や低い離脱率は、独立して検証された因果関係ではありません。決してバイラルを約束しないでください。ソースから得られた事実は、仮説とは別に保持してください。

2. 書き始める前に文字起こしと検査を行う

利用可能なローカルのシェル/ファイルツールとローカルのWhisperを使用してください。ヘルパースクリプトscripts/prepare_media.pyは、モノラル音声を抽出し、クリップ全体から視覚フレームをサンプリングし、オプションでWhisperを実行します。--helpを読んでください。スペースを含むファイル名もサポートされています。再実行する前に、既存の信頼できるトランスクリプトを確認してください。

キャッシュされたbaseまたはsmallモデルから始めてください。広東語のbase出力が重要な表現を破損する場合は、smallを優先してください。タイムスタンプと元のASR出力は保持してください。
動画全体をレビューしてください。フレームサンプリングと文字起こしを組み合わせても、継続的に視聴/聴取することと同等ではありません。検証内容を正確に説明してください。
否定、疑問、名前、数字、英語のブランド用語については、ソース音声または埋め込み字幕と照らし合わせて修正してください。ASRを完成されたトランスクリプトとして扱わないでください。
ブランドラインとそれに続く英語の部分の正確な範囲を特定し、それを1つの連続した単位として保持してください。
実際のイベント、関与した人、予想されたこと、実際に起こったこと、感情的コスト、変化した解釈、現在の行動、そして締めくくりのラインを特定してください。
ソースファイル名、トランスクリプト、フレームシート、出力ファイルはローカルに保持してください。スキルのインストールや公開は、ユーザーのメディアを公開することを許可するものではありません。

3. 2つの完全なレビューフローを提示する

references/review-format.mdを読んでください。バージョンAとBを、異なるオーディエンスの入り口ポイントやナレーションの順序で作成してください。両方とも同じソース事実と一致させてください。

フックは、単なるスローガンや説明のない現象ではなく、完全な緊張を伝えるものでなければなりません。例えば、「比較対象がアップグレードする」は不完全です。「私は進歩し、さらに先を行く人を見つけ、自分はまだ十分ではないと決意する」は、聞き手に完全な矛盾を与えます。

因果関係を保持してください。ベンチマークが55秒だったからといって、112秒のソースを40秒にカットしないでください。承認されたケースでは、背景、成果、逆転、現在のブランド選択、そして締めくくりの反省を保持するために、約90～100秒が必要でした。これらの長さは例であり、割り当てではありません。

各レビューには以下を含めます。

バージョンタイトル、アングル、選択されたソース範囲からの推定実行時間。
提案された完全な話し言葉フローを順に、フック、固定のブランドライン/英語ライン、背景、具体的なイベント、対立、転換、現在への影響、そして必要に応じて結末を含めて記述。
読みやすさのために軽く正規化されたテキストであることを明記し、存在しない単語が録音されていると暗示しないでください。内部のソースタイムマップを保持してください。本質的に新しいラインは、「録音が必要」と明示的にマークし、黙って挿入してはいけません。
バージョン間の意味のある違いを簡潔に説明してください。

2つのフローとして、見出しだけ、アウトラインだけ、または孤立したフックだけを提出しないでください。移動したフックは、短く意図的なコールバックが必要な場合を除き、元の本文の位置から削除してください。代名詞、「後で」、「しかし」、原因と結果が、並べ替え後も意味を成すことを確認してください。

flow-review.mdと提案されたソース範囲をローカルに保存してください。ユーザーが現在のフローを承認するまで、ここで編集作業を停止してください。 これはユーザーが要求したレビュー優先のワークフローに従っていることを明確に述べてください。もしこのスキル自体が後日の許可に関する質問の根拠となる場合は、この正確なファイルをリンクし、承認境界に関する文を引用してください。

4. 承認 → 実行可能な編集計画

ユーザーの承認メッセージ、それがカバーするバージョン/リビジョン、および承認されたフローをapproval.mdに記録してください。ソースの変更や、実質的に異なる話し言葉の内容が生じた場合は、承認がまだそれらをカバーしているかどうかを確認する必要があります。承認された内容を保持する技術的な境界の調整は、繰り返し承認を必要としません。

ソースパス、FPS、長さ、ブランドスパン、2つの名前付きバージョンとその順序付けられたセグメント（start_frame、end_frame、role）を含むedit-plan.jsonを作成してください。許可されるロールは、hook、brand、body、payoffです。フックを最初に、完全な連続したブランドスパンを2番目に配置することを要求します。半開区間を使用してください。開始は含み、終了は含みません。

scripts/validate_plan.pyを実行して範囲をチェックし、長さを計算してください。これはジオメトリを検証するものであり、真実性、言語、承認を検証するものではありません。ソースの音声と映像をロックしたままにし、フレーム単位で揃った自然な音声の境界でカットし、必要な場合は呼吸を保持し、音節がクリップされないようにしてください。推定実行時間に合わせるために、音声を加速したり、承認された意味を変更したりしないでください。

5. CapCutで編集および出力する

承認後、references/capcut-workflow.mdを読んでください。

実際に利用可能な機能を発見してください。CapCutとChatCutは異なる製品です。黙って代用しないでください。
利用可能な場合は本物のCapCutコネクタを優先し、そうでない場合はユーザーのローカルCapCutインストールでサポートされているコンピュータ使用ツールを優先してください。
スキルは指示を提供します。CapCutをインストールしたり、コンピュータ制御を許可したり、利用できないツールを存在させたりするものではありません。
AとBそれぞれに、タスク専用の編集可能なプロジェクトを維持し、元のメディアを保存してください。無関係な既存のプロジェクトを編集しないでください。
ローカルで検査されたネイティブドラフトルートはオプションであり、バージョンに依存します。参照ファイルのガードレールの下でのみ使用し、古いパス、ID、スキーマ、UI座標を推測しないでください。
CapCutを介して出力してください。実用的な場合、元のアスペクト比とフレームレートでH.264 MP4を提供してください。アップスケーリングが詳細を生成するとは暗示しないでください。CapCutがH.264 MOVを生成する場合は、再エンコードせずにロスレスでMP4に再マックスしてください。関連する場合にのみ開示してください。

機能や認証の都合でCapCut編集ができない場合は、承認されたレビューとソースタイム計画を保持し、具体的なブロッカーと正確な次のアクションを説明してください。計画を完成した動画と呼んだり、FFmpegのみの編集をCapCut出力と称して代用したりしないでください。

6. 確認と納品

両方の出力ファイルが存在し、完全にデコードでき、音声と映像を含み、計画された長さとアスペクト比に一致し、承認されたフック→ブランド→英語の順序を含んでいることを確認してください。開始部分、すべての新しい結合点、および終了部分を検査し、可能であれば音声を聞いて、音節のクリック、クリック、繰り返しの単語、不自然なトランジションがないか確認してください。フローオンリープロジェクトに追加のテキストトラックやエフェクトがないことを確認してください。タイムラインだけでなく、最終出力を検査してください。

期待されるソーススパンとの音声比較は、編集順序を裏付けることができます。AACの位相/遅延の違いにより、生の波形相関が低下する可能性があります。振幅エンベロープのタイミングは、より良い追加チェックです。メトリックや数フレームのサンプリングだけでは、編集全体が視聴または聴取されたことを証明するものではありません。

両方の完成動画へのクリック可能なローカルリンク、長さ、簡潔なバージョンラベルを提供してください。編集可能なCapCutプロジェクトが保存されている場所を記載してください。素材の検証の限界を正直に報告してください。動画を自動的にソーシャルメディアに公開しないでください。

viral-flow-capcut