pr-to-video

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

まず、このスキルを最新の状態に保ってください。実行前にユーザーへ確認してください： npx hyperframes skills update pr-to-video。すべて最新の場合はすぐに何もせず終了します。そうでない場合は、このスキルと、依存するコアドメインスキルを更新してから使用してください。

media-use：音声／画像／ロゴを取得する前に、/media-use を呼び出して、BGM／画像は HeyGen カタログから、効果音は Openverse から、ブランドロゴは公式ソースから取得してください。既存のアセットを登録するには、まず --adopt を実行してください。/media-use スキルを参照してください。ホストアプリが独自の音楽または効果音ツールを提供している場合は、音楽と効果音にそれらを使用してください。

PR から HyperFrames へ

このスキルを使って GitHub プルリクエストを取り込み、変更内容を理解し、コード変更を解説する動画を計画して、HyperFrames でフレームごとに作成します。入力は コード変更（gh で読み取ります）であり、ウェブサイトではありません。したがって、キャプチャの手順はなく、投稿者のアバター以外の実アセットもありません。

最初の窓口は /hyperframes です。 あなたがオーケストレーターです。各ステップを実行し、そのゲートを確認してから次に進んでください。このスキルは GitHub プルリクエスト（コード変更）向けです。それ以外の意図、「動画を作って」というだけの依頼、または不確かな場合は、まず /hyperframes を読んでください。すべてのルート判断は意図レイヤーが担い、BRIEF.md のない状態でここに到着した新規作成も、いずれにせよセットアップの冒頭ルールに従って処理されます。

あなたがオーケストレーターです。解決された外部の PROJECT_DIR で作業し、デフォルトでは呼び出し元のリポジトリで作業しないでください。ステップを順に実行し、各ゲートを通過してから次に進んでください。ユーザーの確認が必要なステップは、ステップ 0、ステップ 3、ステップ 6 です。ステップ 0 の前に ../hyperframes/references/brief-contract.md を読んでください。このファイルではゲートの種類と、BRIEF.md の flow／storyboard からステップ 3／4／6 のゲートを決定するモードを導き出す方法が定義されています。ステップ 5 以外のすべてのステップは自分で実行してください。ステップ 5 では、範囲を限定したフレームワーカーのプールを割り当てます。デザインやモーションのルールはここに記載しないでください。それらはフレームワーカーのサブエージェント、このスキルにある ../hyperframes-animation/rules/ と ../hyperframes-animation/blueprints/、および hyperframes-creative にあります。

ワークフロー：ステップ 0 セットアップ → hyperframes.json；ステップ 1 取り込み → capture/extracted/ ＋ assets/<login>.png；ステップ 2 デザインシステム → frame.md；ステップ 3 ストーリーボード／スクリプト → STORYBOARD.md および SCRIPT.md；ステップ 3.1 音声 → audio_meta.json；ステップ 4 ビジュアルデザイン → 拡充された STORYBOARD.md；ステップ 5 フレーム → compositions/frames/NN-*.html および index.html；ステップ 6 最終レンダリング → renders/video.mp4。

---

ステップ 0：セットアップ

目標：PR の参照情報（完全な URL、<owner>/<repo>#<N> 形式の参照、またはチェックアウト済みリポジトリでの「this PR」）を含む、確認済みのブリーフを用意して開始し、HyperFrames プロジェクトを作成して、ブリーフを永続化します。スタイルは常にコードエディトリアルです（ステップ 2 で固定し、質問しません）。

ブリーフは、ここで尋ねる質問ではなく、インテントレイヤーによって確定されます。 開始時のルールは次の順です。（1） BRIEF.md が存在する → 読み込み、何も尋ねません。ブリーフは確定済みで、flow／storyboard からモードが決まります（ブリーフの契約 § 1）。（2） BRIEF.md はないが、プロジェクトが存在する（ディスク上に hyperframes.json／STORYBOARD.md がある）→ ストーリーボードのフロントマターと記録済みの設定をもとに再開します。作成途中のプロジェクトについて、同じ質問を繰り返してはいけません。（3） どちらもない — ここへ直接届いた新規作成リクエスト → /hyperframes を読み込み、そのインテントレイヤー（references/intent-interview.md）を実行します。レシピと記憶済みのデフォルト設定を確認し、このルートの質問を行います。これには、全容が ../hyperframes/references/routes/pr-to-video.md に記載された、PR の規模から動画の長さを決める方針も含まれます。その後、確定したブリーフを返します。編集リクエストではこれらすべてを省略し、編集に進みます。

ほかの作業に入る前に、プロジェクトディレクトリを解決してください。ユーザーが指定したプロジェクトディレクトリはそのまま使い、指定がない場合はリゾルバーが出力する永続的な外部キャッシュの場所を使います。呼び出し元のリポジトリに videos/ を作成してはいけません。

PR="<url | owner/repo#N>"
if [ -n "${EXPLICIT_PROJECT_DIR:-}" ]; then
  PROJECT_DIR="$(node <SKILL_DIR>/scripts/project-dir.mjs --pr "$PR" --project-dir "$EXPLICIT_PROJECT_DIR")"
else
  PROJECT_DIR="$(node <SKILL_DIR>/scripts/project-dir.mjs --pr "$PR")"
fi
echo "PR-to-video project: $PROJECT_DIR"
node <SKILL_DIR>/scripts/preflight.mjs

機能の事前チェックは、フェッチ、ストーリー作業、音声、フレームのディスパッチより前に実行します。インストール済み CLI でこのスキルが必要とする検証コマンドを実行できない場合は、実行時間のコンテキストを消費する前に、アップグレードの案内を示して停止してください。

$PROJECT_DIR/hyperframes.json がない場合に限り、初期化します。ベース名は PR から付けます。たとえば acme-sdk-pr-1842 です。ワークスペース名やタイムスタンプは使ってはいけません。

npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=pr-to-video — init は、インストール済みスキルの最新版を GitHub で確認し、古くなっているものがあればグローバルのスキルセットを更新します。

以下の相対パスを使うコマンドは、すべて $PROJECT_DIR を作業ディレクトリとして実行します。明示的なサブシェルがない例は (cd "$PROJECT_DIR" && …) を意味します。呼び出し元リポジトリの作業ツリーを変更してはいけません。

初期化の直後に BRIEF.md を書き込みます（init は空でないディレクトリを拒否するため、初期化より前に書き込んではいけません）。内容は、インテントレイヤーで確定したブリーフを ../hyperframes/references/brief-format.md の形式に合わせたものにします。<MEDIA_DIR> は、インストール済みの /media-use スキルディレクトリとして解決します。次に、設定に基づく各回答を node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes . で記録します（対象となる項目は brief-format.md に記載されています）。インテントレイヤーがレシピを採用した場合は、node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes . --name <name> を実行します。これにより、そのレシピの frame.md がプロジェクトにコピーされます（その場合、ステップ 2 は省略されます）。また、ステップ 3 で下書きに使うひな形も返されます。レシピが補うのは回答であり、承認ではありません。レビューのゲートは引き続き適用されます。

セットアップを終える前に、サインイン状態を必ず表示します — npx hyperframes auth status を実行し、その出力を一字一句そのまま伝えてください。音声／BGM に HeyGen とローカルエンジンのどちらを使うか、またサインアウト中の場合はサインイン方法が表示されます。次のいずれかの分岐を適用します。

• 協調型： ユーザーのサインイン、または offline／go の明示的な選択を待ちます。
• 自律型： 状態を伝え、利用可能なローカルエンジンで続行します。

オフラインプロバイダーがないために必要な機能を利用できない場合、黙って省略してはいけません。障害要因を明示してください。この判断を別の質問に含めたり、リポジトリごとの .env にキーを書き込んだりしてはいけません。認証情報の管理とオフライン時の代替手段については、/media-use の references/setup-providers.md § Providers を参照してください。

ゲート： hyperframes.json と BRIEF.md が存在する。PR の参照情報がブリーフに記録されている。設定に基づく回答が記録されている（ブリーフの契約 § 2）。サインイン状態が表示されている（サインイン済み、またはオフラインで続行中）。

ステップ 1：PR を取り込む（キャプチャなし）

目的：PR の事実を取得し、情報源としてプロジェクトに取り込みます。ウェブサイトのキャプチャはありません。fetch-pr.mjs は gh を決定論的に実行します。ページネーション対応の gh api でファイル一覧を補完するため、大規模な PR でも約 100 ファイルで途切れません。また、書き込むのは capture/pr.json と capture/diff.patch のみです（一時ディレクトリは作成しません）。MERGED PR の場合は、最善の方法で shipped_version（および version_source）も解決して pr.json に記録します。これにより、最後のカードで実在するバージョンを示せるため、バージョンを捏造せずに済みます。その後、ingest.mjs がオフラインでそれらを合成キャプチャパッケージに取り込みます。

PR="<url | owner/repo#N | N>"

# Fetch the PR deterministically: runs gh, completes the files list via paginated
# gh api (so a big PR doesn't truncate at ~100 files), writes only capture/pr.json +
# capture/diff.patch — no scratch dir. gh auth / not-found / private errors exit 1 here.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-pr.mjs --pr "$PR" --out-dir ./capture)

# Offline transform → capture/extracted/{tokens.json (colors:[] → code-editorial palette),
# visible-text.txt (the brief), people.json (contributors, bot-filtered, name+login,
# avatarFile=assets/<login>.png)}.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/ingest.mjs \
  --pr-json ./capture/pr.json --diff ./capture/diff.patch --out-dir ./capture/extracted)

# The people front's one network step — download each contributor's GitHub avatar to
# assets/<login>.png for the credits close. Best-effort; always exits 0.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-people-avatars.mjs \
  --people ./capture/extracted/people.json)

fetch-pr.mjs が終了コード 1 で終了した場合（gh の認証エラー／見つからない／非公開）は、標準エラー出力を報告して停止してください。PR の内容を捏造してはいけません。ingest.mjs が終了コード 1 で終了した場合は、標準エラー出力を確認し（通常は pr.json の形式不正です）、修正して再実行してください（決定論的です）。fetch-people-avatars.mjs は常に終了コード 0 です。アバターが見つからなくても、作者の近くにクレジットが表示されないだけです。

people.json には、gh がすでに名前を取得した投稿者（PR 作成者、コミット作成者、mergedBy）の name が記録されます。それ以外（レビュー担当者／コメント投稿者／割り当てられたユーザー）は null です。gh pr view が返すのは、これらのユーザーの基本的な login のみだからです。ステップ 3 でクレジットの締めくくりを書く前に、そのフレームに実際に登場する 1～6 人について、null の名前を自分で解決してください：gh api users/<login> --jq .name（すでに gh を使用できるため、スクリプトを書く必要はありません）。GitHub にそのユーザーの公開名がない場合は、画面上では login を使用し、読み上げる文からその人を除外してください（story-design.md のクレジットのセクションを参照してください。ナレーションでは必ず名前を読み上げ、ハンドル名をそのまま読んではいけません）。

ゲート： capture/pr.json、capture/diff.patch、capture/extracted/tokens.json、capture/extracted/visible-text.txt、capture/extracted/people.json が存在し、PR の変更内容を明確な一文で説明できること。assets/<login>.png は可能な場合に取得します。不在でも失敗ではありません。

---

ステップ 2：デザインシステム

目的：コードエディトリアルのフレームプリセットを採用します。スクリプトによって、この動画の frame.md とキャプションスキンが生成されます。

スタイルは code-editorial（温かみのあるエディトリアル調。差分表示用に設計されたネイビーのコード画面）に固定されています。次を実行してください：

node <SKILL_DIR>/scripts/build-frame.mjs --preset code-editorial --hyperframes .

スクリプトは code-editorial プリセットの FRAME.md を frame.md にコピーし、capture/extracted/tokens.json にあるブランドトークンを反映するよう調整します（PR にはブランドトークンがないため、colors:[]／fonts:[] となり、コードエディトリアル独自のパレットを含む完成済みのデザインが維持されます）。また、プリセットのキャプションスキンを .hyperframes/caption-skin.html にコピーし、自己検証を行います（マッピングに不備がある場合は終了コード 1 で終了します）。終了コード 0 になったら、すぐに次へ進んでください。手動で編集してはいけません。

ゲート： build-frame.mjs が終了コード 0 で終了していること。frame.md が code-editorial プリセットから生成され、.hyperframes/caption-skin.html がキャプションスキンのソースとして存在すること。

ステップ 3：ストーリーボードとスクリプト

目標：PR を、承認済みのフレームごとの説明プランにまとめます。

../hyperframes-creative/references/story-spine.md（フックの表現、証拠より価値を先に示すこと、提案としてのストーリーボード、ソースを追跡できるビジュアル）、references/story-design.md、../hyperframes-animation/blueprints-index.md、../hyperframes/references/storyboard-format.md、../hyperframes/references/script-format.md を読みます。これらを使って STORYBOARD.md を作成し、ナレーションが必要な場合は SCRIPT.md も作成します。フロントマターの duration: はブリーフの length を設定します。これはおおよその目安であり、組み立て時に実際のカットが目安に対してどこに収まるかが報告されます。

PR のアーキタイプ（changelog / feature-reveal / fix-explainer / refactor-walkthrough）、PR に適したフレームタイプ、フック、説得の流れ、ビート、フレームごとの語数上限、クレジットの締めには story-design.md を使います。構成は差分のファイル順ではなく、ナラティブの設計から決めます。変更内容を説明し、差分を読み上げてはいけません。あくまで参考として、../hyperframes-animation/blueprints-index.md の役割→ブループリントのメニューを確認します。各ビートでは、候補となるブループリントが示す形でナレーションを書き、適合する候補があればその blueprint: ID を付けます（どのビートを設けるかはストーリーの意図に従います。形に合わせるためにビートを無理に設けてはいけません）。capture/diff.patch から実際の差分ハンクを 2～4 個取り上げ、それぞれ小さく読みやすいスニペットにします。各フレームの scene には、そのフレームで使用する code-* ブロックの名前を記載します。フレームに asset_candidates を含めてはいけません。ただし、assets/<login>.png のアバターを 1～6 個含む credits の締めは例外です。ストーリーボードとスクリプトのリファレンスで指定されている必須フィールドを正確に使用します。

ドラフトを作成したら、レビュー・ループのプラン確認を実施します。../hyperframes/references/review-loop.md § 1 に従い、プランを提案として提示し、2 つの質問をします。承認するか変更するか、および先にスケッチを作成するか（推奨）、スキップするかを尋ねます。フィードバックはチャットへの返信として届きます。承認されるまで繰り返します。これはチェックポイントのゲートです（ブリーフの契約 § 1）。自律モードでは質問する必要はありません。同じ概要を事前通知として投稿して先へ進みます。スケッチはビルドにまとめられ、1 つの質問を添えた最終プレビューはステップ 6 で提示されます。

ゲート： STORYBOARD.md が存在し、すべてのフレームに必須のナラティブフィールドがあり、ナレーションが必要な場合は SCRIPT.md が存在し、ユーザーがプランを承認していること（自律モードの場合は、概要が事前通知として投稿されていること）。

---

Step 3.1：音声

目標：承認済みのスクリプトからナレーション、単語ごとのタイミング、音楽、音声メタデータを生成します。

Step 3 の承認後に音声処理を開始します。バックグラウンドで実行し、その後 Step 4 に進みます。

実行前に、ユーザーの依頼に基づいてナレーションの音声を選んでください。 依頼で音声、性別、またはトーンが指定されている場合は、それに合う音声 ID を選び、--voice <id> を渡します。それ以外の場合、パイプラインのデフォルトは HeyGen では Marcia（女性）、Kokoro では am_michael です。そのため、「男性の声で」といった依頼は、フラグを渡さない限り反映されません。音声 ID はプロバイダーごとに異なります。Step 0 のサインイン状態で選ばれたプロバイダーに応じて解決してください。サインイン済みの HeyGen では node <MEDIA_DIR>/audio/scripts/heygen-tts.mjs --list（または GET /v3/voices?engine=starfish）を使用します。オフラインの Kokoro では <MEDIA_DIR>/audio/references/tts.md の音声一覧を使用します（男性は am_／bm_、女性は af_／bf_ のプレフィックス）。ユーザーが希望を示していない場合は、パイプラインのデフォルトより先に、記憶されている音声（brief contract § 2）を使用し、使用した音声を伝えてください。どちらにも名前がない場合に限り、--voice を省略します。この実行でユーザーが明示的に音声を選んだ場合は、その選択を記録してください（prefs.mjs record --key voice）。

node <SKILL_DIR>/scripts/audio.mjs --script ./SCRIPT.md --storyboard ./STORYBOARD.md --hyperframes . --out ./audio_meta.json --voice <voice-id> &

音声スクリプトは、ナレーション、単語ごとのタイミング、HeyGen の音楽ライブラリからの BGM 検索、タイミングメタデータを処理します。BGM のムードは、ストーリーボードの music: フィールドから取得します。これは HeyGen Audio API を使った検索であり、生成ではありません。また、TTS と同じ ~/.heygen 認証情報を使用します。プロバイダーの詳細については、../media-use/audio/references/tts.md を読んでください。ホストアプリ独自のツールで音楽や効果音を作成する場合は、ファイルを assets/ の下に置き、audio_meta.json ファイルに "source": "host" として記載します。音楽は bgm として { "path": "assets/…", "source": "host" } を指定し、ストーリーボードでは music: none とします。効果音は sfx エントリとして { "frame": <n>, "file": "assets/…", "offset_s": 0, "duration_s": <その長さ>, "source": "host" } を指定します。音声処理のたびにこれらを保持し、ホストの効果音があるフレームでは、検索した音声キューを追加しません。

ナレーションがなく、SCRIPT.md もない場合は、音声生成をスキップします。ストーリーボードに音楽のムードが設定されていれば、BGM は引き続き処理できます。

完全に無音であることを示す正式なマーカー（この音声モデルを再利用するワークフロー間で共通）：STORYBOARD.md の先頭の YAML ブロックに music: none があり、SCRIPT.md がなく、さらに sfx: キューもホスト音声もないこと。この組み合わせは、プロジェクトが無音であることを示します。つまり、ナレーション、BGM、SFX はありません。audio.mjs はこれを認識して何も生成しません（古い audio_meta.json があれば削除します。audio_meta.json がないことを assemble は無音として扱います）。そのため、このステップは問題なくスキップできます。ナレーションがなくても sfx: キューやホスト音声がある場合、映像は無音ではありません。audio.mjs は fetch-sfx が埋めるための audio_meta.json ファイルを書き込みます。ナレーションがある状態で music: none とした場合は、TTS は維持し、BGM のみをオフにします。この表記をそのまま使い、別のマーカーを独自に作らないでください。

ゲート： 音声ジョブが開始されているか、プロジェクトが無音として指定されていること（music: none、SCRIPT.md なし、sfx: キューおよびホスト音声なし）。

---

Step 4：フレームのビジュアルデザイン

目標：各ストーリーボードフレームに、ビジュアルの方向性、レイアウトの意図、モーションの選択を追加します。 まずストーリーボードシートのスケッチを作成します（共同作業の場合のみ）。 計画が承認されたら、スケッチ作業を実行してください — ../hyperframes/references/review-loop.md § 2（Step 3.1を待つ必要はありません。静止画にはタイミングを使わないためです）：各フレームの構図を自分で決めて、予定された開始位置に合わせてそれぞれを index.html に配置し、1回の実行ですべての静止画をスナップショットしてボード boards/storyboard.html（../hyperframes-creative/references/storyboard-recipe.md）を作成し、それぞれを built に設定してください。すべてのフレームが built になったら、レイアウトに関する質問を1つだけ行って一時停止し、ボードが確定するまで、指定されたフレームだけを修正します。仮置きの例：コードのビートでは、ファイル名と実際の差分行を数行含むシンプルなコードパネルを使います。code-* ブロックの接続はワーカーが担当します。その後でのみ、以下のビジュアルデザインを確定したレイアウトに適用してください。自律モードの場合、またはユーザーがStep 3でスケッチを省略することを選んだ場合は、この作業を省略し、Step 5でフレームを outline から animated に直接進めます。

STORYBOARD.md をその場で編集してください。別のストーリーボードは作成しないでください。色、書体、レイアウトの雰囲気、スタイルの基準には frame.md を使います。

references/visual-design.md、../hyperframes-animation/blueprints-index.md、references/motion-language.md、references/code-vocabulary.md、../hyperframes-animation/rules-index.md を読みます。手法（タイムコード付きショットシーケンス、インラインのレイアウト用語、コードビートの扱い）と必須の ## Video direction ブロックには visual-design.md を使います。各フレームのショット形状を選ぶには ../hyperframes-animation/blueprints-index.md を使います。コードビートごとに適切な code-* ブロックを選ぶには code-vocabulary.md を使います（diff = code-diff、リファクタリング = code-morph、新規コード = code-typing、…）。モーションには motion-language.md（モーション用語とモーションの原則）および ../hyperframes-animation/rules-index.md（有効なルール名）を使ってください。モーション名やブロック名、ブループリント名を独自に考案しないでください。

名称付きのルックをデザインする前に、最新のカタログを検索してください。 コードビートは code-vocabulary.md で扱いますが、それ以外は対象外です。ブリーフで指定されているその他すべてのルック、エフェクト、処理、トランジション（「CRT scanlines」、「glitch」、「film grain」、「shimmer sweep」、「confetti burst」など）について、npx hyperframes catalog --query "<the look, in plain English>" --json を実行し、STORYBOARD.md にそのルックを書く前に検索上位の結果を読みます。検索にインストールは不要です。プロジェクトも、事前の add も、アカウントも必要ありません。どのディレクトリからでも、ホストされたレジストリ全体（約400のブロックとコンポーネント）を対象に検索できます。見つけたブロック名をここに記載してください。Step 5では、ストーリーボードに記載されたブロックがすべて事前にインストールされます。検索しても適合するものが見つからなかった場合に限り、ルックを手作業で作成してください。

各フレームについて、visual-design.md の手法に従い、タイムコード付きショットシーケンスを STORYBOARD.md に記述します。フレームのブループリントを選ぶ（または組み立てる）際には、そのフレームの内容を反映させ、各Sceneの展開をナレーションに合わせて調整し、フレーム全体の長さを通して展開させます。最初にすべてを表示して、そのまま静止させることはしないでください。コードビートでは、code-* ブロックがフレームの focal です。 Sceneでは、コードそのもののアニメーションではなく（それはブロックが担当します）、ファイルやヘッダーの登場、対象の差分へのカメラ移動、行の表示など、周囲のコード編集画面を演出します。各コードフレームのフィールドの直後に ### Source excerpt を追加し、ワーカーがレンダリングする実際の差分のみを含む diff フェンスブロックを記述します（最大12行）。capture/diff.patch からこの場で該当箇所を選んでください。ワーカーがその差分全体を再度開くことは禁止されています。各Sceneのレイアウトとモーションはインラインで指定します（用語は visual-design.md と motion-language.md を参照）。動画全体に対する ## Video direction ブロックを1つ追加します。

ストーリー、スクリプト、transition_in、asset_candidates、PRのソースは変更しないでください。スケッチ作業でポーズを作る場合を除き、このステップではHTMLを記述しないでください。アセットのステージング手順はありません。実際に使うアセットはクレジット用アバターのみで、すでに assets/ にあります。 ゲート： すべてのフレームに、ナレーションに合わせて見せ方のペースが調整されたタイムコード付きショットシーケンスがあり、冒頭に情報を詰め込みすぎていません。コードフレームでは、focal として code-* ブロックを指定しています。## Video direction が存在します。共同作業の場合：スケッチシートが確認済みです。

---

ステップ 5：フレームを構築する

目標：ストーリーボードのすべてのフレームを HTML コンポジションとして構築し、再生可能な動画に組み立てます。

音声の生成を開始している場合は、ステップ 3.1 の音声が完了するまで待ちます。その後、長さを同期して効果音を取得します。無音の場合は、どちらもスキップします。

node <SKILL_DIR>/scripts/audio.mjs sync-durations --audio-meta ./audio_meta.json --storyboard ./STORYBOARD.md

node <SKILL_DIR>/scripts/audio.mjs fetch-sfx --storyboard ./STORYBOARD.md --hyperframes .

長さの同期は機械的に行います。実際のナレーションの長さを優先し、無音フレームは推定値を維持します。同期後の長さを手動で編集してはいけません。

ディスパッチする前に、STORYBOARD.md 全体で指定されたレジストリブロックを一度だけ事前インストールし、並列ワーカーによるレジストリの競合を防ぎます。

for b in <ストーリーボードで指定された各レジストリブロック>; do npx hyperframes add "$b"; done

ディスパッチする前に、../hyperframes/references/subagent-dispatch.md を読みます。対象範囲を限定したパケットと、ワーカーロールのペイロードを作成します。

node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJECT_DIR" --storyboard "$PROJECT_DIR/STORYBOARD.md"

パケットビルダーは、上流で選択された ### Source excerpt がないコードフレームをエラーにし、パケットのバイト数にも厳格な上限を設けています。また、_role.md（../hyperframes/references/frame-worker-core.md とこのスキルの sub-agents/frame-worker.md をそのまま連結したもの。ワーカーロール全体）も書き出します。ワーカーは合計で最大 3 人までディスパッチし、パケットのパス全体に割り当てを分散させます。各ワーカーのプロンプトには、_role.md と割り当てられたパケットのパスを含めます。ロール全文を貼り付けるか、そのパスを渡してください（どちらも同等です。ワーカーはまったく同じドキュメントから作業を開始します）。各ワーカーは、ロールを一度だけ読み、割り当てられた複数のフレームを順番に構築できます。ワーカーが読み取るのは、自分のパケットと frame.md のみです。STORYBOARD.md 全体、capture/diff.patch、capture/extracted/visible-text.txt を開いてはいけません。各ワーカーが書き込めるのは、割り当てられた compositions/frames/NN-*.html のみです。ワーカーは STORYBOARD.md を編集してはいけません。ディスク上に確認済みのスケッチがあるフレーム（共同作業での実行 — レビューループ § 3）については、ディスパッチ時のコンテキストでワーカーにその旨を伝えます。スケッチは既存の compositions/frames/NN-*.html であり、ワーカーは描き直さず、そのレイアウトにデザインを加えます（frame-worker core § 確認済みのスケッチがある場合）。

フレームの作成に失敗した場合は、既存のパケットに、バリデーターまたはリンターの具体的な指摘を添えて、そのフレームだけを再ディスパッチします。再試行は最大 1 回です。バッチ全体を再実行してはいけません。また、具体的な指摘なしに再試行してはいけません。

画面全体に広がる背景は、#root ではなく、class="clip" のレイヤーに配置します。 フレームの地色（カラー領域／グラデーション／グリッド）は、それ自体が全長の背景クリップです。#root／data-composition-id 要素に設定された background はフレームの表示区間に制限され、地色として確実に機能しません。そのため、暗いコンテンツが黒いホスト body 上に表示され、見えなくなることがあります。動画のベースとなる地色は、アセンブラーが frame.md の canvas の色をインデックスの #root に塗ることで設定します。（完全なルールとセルフチェック：../hyperframes/references/frame-worker-core.md。）

ワーカーから結果が返るたびに、そのフレームを STORYBOARD.md で animated にします。

音声のタイミングが確定したら、バックグラウンドでキャプションを作成し、インデックスを組み立てます。

node <SKILL_DIR>/scripts/captions.mjs build --storyboard ./STORYBOARD.md --audio-meta ./audio_meta.json --hyperframes . --out ./caption_groups.json &

node <SKILL_DIR>/scripts/assemble-index.mjs --storyboard ./STORYBOARD.md --hyperframes .

captions.mjs は、プロジェクトの .hyperframes/caption-skin.html（code-editorial のもので、ステップ 2 でコピー済み）を使用し、frame.md のブランドトークンを挿入します。captions: skipped (<reason>) は有効な結果です。assemble-index.mjs は、冪等なバックストップ処理として、assets/ のクレジット用アバターをステージングします。

ゲート： すべてのフレームが animated になっており（共同作業の場合：ステップ 4 でスケッチシートが確認済み）、index.html が存在し、キャプションが作成済み、または明示的にスキップされています。

---

ステップ 6：仕上げ

目標：組み立てた動画を確認し、ユーザーの承認を得て、最終版 MP4 をレンダリングします。

トランジションを挿入してチェックを実行し、レビューのために一時停止してから、レンダリングします。

node <SKILL_DIR>/scripts/transitions.mjs inject --storyboard ./STORYBOARD.md --hyperframes .

node <SKILL_DIR>/scripts/transitions.mjs verify --storyboard ./STORYBOARD.md --index ./index.html

npx hyperframes lint

npx hyperframes check

npx hyperframes snapshot --at <frame-midpoints>

snapshot はキャプチャしたフレームを 1 枚のコンタクトシート（.hyperframes/artifacts/snapshots/<id>/contact-sheet.jpg。コマンドがパスを出力します）にまとめます。ざっと確認し、明らかな問題がなければ先に進みます。ここで時間をかけすぎないでください。

コマンドが失敗した場合は、stderr を表示して停止します。復旧コマンドを次々と実行しないでください。自分で修正します。最も安全で手間の少ない方法で compositions/frames/NN-*.html を編集し、失敗したチェックを再実行します。

既知の誤検知 — 対応不要です。 check で、キャプションの強調表示された単語（セレクター #caption-word-* / .caption-line）に対し、約 1～4px の text_box_overflow エラーがいくつか報告されることがあります。キャプションのピルでは意図的にタイトな line-height（scripts/captions.mjs で一度だけ設定）を使用しており、overflow:hidden はありません。そのため、太い表示用グリフのインクが数ピクセル、ピル自体のパディングにはみ出しますが、実際にクリッピングされているわけではありません。これらは想定内として先に進んでください。キャプションの line-height を大きくしないでください（ピルが膨らみ、かえって悪化します）。text_box_overflow への対応が必要なのは、キャプションの単語ではなくフレーム要素（#el-NN-*）が報告されている場合だけです。

チェックに合格したら、ユーザーレビューのために一時停止します。レビュー手順の最後の確認（../hyperframes/references/review-loop.md § 4）では、最終 Studio プレビューを見せて、「今すぐレンダリングしますか、それとも変更しますか？」と 1 つだけ質問します。（自律実行の場合も同じ質問を 1 つだけ残します。ユーザーから依頼されていなくても、以下のコマンドでプレビューを開いてください。）その後、コンタクトシートとフレーム ID を添えて MP4 を納品し、修正の対象を特定のフレームに絞れるようにします。

プレビュー：npx hyperframes preview "$PROJECT_DIR" --background

ユーザーの承認後（自律実行モードでは、レンダリングするか変更するかの質問の後）にのみ、レンダリングします。

npx hyperframes render --skill=pr-to-video --quality high --output renders/video.mp4

ユーザーから依頼されない限り、レンダリング後に lint、check、snapshot を再実行しないでください。

ユーザーのレビューが終了した後（または、今後ライブ編集の予定がない場合はレンダリング後）、このプロジェクトのバックグラウンドサーバーだけを停止します。npx hyperframes preview "$PROJECT_DIR" --stop。レビュー待ちの間は、決して停止しないでください。

完了条件： レンダリング前に lint と check に合格し、スナップショットを確認済みであること。レビュー時にユーザーが承認していること（自律実行の場合は、チェックに合格し、納品物にコンタクトシートが含まれていること）。renders/video.mp4 が存在すること。最終返信には MP4 のパスと最終的な長さを記載します。

---

クイックリファレンス

フォーマット： 横長 1920x1080、縦長 1080x1920、正方形 1080x1080 — 出力先から決定します（ブリーフの仕様 § 2）。ストーリーボードの frontmatter でフォーマットを一度だけ設定します。

キャプチャ済みアセットを使うワークフローとの PR 差分： ステップ 1 のキャプチャはありません（gh CLI が PR を合成された capture/extracted/ パッケージに取り込みます — tokens.json + visible-text.txt + people.json）。実際のアセットは投稿者の assets/<login>.png アバターだけです（クレジットの締めで使用）。asset-descriptions.md とアセットのステージング手順はありません。コードのビートは、code-editorial のネイビーの Code Surface 上にある code-* レジストリブロックでレンダリングします。スタイルは常に code-editorial です。 バックグラウンドスクリプト： ワークフローには、scripts/ に次のスクリプトが含まれています。fetch-pr（gh を介して PR → capture/pr.json + diff.patch。大規模 PR に対応し、スクラッチ領域は不要）、ingest（→ 合成キャプチャパッケージ。オフライン対応）、fetch-people-avatars（コントリビューターのアバター → assets/）。さらに、共有エンジンとして、プリセットを採用してブランドに合わせて再構成し、frame.md + キャプションスキンを生成する build-frame、TTS、BGM、SFX、再生時間の同期を行う audio、captions、トランジションを挿入して検証する transitions、assemble-index があります。それ以外はすべて hyperframes CLI です。コードブロックは npx hyperframes add <name> でインストールします。

再利用可能でドメインに依存しないショット形状は ../hyperframes-animation/blueprints/ にあり（../hyperframes-animation/blueprints-index.md にインデックスされています）。code-* レジストリブロックは、コードビートの語彙集です（references/code-vocabulary.md）。

読むもの	確認するタイミング
[../hyperframes/references/brief-contract.md](../hyperframes/references/brief-contract.md)	ゲートの種類、BRIEF.md からのモードの導出、フィールドの意味。
[../hyperframes-creative/references/story-spine.md](../hyperframes-creative/references/story-spine.md)	ステップ 3：ストーリーの原則 — フックの表現、証拠より先に価値を示すこと、提案の形、ソースを追跡できるビジュアル。
[references/story-design.md](references/story-design.md)	ステップ 3：PR の説明を計画します。
[../hyperframes-animation/blueprints-index.md](../hyperframes-animation/blueprints-index.md)	ステップ 3：役割→ブループリントのメニュー。ステップ 4：ショットの形を選びます。
[../hyperframes/references/storyboard-format.md](../hyperframes/references/storyboard-format.md)	ステップ 3：STORYBOARD.md を作成します。
[../hyperframes/references/script-format.md](../hyperframes/references/script-format.md)	ステップ 3：SCRIPT.md を作成します。
[../media-use/audio/references/tts.md](../media-use/audio/references/tts.md)	ステップ 3.1：TTS プロバイダーを選択、または理解します。
[references/visual-design.md](references/visual-design.md)	ステップ 4：フレームのショットシーケンスを作成します（レイアウトの語彙も参照）。
[references/code-vocabulary.md](references/code-vocabulary.md)	ステップ 4 + 5：コードのビートに使う code-* ブロックを選択して記入します。
[references/motion-language.md](references/motion-language.md)	ステップ 4：モーションの語彙と原則。
[references/cut-catalog.md](references/cut-catalog.md)	ステップ 4-5：カットカタログ（ワーカーがフレーム内のつなぎ目を構築します）。
[../hyperframes-animation/rules-index.md](../hyperframes-animation/rules-index.md) + [../hyperframes-animation/rules/](../hyperframes-animation/rules/)	ステップ 5：引用したモーションに対応するローカルルールのレシピ本文。
[../hyperframes/references/frame-worker-core.md](../hyperframes/references/frame-worker-core.md)	ステップ 5：共有ワーカーの契約（パケットビルダーが差分の先頭に付加します）。
[sub-agents/frame-worker.md](sub-agents/frame-worker.md)	ステップ 5：ワークフローのフレームワーカー用差分。
[../hyperframes/references/subagent-dispatch.md](../hyperframes/references/subagent-dispatch.md)	ステップ 5：サブエージェントを安全にディスパッチします。
[../hyperframes-creative/frame-presets/code-editorial/FRAME.md](../hyperframes-creative/frame-presets/code-editorial/FRAME.md)	ステップ 2：コードエディトリアルのプリセット（固定スタイル）。