url-to-motion-design

URLからモーションデザインへ

誰かが気に入った映像が、Filのモーションシーンライブラリに新しいシーンとして生まれ変わります。同じルックとモーションのアイデアを保ちながら、Fil独自の言葉で表現し、元のブランドの痕跡は残しません。この一連の工程は、2026年11月5日に最初から最後まで一度実行されました（Xの3分間のローンチ映像から、キャンバス上の9つのシーン、うち4つが8/10、上映ページとMP4まで）。このスキルは、落とし穴を修正したその工程です。

パス：<skill>はこのフォルダー、<repo>はfacet-studioのチェックアウト、<run>は実行フォルダー（<repo>/qa/<slug>/、未追跡）です。

1. ソースを取得する

node <skill>/scripts/fetch-source.mjs "<url>" <run>/source

Xの投稿はapi.fxtwitter.com（投稿自体の動画とテキスト）経由で取得し、YouTubeとVimeoはyt-dlp経由、直接リンクはそのまま使います。 source.json（テキスト、作者、長さ）を読んで、映像の内容を把握します。

2. すべてのショットを見つけ、最良の5〜10本を選ぶ

node <skill>/scripts/shots.mjs scan <run>/source/source.mp4 <run>/scan

<run>/scan/sheets/にある1fpsシートをすべて確認します（1fps_<start>.jpgのタイルkは、秒数start+kを示します）。隣にあるcuts.txtも確認してください。以下を選びます。

• モーショングラフィックスのみ：アニメーションする文字、図表、UI、データ、パーティクル、コラージュ。人物の顔出しや通常の映像は除外します。
• 重複なし（オーナーの言葉：「シーンは繰り返し使えないようにする」）：各種類から1つずつ選びます。同じデバイスを映したショットが2つある場合（白と暗色のノードマップ、2つのパーティクル球体、2つのフォトコラージュなど）は、より優れた方を残します。ルックが同じでもアイデアが異なる場合（塔とグリッドなど）は両方残せます。
• 各5〜10秒、実際のカットで区切られていること。5秒未満のショットは除外します。長い連続区間の中にソフトなトランジションが隠れている場合があります。境界が不明瞭なときは、0.2秒のストリップを確認します（ffmpeg -ss <t> -t 2.4 -i src -vf "fps=5,scale=320:-1,tile=6x2" -frames:v 1 x.jpg）。
• 最良の5〜10本を選び、仕上がりの質とアイデアをFilにどれだけ活かせるかで順位を付けます。 picks.json（[{id, name, a, b, hero, what}]、idは短く、セクションごとの接頭辞を付けます。例：pg-tower）を書き、次に：

node <skill>/scripts/shots.mjs pick <run>/source/source.mp4 <run>/picks.json <run>

overview.jpgと、ヒーロー静止画をすべて確認します。トランジションの途中のフレーム（2つのキャプションがクロスフェードしている、モーションブラーがかかっている、単語が半分だけ置き換わっているなど）の場合は、別の時間を選びます。SendUserFileで概要画像と静止画を送信します。

スクリーンショットを先に見たいと言われた場合は、ここで止めてください。 構築を始める前に確認します。構築にはクレジットではなくエージェントが何時間もかかりますが、判断するのは依頼者です。

3. 実行環境をセットアップする

• references/builder-brief.mdをもとに<run>/BRIEF.mdを作成します。セクション名（ソースのブランド名は使わず、ルックを表す一般的な名前）、独自の言葉で説明したルック、すべてのシーンで使うフォントファミリーを記載します。また各シーンについて、id、長さ（ショットの長さ、5〜8秒）、メッセージの種類（feature、number、statement）、ショットのモーションをFilの世界に取り入れる最初のアイデアを記載します。事実に基づく内容のみを使ってください。
• ラボを起動します（references/lab.md）：lab/server.mjs用のlaunch.jsonエントリー、preview_start、scripts/render.mjsのスモークテストを設定します。アプリ内ブラウザーのみを使用してください。
• フォルダー：<run>/scenes/、<run>/out/、<run>/keep/、<run>/judges/。

4. ヘルパーと構築する

汎用ヘルパーを3つバックグラウンドで動かし、2〜4シーンずつ担当させます。グラウンド（明るいデータ、明るいプロダクト、暗色）ごとにまとめ、それぞれに<run>/BRIEF.mdと、そこに記載されたすべての内容を読むよう指示します。また、自分のファイルだけを編集し、シーンごとに1行で報告するよう伝えます。作業中はランナーを起動したままにします（lab.md）。そうしないと、ここに時間がかかります。

5. ブラインド評価し、修正し、繰り返す

python3 <skill>/scripts/panel.py setup <run> <tag> <id,id,…>     # sheets + two anchors, shuffled
# two fresh general-purpose agents, each: read judges/<tag>/JUDGE.md, Read every sheet, write judges/<tag>/judgeN.jsonl, read nothing else
python3 <skill>/scripts/panel.py tally <run> <tag>

• ヘルパーから報告があり次第、そのシーンを評価します。全員の報告を待たないでください。評価したすべてのバージョンを、変更が加わる前に keep/<id>-<tag>.html（および対応するシート）にコピーし、報告後にヘルパーが編集していないことを確認します（cmp）。
• 8点で合格です。 keep/<id>-pass-<tag>.html として保存し、ヘルパーには今後一切触れないよう伝えます。
• 8点未満の場合：評価コメントを一字一句そのまま伝え、自分の所見を一行と修正案（references/seven-to-eight.md）を添えます。レイアウトのせいにする前に、自分でシートを読んでください。シートのセルの高さを読み違えたせいで、1ラウンドを無駄にしました。
• 点数が下がったバージョンは却下し、より良いバージョンをベースに戻します。評価コメントでアイデア自体が2ラウンド続けて指摘された場合は、同じ見た目で新しいアイデアを試します。7点の評価済みバージョンが6つほどになったら、そこで止めてオーナーに確認します（19ラウンド目では「7点のままにする」を選びました）。
• 評価者によって約1点の差が出ます。基準となる例から、今回の評価がどれほど厳しかったかを判断します。

6. キャンバスに載せる

references/publish.md：すべてを収められるサイズの空セクションを用意し、それぞれにスコアを名前に含めたCode／モーションノードを1つずつ配置して、詳細なメモを付けます。安価なヘルパーにページを書かせ、文字数を確認し、8点に届かなかったシーンには評価済みの最良バージョンを載せ、キャンバスのログに1行記録します。 無料：generate は使わないでください。

7. 動画で見せる

依頼されていないもの：上映ページ（scripts/screening.mjs → localhost でテスト → Artifact）と、音声付きの実際のMP4（scripts/video.mjs、シーン1分あたり約12分）。オーナーから「動画を見せて」と2回頼まれました。2回目はライブページでは足りず、ファイルが必要でした。

全体を通して守るルール

• コピーではなく、スタイルです。 見た目、配色、文字の雰囲気、カメラ、モーションの表現だけを参考にします。元ネタのブランド、製品、ロゴ、文言、人物、写真、パートナーロゴ、主張、正確なレイアウトは決して使いません。唯一のロゴはFilの立方体（public/favicon.svg のものをそのまま使用）です。元ネタの映像は参考用であり、公開しません。
• Filに関する事実だけを正確に使います（references/scene-contract.md、Words）。
• 合格基準は、新規の評価者2人によるブラインド評価で8点です。低い方の点数を採用し、足りない点を正直に伝えます。
• 評価を記録します：すべての評価コメントを、ラボの scores.jsonl に1行ずつ記録します。
• 製品の変更はないため、facet-studio でバージョン、変更履歴、コミットは作成しません。スキル自体の変更は ~/.claude/skills と MengTo/Skills に反映します。

報告

表は1つにまとめます。シーン、評価者、キャンバス上の内容（合格、または最良バージョンと不足点）、キャンバスのリンク、上映ページのリンク、動画ファイルを記載します。 次に、不足点と改善につながるものを記載します（通常、磨き込みではなく新しいアイデアです）。