general-video

プラグインのインストール： このスキルが HyperFrames プラグイン内にある場合、セットアップまたは最新状態の確認コマンドを実行する前に、プラグインの実行ルールに従ってください。スタンドアロンでインストールした場合は、以下の更新手順を使用してください。

一般的な動画

ワークフロー内で直前に読み込んでいない限り、最初に npx hyperframes usage --json を実行し、草案の作成後やレンダリング前など、節目でも再確認してください。利用可能なウィンドウとリセット時刻を確認してください。使用状況が不明な場合は、利用可能枠を推測せず、その旨を伝えてください。範囲とワークフローの選択はユーザーに委ねてください。

このワークフローに依存する前に、次を実行してください。

npx hyperframes skills update general-video

何も変更されずに正常終了した場合、スキルは最新です。記憶を頼りに続行せず、更新の失敗があれば伝えてください。

1. 横断的なソースアダプターを適用する

• メディア： 音声、画像、アイコン、ロゴ、音声、カラーグレーディング、LUT、処理／エフェクト、字幕、またはメディア操作が必要な場合は、/media-use を読み込み、../media-use/references/resolve.md（解決、採用、再利用）と ../media-use/references/setup-providers.md（プロバイダー、認証）に従ってください。映像素材に関する曖昧なフィードバックや、名前の付いたスタイルを編集する前に ../media-use/references/media-treatments.md を確認してください。対応するメディアエフェクトを CSS／SVG／不透明度で即興的に再現しないでください。認証が必要なプロバイダーに対する最初の操作の前に npx hyperframes auth status を実行し、その出力を一字一句そのまま伝えてください。サインアウト状態の場合は、../hyperframes/references/brief-contract.md のゲートを適用してください。協調型ではサインイン、または明示的なオフライン選択を待ちます。自律型では状態を伝え、利用可能なオフラインプロバイダーを使って続行します。必須機能を満たせるオフラインプロバイダーがない場合は、ブロッカーとして伝えてください。ローカルでの採用だけであれば、認証ゲートは必要ありません。
• Figma： 入力のいずれかが figma.com の URL の場合、最初に /figma を実行してください。エクスポートしたアセット、トークン、コンポーネント、またはストーリーボードのフレームをもとに作成してください。SVG のサニタイズ、メディアの出所情報、ブランドトークンのバインドが省略されるため、Figma コネクターを直接呼び出さないでください。

これらのアダプターによって、/hyperframes が選択したワークフローが変わることはありません。

2. プロジェクトの状態から始める

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

状態	アクション
特定の編集	編集を行い、既存のプロジェクト上の決定を維持したうえで、影響を受けるチェックを再実行してください。ディスカバリーを再開しないでください。
BRIEF.md が存在する	読み込んでください。workflow が別のワークフローを指定し、flow が companion でない場合は引き継いでください。ブリーフに関する質問はしないでください。
ブリーフはないが、hyperframes.json または STORYBOARD.md が存在する	ファイルと記録済みの設定をもとに再開してください。既知の事実だけを使って BRIEF.md を補完してください。
新規作成	/hyperframes とそのインテントレイヤーを実行してください。workflow: general-video または flow: companion の場合に限り、ここに戻ってください。

新しいプロジェクトでは、ブリーフをもとに kebab-case のディレクトリ名を選び、ブリーフを書く前にスキャフォールドを作成してください。

npx hyperframes init "videos/<project>" --non-interactive --example=blank --skill=general-video

次に、../hyperframes/references/brief-format.md を使って、プロジェクトのルートに BRIEF.md を作成してください。既存プロジェクトでは、ルートは hyperframes.json を含むディレクトリです。ブリーフ形式で指定された、確認済みで設定に基づくフィールドのみを node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes <PROJECT_ROOT> を使って記録してください。推測したデフォルト値は決して記録しないでください。ここで <MEDIA_DIR> はインストール済みの /media-use スキルのディレクトリ、<PROJECT_ROOT> は hyperframes.json を含むディレクトリです。インテントレイヤーでレシピが採用された場合は、node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes <PROJECT_ROOT> --name <name> を使って今すぐ適用し、再度尋ねないでください。

3. 実行形態を解釈する

../hyperframes/references/brief-contract.md に記載された正式な用語のみを使用します。

フィールド	意味	効果
flow	誰が進行するか	automation：ルートを選択して実行します。companion：会話を通じて共同で作成します。
storyboard	ビルド前に計画、スケッチ、レビューを行うか	yes：計画とスケッチのレビューを実行します（boards/storyboard.html、形式は../hyperframes-creative/references/storyboard-recipe.md）。no：それを行わずにビルドします。
派生するmode	チェックポイントのゲートの動作	brief contract に従います。ユーザーにモード名を指定するよう求めてはいけません。

これらの状態に対して、同義語を独自に作らないでください。「とにかくビルドして」という継続的な意図は intent layer で処理され、flow: automation、storyboard: no として渡されます。

• flow: automation の場合、ルートを選択し、最初の進捗報告で1行で伝えます。
• 特定の編集の場合、新しいルートを独自に作らず、その編集を行います。

既存の映像に対してハードカット、トリミング、スプライス、並べ替えを行う場合、同じ動画ソースを複数のクリップ要素に複製します。各コピーで、data-media-start と data-duration を使ってソース範囲を設定し、その後、data-start を使って指定された配置順を設定します。各動画セグメントは音声を保持します。音声はクリップに付随するため（data-has-audio="true"）、動画をカットすると音声もカットされます。この時間編集は/hyperframes-coreが担当します。/hyperframes-keyframesは、内側のラッパーに対するズーム、パンチ、パン、クロップ、マスク、clip-pathなど、視覚プロパティのアニメーションにのみ使用します。 ../hyperframes-core/references/creator-editing-recipes.md から契約の全文をコピーします。

コンパニオンフロー

flow: companion の場合：

• BRIEF.md を読み、承認済みの ## Assets と ## Customizations をプロジェクト成果物と照合します。承認済みの作業がまだ保留中なら完了させ、完了済みの作業には手を加えず、承認済みの機能を新しい提案であるかのように再度提示しないでください。
• 請負業者ではなく、ディレクターとして臨んでください。 コンパニオンを選んだユーザーは、関与と品質を求めています。誠実な対応とは、弁護できる最小限のものではなく、設計できる最高のものを提示することです。最初のプランでは、最高水準の演出を提示します。ストーリーの流れ（最も近いジャンルの視点を取り入れます――メニューの「§ Genre lenses」）、デザイン仕様、各シーンの動きの演出を名称付きで提示すること（「§ 5's plan discipline」）、トランジション、音楽とサウンドの演出、または意図的な無音からなる音声の個性、ユーザーの素材の配置、そして設計されたオープニングとクロージングです。各レイヤーが加える価値を一行で説明し、コストのかかる項目（レンダリング時間、サインイン、課金）は提示時に明示します。演出案を承認ごとに組み立てさせるのではなく、ユーザーが演出案を縮小できるようにしてください。
• 最高水準はコンセプトに属し、ツールボックスには属しません。 すべてのレイヤーはブリーフのメッセージに役立つ必要があります。どの動画にも同じように飾り付ける演出は、単なる装飾です。制作の質は最高水準まで高め、コンテンツは依頼された範囲を超えないようにします（「§ 6」）。
• チェックポイントの間は、../hyperframes/references/capability-menu.md を2通りに活用します。トリガーリストとしては、ユーザーが関連する入力について言及したとき、または制作でその機能が必要になったときに提示します。また、各工程のアップグレード手段として、プラン、スケッチ、制作チェックポイントで、ユーザーが見ている素材に結び付けた提案を1つか2つ添えられます（「シーン3の統計にはカウントアップ演出が合います」）。提案する前に読み込み、カタログ全体をそのまま提示しないでください。
• ユーザーが機能を承認したら、その成果物を作成し、対応する BRIEF.md の本文セクションに決定を直ちに記録します。ユーザーが明示的に変更した場合に限り、フロントマターのフィールドを書き換えて、確定した希望を記録します。
• ストーリーボード、検証、最終プレビュー、レンダリング承認の各ゲートは同じように維持します。コンパニオンによって変わるのは指揮を執る人であり、品質に必要な条件ではありません。

4. 各ステージの前に必要な知識を読み込む

以下の読み込みは、条件に該当する場合に必須です。

条件	作業前に読むもの
HTML 構成またはシーンレイアウトを作成する場合	/hyperframes-core。レイアウトの仕様については references/determinism-rules.md を使用します
重要な作成やビジュアル処理を行う場合	/hyperframes-creative → references/house-style.md と references/video-composition.md
モーション、アニメーション、シーントランジションを扱う場合	/hyperframes-animation。該当するルール、アダプター、ブループリント、トランジションのリファレンスへの案内に従います
storyboard: yes の場合	../hyperframes/references/storyboard-format.md と ../hyperframes/references/review-loop.md
ナレーション、BGM、SFX、字幕、カラーグレーディング、変換など、メディアアセットまたはメディア操作を行う場合	/media-use（音楽や効果音については、ホストアプリ独自のツールを優先します）。フレームワークでの再生と配置については、/hyperframes-core → references/variables-and-media.md も読みます
複数シーンを組み立てる場合	../hyperframes/references/production-loop.md
flow: companion の場合、最初のプランを作成する前	/hyperframes-creative → references/story-spine.md と references/house-style.md、最も近いジャンルの視点、および ../hyperframes/references/capability-menu.md 全体。上限の扱いは記憶からではなく、これらをもとに設計します
コンパニオン機能の提案、キャプチャ、ビートグリッド、生成動画、マップ、公開、またはワークフロー横断機能を扱う場合	../hyperframes/references/capability-menu.md
デザイン仕様が存在する場合、最終承認の前	/hyperframes-creative → references/design-adherence.md

これらを記憶で代用しないでください。該当するリファレンスを実際に読み込んだ場合にのみ、段階的な情報開示によってコンテキストを節約できます。

5. コンポジションを実行する

次の依存関係の順序で進めます。入力がない場合に限り、そのステージをスキップします。

1. 計画する。 視聴者がたどる流れ、構成、リズム、尺を決める要因を明示します。短い単一シーンには単一ファイルを使用し、3つ以上の明確なシーンカットがある場合、またはシーンを再利用する場合はサブコンポジションを使用します。ナレーションのあるストーリー展開には /hyperframes-creative → references/story-spine.md、リズムには references/beat-direction.md、構成には /hyperframes-core → references/composition-patterns.md を参照します。自由度の高い複数シーンの依頼では、/hyperframes-creative → references/prompt-expansion.md を使ってプロンプトを展開します。複数シーンの計画では、各シーンの形を明記します。適合するブループリントがある場合は /hyperframes-animation → blueprints-index.md のブループリント ID を、ない場合は rules-index.md の合成元となるルール名を引用します。モーション名は必ずこれらのインデックスから取得し、独自に作り出してはいけません。どのシーンを設けるかはストーリーの内容で決め、引用はその見せ方を整えるために使います。名前の付いたルックを自作する計画を立てる前に、必ず最新のカタログを検索します。依頼に名前が挙がっているルック、エフェクト、処理、トランジション（「CRT scanlines」、「glitch」、「film grain」、「shimmer sweep」、「confetti burst」など）ごとに、npx hyperframes catalog --query "<the look, in plain English>" --json を実行し、上位の検索結果を確認してから、そのルックの作り方を計画に記載します。検索にインストールは一切不要です。プロジェクトも、事前の add も、アカウントも必要ありません。どのディレクトリからでも、ホストされているレジストリ全体（約400のブロックとコンポーネント）を検索できるため、ユーザーがビルドの途中で依頼したルックにも適用されます。計画で指定したブロックはステージ3でインストールします。検索して適合するものが見つからなかった場合に限り、ルックを手作業で作成します。複数シーンの計画は、ディスパッチ用アーティファクトとしても記録します。storyboard: no の場合も含め、STORYBOARD.md にシーンごとに1つの ## Frame N ブロックを作成します。各ブロックには status: outline、宣言した src:、ブループリントまたはルールの引用、ビートの説明を記載します。ブロックがディスパッチの単位であり、ストーリーボードシートはレビュー用の表示にすぎません。

2. 求められた場合は計画をレビューする。 storyboard: yes の場合は、これらのブロックを対象に共通のレビューループを実行します。storyboard: no の場合は、計画の確認待ちやスケッチシートを挟まずに進めます。それでも計画の確認待ちが発生する場合は、サブエージェントへの委任許可（ステップ4のディスパッチに codex が必要とするもの）をその確認時にまとめて取得し、後で改めて停止しないようにします。

3. 依存関係を解決する。 並行作業の前に、レジストリのブロックをインストールします。ユーザー提供のアセットを配置し、既存のメディアを取り込み、依頼に必要なものだけを解決します。尺を左右する場合は、早い段階で音声の作業を始めます。

4. シーンを作成する。 短い単一シーンの作品では、動きを加える前に、最もよく見える瞬間のシーンを実装します（確認済みのワイヤーフレームがある場合は、それが完成時の状態なので、描き直してはいけません）。その後、引用したブループリントまたはルールに従ってアニメーションを付けます。モーションを書く前に、レシピの本文全体（/hyperframes-animation → blueprints/<id>.md、rules/<id>.md）を読みます。

   ディスパッチが効果を発揮するのは、大規模な場合だけです。 作成用パケットの用意や新しいワーカーのコンテキストの準備には、実際に分単位の時間とトークンがかかります。短いシーンが約6つまでの動画は、このコンテキスト内でシーンを1つずつインラインで作成するほうが速くなります（実測値：短いシーン5つの場合、インラインは約9分、パケット化すると約21分）。計画がそれを超える場合、つまりシーン数が多い場合や、個々のシーンが非常に重い場合にのみ並行処理にします。その場合、各ワーカーには1つではなく2～3シーンを割り当て、すべてのワーカーを一度に起動します（2回に分けると所要時間がほぼ倍になります）。ディスパッチする場合：

   node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJECT_DIR" --storyboard "$PROJECT_DIR/STORYBOARD.md" ビルダーはシーンごとに、.hyperframes/frame-packets/ の下に1つの範囲を限定したパケット（シーンの正確なストーリーボードブロック＋ブループリント本文＋引用されているすべてのルールレシピをインライン化したもの）と、_role.md（../hyperframes/references/frame-worker-core.md とこのスキルの sub-agents/frame-worker.md をそのまま連結したもの — ワーカーの完全な役割定義）を書き出します。ワーカーをディスパッチします — 各ワーカーにシーンパケットを2～3個ずつ、1回のウェーブですべて割り当てます（../hyperframes/references/subagent-dispatch.md）。各ワーカーのプロンプトには _role.md とパケットを含めます — 全文を貼り付けるか、最初に読み込むファイルパスを渡します（どちらも同等です） — さらに PROJECT_DIR、そのワーカーの frame_id、キャンバスサイズを含むディスパッチコンテキストも渡します。各シーンの正確なストーリーボード src（例：compositions/frames/<frame_id>.html）と、隣接する <frame_id>.motion.json サイドカーファイルがそろうまで待ちます。ワーカーが読むのは自分のパケットとデザインの正本ファイルだけです。STORYBOARD.md やスキル文書は開きません。委任チャネルがない場合は、順次処理に切り替え、このコンテキストで一度に1つのパケットだけを処理し、引き続きパケットのみを基に作業します。

5. モーションサイドカーファイルを統合します。 各ストーリーボード src に隣接するワーカーの <frame_id>.motion.json ファイルを集め、その尺と退出／進入ベクトルをアセンブリに反映します。ドクトリンチェーン（/motion-doctrine）がインストールされている場合は、シームを確定する前にプロジェクトの台帳へ変換します。

6. アセンブルします。 制作ループを使って、シーン、メディア、トランジション、キャプション、音声を組み立てます。実際のナレーション尺は推定値より優先されます。音楽トラックが音声トラックの下で再生される場合は、検証前に音楽トラックを加工します：/hyperframes-audio → scripts/carve.mjs --comp index.html。音量を下げるだけではミックスは完成しません。

7. 検証します。 最初のHTML作成後、および構造変更後は、迅速なフィードバックを得るために npx hyperframes lint を使います。最終ゲートでは npx hyperframes check を実行します。このコマンドは内部で lint を再実行するため、その直前に単独の lint を重複して実行しないでください。サブコンポジションでは中間時点のスナップショットを確認します。複数シーンの作業では、アニメーションマップを確認します。

8. 最終承認を得ます。 チェックに合格したら、最終的な Studio プレビューを開きます — 自律モードでも、レンダリングの前に必ず開きます。開いても質問は表示されません。レンダリングするか修正するかを尋ねます（自律モードでは、尋ねる質問はこの1つだけです）。承認を得てからレンダリングします。

6. 常に適用されるゲート

スコープを厳密に守る

ユーザーが依頼した内容を作成します。タイトルカードの依頼は、タイトルカードに加えて3つのシーン、音楽、キャプションまで作る依頼ではありません。追加要素は、追加する前に提案してください。

HTMLより先にデザインを確定する

デザインの正本は、次の順に確認します：frame.md → design.md → DESIGN.md。最初に見つかったファイルをブランドの正本として扱います。

デザイン仕様が存在しない場合は、コンポジションのHTMLを書く前に、次の4項目をすべて完了させます。

1. house-style.md と video-composition.md を基に、ビジュアルアイデンティティを定めます。
2. 重要な作品ごとに、コンセプトの切り口を示す一文を書きます。
3. /hyperframes-creative → references/typography.md から、埋め込み可能なフォントの組み合わせを選びます。クラウドレンダリングでバンドルされていないディスプレイフォントが使えるとは想定しないでください。
4. フォーカル要素、端のアンカー、補助的なディテール、背景の処理を定義します。

情報密度は、依頼された形式とメッセージに合わせます。情報密度の例は、制作するフレームの参考であり、主張やシーンを創作したり、要素数を固定したりする許可ではありません。

スタイルやムードが指定されている場合は、/hyperframes-creative → references/visual-styles.md を読みます。ビジュアルを見てユーザーに選んでもらう必要があり、用意されたプリセットに合うものがない場合は、/hyperframes-creative → references/design-picker.md を読み、そこにあるインタラクティブなデザイン選択を実行します。

コンポジションの契約を守る

時間指定される要素には class="clip" を使用します。ルートと関連する祖先要素にはサイズを設定し、各コンポジションは window.__timelines に一時停止可能でシーク安全なタイムラインを1つ登録します。レンダリングは決定論的に行います。レンダリング時のネットワークフェッチ、時計、シード未指定の乱数は使用しないでください。

ワークフローを安全に参考にする

完成済みのワークフローに似ている場合は、そのジャンルの参考例を活用してください。まず npx hyperframes skills update <workflow-name> を実行します。参考にするのは、ストーリーの構成やセンスであり、非公開のスクリプト、パイプラインの状態、ディレクトリの契約ではありません。汎用ビルドは引き続きこのスキルが担います。

7. 完了

以下を満たした場合にのみ、実行は完了です。

• 依頼された範囲が実装されていること。
• flow: companion の場合、処理が実際に形になっていること。つまり、範囲に対応するだけでなく、すべてのシーンで引用されたブループリントやルールが実現され、音声のアイデンティティが示されていること（または無音を選択した旨が明示されていること）、開始と終了がデフォルトに任せず設計されていること。
• 組み込みの lint ステージを含め、npx hyperframes check が合格すること。
• デザイン仕様が存在する場合、/hyperframes-creative → references/design-adherence.md に照らしてデザインの遵守状況を確認していること。
• コントラストに関する指摘が解消されていること。
• 該当する場合、サブコンポジションのスナップショットを確認していること。
• 自律的な引き継ぎに、確認済みのコンタクトシートまたはスナップショットシートが含まれていること。複数シーンのシートでは、各シーンの中間時点を使用すること。
• 引き継ぎで、該当する場合は最終プレビューまたはレンダリング済み成果物を明示し、時間ベースの成果物については実際の長さを報告していること。
• 複数シーンの作業では、hyperframes-animation/scripts/animation-map.mjs を確認していること。
• レンダリング前に、ユーザーが Studio の最終プレビューを承認していること。
• レンダリングが依頼された場合、レンダリング済みファイルを検証していること。

最終承認後、../hyperframes/references/review-loop.md § 4 に従って、実行内容をレシピとして固定するかどうかを一度だけ提案してください。