owainlewis/ai-reel-editor

リールを編集する

あなたは編集者です。reel CLIは機械的な作業を行います。クリエイティブな判断はすべてあなたが行います。 計画を立てる前に、docs/STYLE.md と docs/RULES.md を読んでください。RULES.md のルールは実際のユーザーノートから来たものであり、ここにある他のすべてのルールよりも優先されます。

1. セットアップ

npm run reel -- new <slug> <video> [--broll a.mp4 b.mp4]
npm run reel -- transcribe <slug>

• projects/<slug>/transcript.txt を最初から最後まで読んでください。transcript.json 内の聞き間違えた名前（ツール、企業、人物）を修正してください。発言内容は決して変更しないでください。
• checks/frame.jpg を確認し、顔の位置を測定します。フレームに対する割合（0〜1）で、中心のx座標、中心のy座標、頭の高さ（頭頂から顎まで）を測定します。これらは face に入力します。
• 映像に既に音楽が含まれている場合は、"music": false を設定します。

2. デザインの前にリサーチする

名前の出てきたツール、企業、リポジトリ、数字、主張はすべて、画面上に表示する前にそのソースと照合します。

• 一次情報源（リポジトリ、ドキュメント、企業のサイト）を見つけてください。それを読み、話者の発言を裏付ける事実をメモします。
• 話者がソースと矛盾することを言った場合は、作業を中止し、ユーザーにその旨を伝えてください。グラフィックで「修正」しようとしないでください。
• 数字、結果、引用、UI を決してでっち上げないでください。グラフィックには、発言された内容またはソースが示す内容のみを表示できます。

3. 実際のビジュアルを収集する

優先順位（STYLE.md 参照）：ユーザーのBロール、実際の製品やページ、公式ロゴ、次いでデザインされたグラフィック。

npm run reel -- capture <slug> <url> --name repo --width 1280 --height 1500
npm run reel -- capture <slug> <url> --name readme --width 520 --selector "article.markdown-body"
npm run reel -- fetch <slug> <logo-url> --name github.svg

• ページのクロームやヘッダーには1280ピクセル幅でキャプチャします。段落の場合、520ピクセル幅でキャプチャすると、テキストが携帯電話で読めるカラムに折り返されます。
• ロゴはブランド自身のサイト、リポジトリ、またはメディアキットから入手します。ロゴを再描画したり、近似的なものを使用したりしないでください。GitHub Organizationのアバターは公式ロゴとみなします。
• すべてのキャプチャをReadツールで確認し、フレーム内で強調表示する正確な矩形領域をメモします。
• キャプチャまたはダウンロードしたすべてのものは、そのソースとともに assets/ledger.json に記録されます。

Bロールライブラリ

Owain自身の映画的なショット（タイピング、作業中の様子、デスクの詳細）は broll/ にあります。これらはリールに「撮影された」という印象を与えます。

npm run reel -- index            # 新しいファイルをショットに分割し、レターボックスをクロップし、broll/index.json に書き込む
npm run reel -- broll typing     # クリップをリスト表示、最も一致するものから順に表示

• index の実行後、broll/sheet.jpg（または broll/.clips/<id>.jpg）を確認し、broll/index.json の各新しいクリップの description と tags を記入します。何が見えるかを説明し、その意味は説明しないでください。
• クリップは { "kind": "video", "src": "broll:<id>" } で使用します。validate がそれをプロジェクトにコピーします。
• Bロールは、人間的または抽象的なセリフ（「AIで構築しているなら」「それはローカルで動作する」など）に配置します。キャプチャやロゴは事実に基づく主張に使用します。Bロールは証拠としては使用しません。
• ショットはそのクリップの長さを超えてはなりません。超えた場合、validate がエラーを出します。各クリップはリール1本につき1回のみ使用します。

4. フォーマットを選び、ストーリーを計画し、それからショットを計画する

最初に format を設定します（docs/STYLE.md 参照）：

• ツール紹介（新しいリポジトリ、リリース、機能、または投稿）：react。ソースをウォークスルーするように計画します。すべての主張に対して、発言されている単語をハイライトしたキャプチャを用意します。Bロールは分割パネル内でのみ使用します。
• 仕組みの解説 または 私のセットアップ：mixed。

次に header を、フックとなる短いタイトルとして設定します（フレーム1の画面上のテキストです）。そして、各セクションが始まるショットに新しい header を設定してチャプターを計画します。split を選択します。テキストを含むキャプチャがリールの主役の場合は inset を、話者の伝え方が重要な場合は half を選びます。

projects/<slug>/edit.json を作成します（スキーマ：src/schema.ts）。最初に、頭の中または note で以下を決定します。

• フック（0〜3秒）： 視聴者が最初のフレームで見て、そのまま留まらせるもの。実際に動作している製品や、実際のものの名前を優先します。
• 証拠： 主張が本物であることを示す1つのショット（リポジトリ、ソース行、ページ上の数字など）。
• メカニズム： 仕組みの説明。図解またはソース自身の言葉をハイライトして示します。
• ペイオフ： 視聴者が今できるようになること。話者の顔で終わります。

次にショットの計画です。各ショットは、話し言葉のフレーズ（at）で始まり、順序通りに配置されます。経験則：

• 1ショットにつき1つのアイデア。平均1.2〜1.6秒。内部で何らかの明らかになる要素がない限り、2.8秒を超えるものはありません。
• リストの各項目、ステップ、ロゴはそれぞれ独自の at を持ち、対応する単語のタイミングで表示されます。
• レイアウトを混ぜます。証拠には分割、話者の確信を示すには全面、強調や最後のセリフにはパンチ、最も重要な1つのビジュアルにはメディア、Bロールをエッジツーエッジで表示するにはカットアウェイを使用します。
• グラフィックは例や関係性を示すものであり、キャプションを繰り返すものではありません。
• accents：リール全体で4〜6語、意味を伝える重要な単語です。

キャプチャのフレーミング

image ビジュアルの場合、from と to は画像座標の0〜1の範囲の矩形 [x, y, w, h] です。この矩形がパネルを埋めるように表示され、カメラは一方から他方へイーズイン・イーズアウトします。

• 最後はタイトに。validate は、ページのテキストがスマートフォンで読むには小さすぎる場合に警告を出します。
• highlight を at と共に使用し、まさに話されている単語の上にマーカーをスイープします。label でコールアウトタグを追加します。
• 矩形は、表示され続けなければならない領域です。カメラは矩形をパネルの形状に合わせて拡大し、その周りにページ全体を表示します。パネルの縦横比に完全に一致させる必要はありません。

5. レンダリング前に確認する

npm run reel -- validate <slug>   # タイミングを解決し、ショットテーブルを表示し、ハウスルールをチェックする
npm run reel -- stills <slug>     # 各ショット1フレーム -> checks/stills.jpg

checks/stills.jpg を確認します。各ショットについて自問します：スマートフォンサイズで読めるか？パネルを埋めているか？口の上に何かかかっていないか？何か新しいものを表示しているか？修正し、すべてのショットが合格するまで繰り返します。

6. レンダリングと確認

npm run reel -- render <slug>     # オーディオをミックスし、projects/<slug>/renders/final.mp4 をレンダリングする
npm run reel -- check <slug>      # カットのストリップ、開始フレーム、ラウドネス、単語チェックを行う

checks/opening.jpg（最初の2.5秒）と checks/cuts.jpg（各カットの両側のフレーム）を確認します。1フレームのフラッシュ、間違ったスタイルのキャプション、空のパネルがないか探します。ラウドネスは -14 LUFS、トゥルーピークは -1 dBTP 以下である必要があります。

ユーザーにMP4を送信します。何を確認したか、何を確認できなかったかを明確に伝えます（ミックスを聞くことはできないため、その旨を伝えます）。

7. ノートをルールに変換する

ユーザーが下書きに対してノートを提供した場合：

1. 編集を修正します。
2. 修正内容がどこに属するかを判断します。docs/RULES.md のルール、tools/ のチェック、または src/ のコンポーネントの変更のいずれかです。問題を機械的に検出または防止できる場合は、記述されたルールよりもチェックまたはコードの変更を優先します。
3. docs/RULES.md のログに行を追加します。ユーザーの言葉で書かれたノートと、変更内容を記録します。

同じノートが二度と必要になることがあってはなりません。