Rune-kit/rune

video-creator

目的

製品デモとマーケティングのための動画コンテンツ計画。タイミングマーク付きのナレーションスクリプトを作成し、シーンごとのストーリーボードを定義し、ショットリストを作成し、必要なアセットをリストアップします。完成した制作計画をファイルに保存します。このスキルは動画制作の計画を作成します — 実際の動画ファイルではありません。

呼び出し元（インバウンド）

• marketing（L2）：デモ/説明ビデオのスクリプト
• launch（L1）：製品デモビデオ

呼び出し先（アウトバウンド）

なし — 純粋な L3 ユーティリティ。

実行可能な手順

ステップ 1: 概要を受け取る

呼び出し元のスキルから入力を受け取る：

• topic — 動画の内容（例：「Rune プラグインデモ」、「機能Xのウォークスルー」）
• audience — 視聴者（例：「開発者」、「非技術系創業者」、「既存ユーザー」）
• duration — 目標の長さ（秒単位、例：60、120、300）
• platform — 公開プラットフォーム：youtube | twitter | tiktok | loom | internal
• output_path — 計画を保存する場所（デフォルト：marketing/video-plan.md）

プラットフォームから制約を導出する：

• YouTube：厳密な長さの制限なし、3分以上はチャプター推奨
• Twitter/X：最大140秒、最初の3秒でフック
• TikTok：最大60秒、テンポの速いカット、キャプション必須
• Loom：非同期向け、画面録画重視、音楽不要

ステップ 2: スクリプト

タイミングマーク付きのナレーションスクリプトを作成する。一行も書く前に、以下のナレーションクラフトの原則を適用する — 視聴者が聞くスクリプトは、オープニングと流れで成否が決まり、ショットリストではない。

構成：

• フック（0〜5秒）：注意を引くオープニング — 問題または価値を提示
• セットアップ（5〜15秒）：コンテキスト — 誰のためのものか、何を学べるか
• デモ/本文（15秒〜[duration-15秒]）：シーンに分割されたメインコンテンツ
• CTA（最後の10秒）：行動喚起 — 次に何をするか（リポジトリにスター、サインアップ、シェア）

各セクションのフォーマット：

[00:00] フック
ナレーション：「...」
画面：[視聴者が見るもの]

[00:05] セットアップ
ナレーション：「...」
画面：[視聴者が見るもの]

ステップ 3: ストーリーボード

シーンごとの内訳を作成する：

各シーンについて：

• シーン番号と名前
• 長さ（秒単位）
• ビジュアルの説明（画面に表示されるもの）
• ナレーションテキスト（ステップ2から）
• トランジションタイプ：カット | フェード | ズーム | スライド

例：

シーン3: ライブデモ — インストールコマンド
長さ: 12秒
ビジュアル: ターミナルウィンドウ、入力されたコマンド "npm install -g @rune/cli"、出力がスクロール
ナレーション: 「たった一つのコマンドで数秒でインストールできます。」
トランジション: カット

ステップ 4: ショットリスト

録画または表示する必要があるものを正確に定義する：

タイプ別に分類：

• 画面録画: キャプチャする各画面状態（URL、アプリの状態、操作）をリスト
• コードスニペット: 表示する各コードブロック（ファイルパス＋行範囲、またはインライン）
• 図/スライド: 必要な各静的ビジュアル（タイトル、キーポイント）
• ターミナル: 録画する各コマンドシーケンス

フォーマット：

ショット1 — 画面録画
  URL: https://myapp.com/dashboard
  操作: 「新規プロジェクト」をクリック → フォーム入力 → 「作成」をクリック
  長さ: 約8秒

ショット2 — ターミナル
  コマンド: npm install -g @rune/cli && rune init my-project
  期待される出力: [表示される内容を説明]
  長さ: 約10秒

ステップ 5: 必要なアセット

録画を開始する前に必要なすべてのアセットをリストする：

• スクリーンショット（どのページ/状態）
• コードスニペット（どのファイル、どのセクション）
• 図（トピック、スタイル：フローチャート | アーキテクチャ | 比較表）
• スライドの背景やタイトルカード
• サムネイル（プラットフォームに基づく寸法：YouTube 1280x720、Twitter 1200x628）

ステップ 6: レポート

Write を使って完全な動画計画を marketing/video-plan.md（または指定された output_path）に保存する：

# 動画計画: [topic]

- **プラットフォーム**: [platform]
- **目標時間**: [duration]秒
- **視聴者**: [audience]
- **作成日**: [date]

## スクリプト
[ステップ2からの完全なタイムスタンプ付きスクリプト]

## ストーリーボード
[ステップ3からのシーン別内訳]

## ショットリスト
[ステップ4からのすべてのショット]

## 必要なアセット
[ステップ5からのチェックリスト]

## プラットフォームに関する注意
[ターゲットプラットフォームの制約とヒント]

次に、呼び出し元のスキルにサマリーを出力する：

## 動画計画が作成されました

- ファイル: [output_path]
- シーン数: [count]
- ショット数: [count]
- 推定録画時間: [n] 分
- 準備するアセット: [count] 個

### 次のステップ
1. 計画にリストされたアセットを準備する
2. ショットリストの順にショットを録画する
3. ストーリーボードを参考に編集する

ナレーションクラフト（スクリプトが興味を引くか退屈させるかを決定する）

デモスクリプトは人が聞くものであり、スライドを読むものではありません。これらの原則は、魅力的なスクリプトを凡庸なナレーションから区別します — ステップ2で、どの行よりも先に適用してください。

9つの原則：

1. 痛み起点のオープニング。 視聴者の最大の痛みか、すでに進行中の統計から始める（「もしあなたがよく…しなければならないなら」、「このリポジトリは9kのスターを持っていて…」）。絶対に平坦なカタログ型のオープニング（「今日は…について見ていきます」、「これは…するツールです」）ではダメ — 問題を挙げず、スクロールを止める理由を何も提供しない。
2. コントラスト構造。 「XだけでなくY」、「Xではなく、Y」、「XのようだがYがある」。コントラストは注意を引く。
3. 二人称での呼びかけ。 「あなたはすぐにわかります」、「もしMシリーズMacで開発しているなら…」。視聴者を引き込む。
4. 指示語による即時性。 「ここで」、「これ」、「タイムライン上で今」。具体的で現在形。
5. 具体的な固有名詞、専門用語はそのまま。 実際のファイル、コマンド、競合他社（「Final Cut」、「Cursor」、「ffmpeg」）の名前を挙げる。一般的な用語（「あるAIツール」、「そのフレームワーク」）は禁止。専門用語を不自然な言葉に無理に翻訳しない。
6. 定量化されたソーシャルプルーフ — 一度だけ。 「9k以上のスター」。スター、フォーク、イシューを別々の断片として続けて羅列しない。
7. 短い節、コンマでつなぐ。 「トリミング、置換、再生成ができます。」一文で、箇条書きの断片ではない。
8. 欠点を強みに。 正直な制限を一つ述べるか、「これを使うべきではない人」を述べる。これは動画の中で最も信頼を築く行であり、リテンション機能であり、埋め草ではない。
9. ユースケースで締めくくる。 「ぜひチェックしてみてください」ではなく、具体的な視聴者のシナリオで閉じる。

名前と番号が付いた「武器」。 各差別化要因にタイトルと番号（「武器01/02」）を与える。2〜3の自明でない具体的な点（正規表現、ガード、アルゴリズム、フォールバック）を見つける — 一つの正確で驚くべきメカニズムが、一般的な機能リストに勝る。

シーン間のコネクタ。 最初のシーン以降の各シーンは、前を参照する言語的なコネクタ（「その核心は…」、「具体的には…」、「ただし注意…」）で始める。これにより、動画全体がN個の個別のキャプションを連続して読んだものではなく、一つのモノローグとして機能する。完全なスクリプトを順に声に出して読んでみる — もしつながりのないサウンドバイトのように聞こえたら、書き直す。

自動不合格パターン — 次のいずれかが現れたらスクリプトを却下する：

• ❌ フック／問題／解決策／CTA の穴埋めが孤立した断片として扱われている
• ❌ サイドバーの統計（スター/フォーク/イシュー）が別々の一行シーンとして扱われている
• ❌ すべての文が独立した箇条書きとして再開される（「X は一つのパイプラインを実行する。Y は書く。Z はナレーションする。」）
• ❌ 一般的な能力の主張（「フル機能」、「非常に強力」、「コミュニティで人気」）
• ❌ 製品ではなく README/リポジトリを説明している
• ❌ 「ぜひチェックしてみてください」／「ご視聴ありがとうございました」で締めくくっている

ボイスオーバー: TTSセーフナレーション（ナレーションが機械音声の場合）

ナレーションが TTS エンジン（AI 音声、人間の読み上げではない）によって合成される場合、話される narration と画面のテキストは別々のチャンネルです — 一方は聞かれ、もう一方は読まれます。それぞれを独立して最適化し、未加工のスラグ、数字、記号を TTS にそのまま渡して、音声が正しく推測することを期待してはいけません。（以下のベトナム語の例はパターンを示しています。対象の TTS エンジンが話す言語に合わせて、同じ音声表記と数字の単語への置換を適用してください。）

数字 → 話し言葉（多くのニューラル TTS エンジンは生の数字を誤読する可能性があります — VN の例）：

形式	TTS の誤読	書くべきもの
バージョンの小数点	GPT 5.5 → 「5.5」	GPT ごーてんご
統計の小数点	82.7%	はちじゅうにてんななパーセント
スペック	200MP	にひゃくメガピクセル
価格	$5	ごどる
倍率/パーセント	2x / 30%	にばい / さんじゅっパーセント

英語/ブランド名 → ナレーションでは音声表記、画面では正確な綴り:

用語	ナレーション（聞こえる）	表示（読まれる）
README	りーどみー	README
ffmpeg	えふえふえむぺぐ	ffmpeg
GitHub / repo	ぎっとはぶ / れぽ	GitHub / repo
API / GPT	えーぴーあい / じーぴーてぃー	API / GPT

話されるナレーションから削除するもの： 絵文字、URL（「ぎっとはぶ どっとこむ すらっしゅ…」と言う）、記号（→ & % $ # / @）、スラッシュコマンド（「プラグインインストールコマンド」と言う）、文中のファイル拡張子（「YAMLファイル」と言う）、キャメルケースの識別子、省略記号 … とダッシュ —（TTS はこれらを誤読する — 二つの短い文に分割する）。すべての文を . または ? で終えて自然な間隔を作る。

専門用語はそのまま、自然な話し言葉の登録で。 知識のある友人が話すように書く — ただし標準的な技術用語（「コミット」、「エンドポイント」、「プロンプト」）は通常の形式を維持する；無理に翻訳すると不自然で意味が失われる。現地の言葉が実際に使われている場合のみ翻訳する。

実際に制作される場合の動画制作ノート（計画だけでなく）:

• 全シーンで1つの音声、1つのプロバイダー — 途中で音声やプロバイダーが変わると違和感がある。
• 最初に TTS の長さを測定し、各シーンのビジュアルを実際の音声の長さに合わせる — 長さを推定してからレンダリングすると A/V のずれが生じる。
• カラオケ形式のキャプションは、ショートフォーム（TikTok/Reels/Shorts）における最高のプロ品質のシグナル：画面下部中央に、音声と同期して単語ごとに埋まるキャプション、キーワードが強調される。ミュート自動再生での理解に加えて、最も強力な「プロフェッショナル」な合図 — そのための下部キャプションバンドを確保する。

注記

このスキルは動画制作の計画を作成します。実際の録画と編集は、人間または専用の画面録画ツールが行う必要があります。

出力形式

動画計画は marketing/video-plan.md に保存され、スクリプト、ストーリーボード、ショットリスト、アセットチェックリスト、プラットフォームに関する注意事項を含みます。シーン数、ショット数、推定録画時間を含むサマリーレポート。詳細なテンプレートについては、上記のステップ6レポートを参照してください。

制約

1. 動画パラメータ（長さ、解像度、フォーマット）を生成前に確認する必要がある
2. ユーザーの確認なしに妥当なファイルサイズを超えてはならない
3. プロジェクトのアセットディレクトリに保存する必要がある

注意すべきエッジケース

このスキルの既知の失敗モード。完了と宣言する前にこれらを確認すること。

失敗モード	深刻度	緩和策
プラットフォームの制約が適用されていない（例：Twitter の最大140秒超過）	HIGH	ステップ1：プラットフォームから即座に制約を導出する — それ以降のすべてに影響する
スクリプトに CTA セクションがない	MEDIUM	CTA（最後の10秒）はすべてのスクリプトで必須 — 長さに関係なく例外なし
ファイルに保存しない（口頭出力のみ）	HIGH	制約3 + ステップ6：output_path への書き込みは必須 — 口頭のみ＝永続性なし
実際の動画ファイルの納品を約束する	MEDIUM	明記：このスキルは計画を作成する — 実際の録画は人間が行う
痛み起点のフックではなく、平坦なカタログ型オープニング（「今日は…について見ていきます」）	HIGH	ナレーションクラフト #1：視聴者の最大の痛みから始める — 問題を挙げないオープニングは2秒でスクロールされる
未加工のスラグ/数字/記号が TTS 用ナレーションに残されている（「README」、「82.7%」、「5.5」）	HIGH	ボイスオーバーセクション：話されるナレーションを音声表記＋数字は単語に書き換える；正確な綴りは表示チャンネルにのみ残す
スクリプトが N 個のつながりのないサウンドバイトとして読める	MEDIUM	ナレーションクラフトのコネクタ：最初のシーン以降の各シーンは前を参照して始める — 完了と宣言する前にスクリプト全体を声に出して読む

完了条件

• プラットフォームの制約が特定され、長さ/フォーマットに適用された
• ナレーションクラフトが適用された — 痛み起点のオープニング、シーン間のコネクタ、1つ以上の欠点を強みにする記述、自動不合格パターンなし
• ナレーションが TTS で話される場合：話し言葉チャンネルでは数字は単語、ブランド名は音声表記、表示には正確な綴り
• タイミングマーク付きのスクリプトが書かれた（フック、セットアップ、デモ/本文、CTA）
• トランジションを含むシーン別のストーリーボードが作成された
• ショットリストがタイプ別に分類された（画面録画、ターミナル、コード、図）
• 必要なアセットのチェックリストが生成された
• video-plan.md が output_path にランタイムのファイル編集機能を使って書き込まれた
• シーン数、ショット数、アセット数を含む「動画計画が作成されました」レポートが出力された

コストプロファイル

入力約500〜1500トークン、出力約500〜1000トークン。スクリプト品質には Sonnet。