nolan は何をしますか？
監督はカメラを回して願うだけでは終わらない。彼らはショットを絵コンテにし、フレーミングし、完全なテイクを撮影する。nolanはソフトウェアデモに対してそれを行う。機能をストーリーボードに変え、画面上の実際のアプリを操作し、製品マネージャーがユーザーに製品を見せるようにすべてのステップをナレーションし、シーンごとにクリーンな動画をキャプチャする。
出力はデモであり、スモークテストではない ― ランディングページに載せたり、顧客に送ったりできる種類のクリップであり、初めて見る人でも「何が」起こっているのか、そして「なぜそれが重要なのか」を理解できる。
このスキルを使うタイミング
実際の仕事が「このプロダクトが何かを行っている様子を、これまで見たことのない人のために、視聴可能な動画として制作する」ことである場合に使用する。それには、ローンチクリップ、機能紹介、ランディングページのヒーロービデオ、オンボーディングチュートリアル、リリースノートのGIFが含まれる。
フローをテストするためにはこれを使わない ― それはE2Eテストであり、簡潔でヘッドレスであるべきだ。nolanはその逆、つまり人間の視聴者のための可読性、ペース配分、ナレーションを最適化する。
ワークフロー ― 3つの段階
| 段階 | あなたが依頼する内容… | nolanが生成するもの | 参考資料 |
|---|---|---|---|
| 🎬 ストーリーボード | "機能Xのデモを計画して" | シーンごとのストーリーボード(JSON): タイトルカード、キャプション、正確なクリック/タイピング、待つべきもの | reference/storyboard.md |
| 🎥 録画 | "録画して" | シーンごとに1つの.webm、実行中のアプリに対してライブで操作、タイトルカードと字幕キャプションを重ねて生成 | reference/recording.md |
| ✨ ポリッシュ | "これを視聴可能にして" | レビューされ、再撮影されたテイク: 修正されたペース、完全なアクション、読みやすいキャプション、修正されたフレーミング | reference/polish.md |
段階は連鎖する: ストーリーボード → 録画 → 確認 → ポリッシュ → 再録画。ストーリーボードが正本であり、録画はそれに基づいて決定論的に行われる。
4つの指針（非交渉、すべての動画で必須）
これらがデモをスクリーングラブから区別する。必須である。
-
プロダクトマネージャーの声であって、スモークテストではない。 ユーザーにとっての価値をナレーションする ― これにより何ができるようになり、なぜ良いのか ― 決してテストの仕組みについて語らない。すべてのキャプションは、PMが顧客に製品を案内しているように読める。
reference/pm-voice.md参照。 -
画面上の日常的で親しみやすいコンテンツ。 一般の視聴者がすでに理解しているインプットだけをUIに入力する ― 通常の質問、実世界の例（「オートミルクを買う」「同僚へのお礼状」）。ニッチな専門用語、内部コード名、視聴者が解読しなければならない「異質な」概念は決して使わない。親しみやすさが最優先。
-
まず見せて、それから語る。 すべてのシーンは全画面のタイトルカード（製品+シーン名）で始まり、組み込まれた字幕キャプション（上部バナー）が各ステップをリアルタイムでナレーションするため、どの視聴者も迷うことがない。
reference/captions.md参照。 -
実際のアプリでの完全なテイク。 実際の製品をライブで操作する ― 目に見える人間らしいペースのタイピングと実際のクリック ― そして各アクションが完全に終了するのを待ってから次に進み、その後読み取れるようにポーズする。途中で回答を切り取ったり、遷移を中断したりしない。長さは完全性に奉仕する。
標準手順
- デモの範囲を決める。 どの製品、どの機能、どのURLで提供されているか、視聴者は誰か？アプリが実行中で到達可能であることを確認する（nolanはライブアプリを撮影する。モックはしない）。
- ストーリーボード。
storyboard.jsonをドラフトする ― アイデアごとに1シーン、それぞれにタイトルカード、順序付けられたステップ（type / click / select / wait）、PMの声でのキャプションを含める。assets/storyboard-template.jsonを雛形として使用する。プロンプトは一般的に保つ（§2）。 - セレクタのドライラン。 本番撮影の前に、ストーリーボードがターゲットとするプレースホルダー/ロール/テキストが実際にDOMに存在することを確認する（間違ったセレクタはテイク全体を無駄にする）。
reference/recording.mdで堅牢な選択について説明している。 - 録画。
scripts/record.py storyboard.json [scene ...]を実行する。キャプション/タイトルカードのオーバーレイを注入し、各シーンを操作し、完了を待ち、シーンごとに1つの.webmをストーリーボードのout_dirに保存する。 - 確認してポリッシュする。 各指針を
reference/polish.mdに対して確認する ― クリップされているものはないか、キャプションに専門用語はないか、タイピングは人間らしく読めるか、すべてのアクションは完了しているか？ストーリーボードを修正し、影響を受けたシーンのみを再撮影する。 - 納品する。 ファイルがどこに配置されたか、サイズ/時間、シーンごとの1行説明を報告する。必要に応じてポスターフレームやGIFを提供する。
nolanが想定するセットアップ
- Python + Playwright (
pip install playwright && playwright install chromium)。scripts/record.pyは同期APIとrecord_video_dirを使用して.webmをキャプチャする。 - 実行中のアプリ がマシンから到達可能なURLにある（ローカル開発サーバー、または撮影許可のあるデプロイ環境）。
- 現実的で機密性のないデモデータがアプリにロードされている ― 指針§2と
SECURITY.mdのデータに関する注記を参照。実際の顧客データや機密情報を決して撮影しない。 - オプション ― 音声ナレーション。 デフォルトではデモは無音（キャプションが担う）。人間らしい音声のナレーションを追加するには、ストーリーボードに
voiceブロックを追加し、ステップにvo行を追加する。これには ffmpeg (brew install ffmpeg) とTTSプロバイダーが必要 ― ElevenLabs / OpenAI / Deepgram（APIキー、最も人間らしい）、Piper（オフライン、オープンソース）、macOSsay（無料、ロボット的）、またはcommandテンプレートを使った任意のツール。reference/narration.md参照。
詳細は reference/recording.md を参照。ハーネスの詳細、オーバーレイ技術、ストーリーボードのステップリファレンスについて説明している。
ナレーションの追加（オプション）
ストーリーボードに voice ブロックがない限り、ナレーションはオフである。誰かがオーディオ/ナレーション/「人間らしく聞こえるように」を依頼した場合:
- どのプロバイダーを使うか尋ねる。 本当に人間らしいオーディオには、クラウドプロバイダーを使い、ユーザーがAPIキーを持っている（または追加する）ことを確認する:
ELEVENLABS_API_KEY、OPENAI_API_KEY、またはDEEPGRAM_API_KEY。また、commandを自身のTTSツールに指定することもできる。 - キーがない場合、無料/オフラインのフォールバックを提供する（Piperは品質良好、macOS
sayはゼロセットアップだがロボット的）― または"provider": "auto"を使用して利用可能な最良のものを使用する。 - どちらも希望しない場合、
voiceを省略する（または"provider": "none"）― 動画は従来通り無音で録画される。
その後、キャプションと同じPMの声で vo 行を書き、通常通り録画する。record.py が音声を合成し、シーンごとにミックスする。詳細: reference/narration.md。
出力の原則
- シーンごとに1つの動画、
NN-slug.webmという名前で、シーンを個別に再撮影できるようにする。 - ハンドオフでは、視聴可能な結果（各クリップが何を示すか）を最初に示し、その後に仕組み（パス、サイズ、再録画方法）を示す。
- 1つの長いクリップより、いくつかの短く完全なシーンを優先する ― 再撮影や再利用が容易。
- テイクを短く切らざるを得なかった場合やキャプションがプレースホルダーの場合は、その旨を正直に伝える ― 「シーン3はまだ再撮影が必要」という正直な報告の方が、クリップされたデモを納品するより優れている。