zxd-666/video-flow

Video Flow｜コード解説動画

テーマを事実に基づいた、理解しやすい中国語解説動画にします。完成品は、BGMと字幕付き、またはAPI合成によるナレーション解説のいずれかを選択可能。レイアウト、グラフ、フローチャート、アニメーションはHTML/CSS/SVG/Canvas/GSAPなどのコードで制作。必要に応じて、出典のあるネット画像、ユーザー素材、またはAI生成画像を静的素材として使用できます。最終的な映像はコードにより編集・レンダリングされ、AI生成のビデオクリップは使用しません。

3ステップの流れ：原稿と制作オプションの確認が通過条件

1. 調査と原稿作成。 ユーザーがテーマのみを提供した場合、情報を収集します。対象者、尺、アスペクト比、表現スタイルを推測（後で変更可）し、重要な分岐点でスクリプトが変わる場合にのみ集中的に質問します。調査とスクリプト に従い、最新の検証可能な情報を検索し、後で映像化に使える可能性のある元のWebページのスクリーンショット、画像、出典を随時保存。完全な内容原稿、出典マッピング、および簡単な映像意図を作成します。原稿と主要な視覚的証拠のディレクトリをユーザーにレビューしてもらいます。
2. 原稿、音声形式、視覚スタイルの確認。 レビュー時に、ユーザーに「BGM＋字幕」または「ナレーション（API音声）」のいずれか、および以下に示す命名済みスタイルのうち1つを選択してもらいます。ユーザーが既に指定している場合は、不足している項目のみ質問します。ユーザーが原稿内容を確認してから制作を開始します。「OK」の一言で原稿を確認できますが、まだ明確に指定されていない音声形式やスタイルを代わりに選択することはできません。確認前は、調査で得た実際のスクリーンショットや資料を保持できますが、ナレーション、AI画像、アニメーションプロジェクト、動画は生成しません。
3. 選択されたプランに従って直接制作・納品。 「BGM＋字幕」版では、確認済みの内容を画面で読みやすい短い文に変換し、読み上げ速度と音楽のビートに合わせて映像を構成します。「ナレーション」版では、音声生成APIを呼び出し、最終的な音声に合わせて映像と字幕を構成します。制作と品質確認 に従い、ディレクション計画と統一タイムラインを作成し、制作、レンダリング、完成品のチェックを行います。MP4、字幕または画面用テキスト、編集可能なプロジェクトファイル、素材・出典リストを納品します。原稿とプランの確認はローカルでの制作を許可するものであり、公開、有料サービスの購入、または同意のない個人の声サンプルの使用を許可するものではありません。

レビュー時に提供する視覚スタイル

• すっきりドキュメンタリー：薄い色の背景と余白、クリアな情報レイアウト、実際のスクリーンショット、控えめなアニメーション。ニュース、商品紹介、証拠の提示に適しています。
• 紙のようなコラージュ：暖かい紙の質感、画像やオブジェクトのコラージュ/分割アニメーション。事例、クリエイティブ、具体的なコンテンツに適しています。
• ダークテクニカルデスク：ダークなインターフェース、フローチャートと部分拡大、実際のツール/コード画面。技術やオープンソースプロジェクトに適しています。

3つのスタイルの簡単な説明と、現在のテーマに対する推奨事項を提示し、ユーザーにスタイルを選んでもらいます。ユーザー自身のスタイルや組み合わせを指定することも可能です。選択後、すぐにカットごとの制作に入り、3つのバージョンのビジュアルモックアップは作成しません。モックアップはユーザーから明示的に要求があった場合のみ作成します。

テーマが明確な場合は、すぐにステップ1を開始します。制作全体のブリーフィングを開始の障壁にしません。ユーザーが指定した尺、プラットフォーム、声色、スタイルを優先します。指定のない項目は、原稿納品時にデフォルトの想定を明記し、ユーザーが一緒に修正できるようにします。他のスキルで謳われている「ユーザーの長期的な好み」をそのまま流用しないでください。

調査とスクリプトの完了基準

• 新しい、変わりやすい、ニッチ、または議論のある事実については、インターネットで検証します。公式発表、公式ドキュメント、論文、生データ表、またはイベント当事者を優先。同時に、公開日時とイベント発生時期を比較します。検索の要約は出典として使用できません。既存の知識は問題の整理や安定した背景の説明に使用しますが、最近の事実の証拠の代わりにはなりません。
• 一次資料を閲覧する際、視聴者が証拠を視覚的に確認できる実際の画像（発表のタイトルと日付、リポジトリファイルリスト、重要な原文、製品の実際のインターフェース、データグラフなど）を同時に選びます。調査とスクリプト に従い、元のスクリーンショット/ファイルと証拠インデックスを保存し、URL、取得日時、対応する段落、使用範囲、表示方法を記録します。特にページが変更されたり消えたりする可能性がある場合は、速やかに保存します。スクリーンショットは、その時点での出典の表現としてのみ扱い、独立した事実検証としては使用しません。保存できない場合は、正確なアクセス方法と理由を記録します。
• 内容原稿には安定した段落IDを付けます。ナレーション版はそのまま読み上げ可能な完全な原稿を準備し、「BGM＋字幕」版はそれをもとに画面用の短い文に抽出し、長い文章を画面に詰め込みません。重要な事実は特定の出典まで遡れるようにします。事実、推論、意見は分けて記述します。証拠のない数字、事例、効果については、確定した結果として書きません。
• ショート動画では、まず1つの核となるメッセージを決め、冒頭の感情的なフック、中盤の説明、最後の実用的な内容を一貫したナレーションラインで結びます。情報が多い場合は枝葉を削り、1本の動画を知識ポイントの目録にしません。ターゲットプラットフォームに合わせて、最初の2秒のフックと、途中で視聴者の注意を再び引き付けるための転換点を計画します。リズムは内容によって決まります。
• 最後には、視聴者が持ち帰れる具体的な内容を必ず提示します。 元の情報がどこにあるか、どの部分を優先的に見るべきかを明確にし、テーマに直接関連する1〜3の洞察、判断材料となる質問、または実行可能なチェック項目を提供します。検索可能な資料名/パスと必要な直接リンクは、原稿の外側および最後の画面計画に記載します。「注目に値する」「今後に期待」などの漠然としたまとめで終わらせません。
• 推定尺は「推定」と明記します。ナレーション版の実際のリズムはAPIで生成された音声に基づき、「BGM＋字幕」版のリズムは最終的な画面テキストの読了時間と音楽のビートに基づきます。引用と画面に関する注釈は原稿の外に置き、最終的な説明テキストに混在させません。
• レビュー時には、ユーザーが内容の正確性と表現の適切さを直接判断できるスクリプトとともに、音声形式と3つの命名済み視覚スタイルの選択肢を提示します。ユーザーが原稿を確認するまでは、ここで停止します。

制作の完了基準

• 「BGM＋字幕」を選択した場合、BGMと映像の動きに対応した効果音を使用します。ナレーションは生成しません。字幕は画面の説明テキストであり、読みやすさと音楽/動きに合わせて調整します。「ナレーション（API音声）」を選択した場合、利用可能で適切に権限が付与された音声生成APIを呼び出して自然なナレーションを生成し、必要に応じて低音量のBGMを追加できます。「ナレーション」は音声表現を指し、実際の出演を必要とせず、デフォルトでユーザーの声色を再現することもありません。システムTTSやBGMのみで代用することは許可されていません。感情的なフックと専門用語を事前に試聴し、声色とタイムラインを決定します。権限がない場合、個人の声をクローンしたり、有料サービスを自ら有効にしたりしません。ユーザーがMiniMaxの声色複製と音声生成を選択した場合は、MiniMax音声連携に従い、アカウントの権利、声色の権限、課金を確認します。最終的な音声で尺を測定します。字幕は確認済み原稿と同一の情報源から生成しますが、実際の音声に変更があった場合は修正して再確認します。ワードレベルのタイミングが実測値、ASRアライメント、推定値のいずれであるかを明記し、推定値を「正確な同期」と表現しません。
• 有料APIキーは、このスキルの SKILL.md、references/、agents/、scripts/ などのファイルに平文で記述してはならず、動画プロジェクト、コマンド、ログ、納品パッケージにも記述しません。呼び出し時は、設定済みの安全な認証情報ソースからのみ読み取ります。サービス、モデル、声色、および非機密パラメータのみを記録し、キー値は記録しません。
• 各画面は説明の役割を果たします。原稿の段落に基づいて、見えるオブジェクト、動作、情報の変化を計画します。リクエストの送信について説明する場合はリクエストフローを表示し、スケジューリングについて説明する場合は割り当てを表示し、制限について説明する場合は境界を表示し、資料の入り口について説明する場合はパスを読み取り可能にします。視覚言語を統一することは、同じ中景アニメーションやカードを繰り返し使用することと同じではありません。テキスト、数字、構造、グラフ、UI、比較などはコード描画を優先します。静的画像は、コード画面よりも問題を説明できる場合にのみ使用します。外部素材の出典と利用条件を記録します。透かし入りの画像を動画素材として使用しません。
• レビュー時にユーザーが選択した視覚スタイルに従って直接制作します。「3バージョンのプレビュー」を開始の障壁にしません。ユーザーが独自のスタイルを指定した場合は、そのスタイルに従って実行します。字幕または画面の説明テキストは画面デザインの一部であり、スマホ画面での階層、改行位置、表示時間、メイン画面との関係を個別に確認する必要があります。
• 原稿とプランを確認した後、まず簡単なディレクション計画を作成します。核となるメッセージの起承転結、画面のモチーフ、カットごとの動きとそれが説明する関係、カット/字幕/音声のヒントを含めます。ナレーション版は最終的なナレーション音声で統一タイムラインを決定します。「BGM＋字幕」版は画面テキストの読了時間と音楽のビートでタイムラインを決定します。実際のスクリーンショットは「証拠が登場する」瞬間に優先的に使用し、プロセスとメカニズムはコードアニメーションで明確に説明します。同じ視覚言語内でオブジェクト、スケール、視点を切り替え、中盤でのカードの繰り返しを避けます。制作と品質確認に従い、実際の完成品を確認します。
• ローカルに既存の huashu-motion CLIをコード動画効果およびレンダリングバックエンドとして優先的に使用します。まずその能力を確認し、そのプロジェクト契約に従って制作および検収を行います。利用できない場合は、ギャップを説明し、現在の環境で検証可能なコードレンダリングパスを選択します。動画を生成したと虚偽の主張をしません。バックエンドのバージョンと絶対パスをプロジェクトファイルにハードコードしないでください。
• レンダリング後、実際のMP4ファイルの音声、尺、アスペクト比、字幕の可読性、キーとなる画面、シーンの繋ぎ目を確認します。自動チェックに加えて、実際に視聴するか、重要な時間帯をスポットチェックします。編集可能なソースファイル、音楽またはナレーション音声、字幕/画面テキスト、素材マッピングを保存します。実行されなかったチェックは「未検証」とマークします。

手戻りの境界

確認済みの事実や説明内容を変更する場合は、まず変更内容と影響を受ける段落を提示し、ユーザーから新しい原稿の確認を得てから、対応する音声または画面テキスト、字幕、カットをやり直します。画面、リズム、またはサウンドミックスだけを変更する場合は、影響を受ける段落のみ手戻りします。フィードバックで中盤のカットが繰り返される、画面と説明が乖離していると指摘された場合は、該当部分の画面の物語を再構成する必要があり、色を変えたり装飾アニメーションを追加するだけでは不十分です。通常の制作段階ごとに逐一同意を得る必要はありません。課金、公開、個人の声サンプルなどの事項は個別に処理します。