cassieliang6709/tech-explainer-video

技術解説動画

三つの関門、各関門でユーザーが明確に「OK」と言った場合のみ次の関門に進みます。ユーザーのグローバル設定にある「確認不要で実行」は、これらの三関門には適用されません。これはユーザーがこのスキルに特別に要求したレビュープロセスです。ユーザーが「まだナレーションを入れないで/まだやらないで」と言った場合は、現在のフェーズで停止します。

デフォルト値（ユーザーから指定がなければこれを使用し、script.md の front matter に書き込みます）：

• ターゲット層：Pythonを書けるが、関連コースの内容はほぼ忘れている大学生。書き方は references/kepu-style.md に従います：具体から抽象へ、「もし自分で設計するなら」、1枚の物理図を全編通して使い、各エピソードの新用語は6つ以内；レジスタ、ソースコードレベルの詳細は各エピソード末尾の「アドバンスト」章に
• 目標：視聴後、PyTorchで実装できるようになること
• 構成：三つのパート、数学的理論 → 使用するPyTorchツール → 統一コーディング
• 各エピソード内部は「総→分→総」：冒頭で今回のエピソードで答える質問とセクションマップを示し、本編でセクションごとに展開（コーナーにロードマップと現在のセクションのハイライトを表示）、最後に各セクションを一文でまとめ、次回予告
• 尺：各エピソード8～12分（2026年10月24日ユーザー変更：エピソード数を減らし、投稿数を抑え、プラットフォーム制限に引っかかりにくくするため）、一つのテーマは通常2エピソード、最大3エピソード
• 比喩：許可するが、一つのポイントだけ：一文で言い終えたらすぐ本題に戻る、一つの概念につき最大一つ（kepu-style.md 第5条）
• 音声：voice: volc（Volcano Engineプリセット音声 zh_female_vv_uranus_bigtts）；~/.volc_tts.env に認証情報がない場合、tts.pyが自動で edge-tts の暁伊（Xiaoyi）にフォールバックし、その旨を通知

フェーズ0：資料収集

ユーザーがノート（例：Obsidian）に言及した場合は、まずそれらを見つけて熟読し、ノートの構造、結論、数値を基本とします。

フェーズ1：アウトライン（対話内で提示）

最初の行に、プロジェクトを一言で定義する：「この回で、Xの人にYを理解させる」。各エピソードにはさらに一行のカバーフック＋右側ビジュアル（references/cover-guide.md 参照）を追加し、アウトラインと一緒にレビューします。 references/outline-template.md に従って簡潔なテーブルを作成：各章で解決する問題、新しい概念、実装するコード、尺、および分割案と説明しない内容。 まず references/kepu-style.md を読んでください。冒頭、テンポ、用語、結論は references/script-guide.md の「冒頭の公式」「テンポ」「用語と敷居」「結論の公式」に従ってデザインします；アウトラインでは各クライマックスがどの章にくるかを明記します。 数学パートを書く際は、最初に計算目標（例：out_i = Σⱼ aᵢⱼ vⱼ）を示し、そこから各コンポーネントを導き出し、ドット積、softmax、スケーリングがすべて「必要だから登場する」ようにします。

フェーズ2：コード → 逐語台本 → チェック → 批注 → 確定稿

執筆原則：最初に設計の動機を説明し、次にメカニズム、最後に結果を説明します。「どんな問題があったのか → 設計者は何を解決したかったのか → なぜこの方法を選んだのか → どのように機能するのか」を優先的に明確にします。補足の手順、例、必要な正確性を加えることは許容されますが、現在の原理を理解するために必要な新しい概念だけを導入します；新しい用語が最初に登場するときは、既存の知識や具体的な例を使って説明します。アドバンスト章は、その章で想定される知識ベースに合わせて調整します。

1. チュートリアルコード py/tutorial.py を書き、実際に実行し、show(key, value) を使って py/values.json をエクスポートします。画面上のすべての数値、形状、True/Falseはここから取得します。
   • 小さな例に説明可能な意味を持たせたい場合は、手動で重みを設定し、コードコメントとナレーションの両方で「手動設定、実際のモデルは訓練に依存」と説明します。
   • 「なぜ」を示す場合は、実際の比較を使用します：例えば、softmaxあり/なしでの結合則の allclose、スケーリング前後の softmax ヤコビアンのノルムなど。
2. references/kepu-style.md と references/script-guide.md に従って script/script.md（フォーマットは下記参照）を書き、2つのセルフチェックリストを順に確認します。 各「画：」行には、視聴者にどのような変化が見えるか、およびこの図が何の理解に役立つかを明確に記述します；まず表現目標を定め、制作ツールは固定しません。画面はウェブキャンバス、Remotion、Manim、Blender、またはより適切なツールで実現可能で、具体的な選択は決定稿後にショットごとに行います。数値、コード、形状を使用する必要がある画面は、引き続き py/values.json、py/tutorial.py と一致している必要があります。 エピソードごとの尺計算：各エピソードのナンバリング行の文字数 ÷ 4.5 ÷ 60 に、約0.5分のチャプターカードと間隔を加え、12分を超える場合はこの段階で分割を調整します（ナレーションができてから長すぎることに気づかないように）。
3. 初稿完成後、順にゼロベースチェック、ファクトチェック、言語ブラッシュアップを実施します： 3b. ゼロベース敷居チェック（必須）：別のエージェントを起動し、それに script.md と「あなたはPythonを書けますが、このトピックの授業はほぼ忘れています」という一文の設定だけを与えます。 コードもノートも与えません。そのエージェントに行ごとに次の項目をマークさせます：①理解できない単語や推論の飛躍；②一文に新しい情報が多すぎて、戻って見直す必要がある箇所；③画面の説明とナレーションが一致していない箇所。 具体的にどのステップの説明が不足しているかを指摘するよう要求し、特に「問題 → 設計動機 → メカニズム → 結果」の流れで理解できるかを確認します。不足している手順、例、または必要な正確性を補うことを提案できますが、本筋と関係のない新しい概念を導入して詳細を補わないようにします。修正は項目ごとに行い、同じ条件でもう一度チェックし、①と②のマークがなくなるまで繰り返します；③も修正する必要があります。修正リストを記録し、納品時にユーザーに渡します。アドバンスト章は、その章で想定される知識ベースに基づいてチェックします。 3c. ファクトチェック（必須）：別のエージェントを起動し、それに script.md とノートを与え、事実誤認または誤解を生じさせる可能性のある記述のみをマークさせ、その根拠を説明させます；知識ポイント、境界条件、または追加の詳細の補足は要求しません。教育的な単純化は許可します；視聴者が単純化された表現を厳密な定義と誤解する可能性がある場合は、ナレーションで「ここでは簡略化しています」と簡単に説明します。修正時は、同じくらいシンプルで正確な表現を優先し、限定詞を積み上げないようにします。3bと矛盾する場合は、正確でありながら理解しやすい表現を探します；事実誤認はそのままにせず、正確性が説明の本筋を覆い隠さないようにします。ファクト修正が理解や画面に影響を与えた場合は、該当する3bのチェックをやり直します。 3d. humanizer-zh スキルを使って、ナンバリング行と「読：」行を一文ずつブラッシュアップします（AI臭さを除去）。数値、用語、コード、「画：」行の意味は保持し、知識ポイントを勝手に追加/削除しない。ブラッシュアップ後、コード結果、画面説明、ナレーションの一貫性を再確認し、各エピソードの尺を再計算します。
4. ファイルをユーザーに送信し（SendUserFile）、ユーザーに文の下に > を付けて批注（コメント）を書いてもらうよう依頼します（Obsidianの > [!批注] も可）。 Obsidianで批注したい場合は、ユーザーのvaultにコピーし、修正後に読み戻します。
5. 批注を処理：項目ごとに修正 → 処理済みの批注行を削除 → 対話内で各項目をどのように修正したかをリストアップ → 再度ユーザーに確認を依頼し、確定と言われるまで繰り返します。
6. 確定前はナレーションを入れず、本番用の画面も制作しません。複雑なショットの実現可能性を検証するために、短いサンプルを作ることは可能です；サンプルは逐語台本のレビューの代わりにはなりません。

script.md フォーマット

---
title: Attention → MHA → GQA
subtitle: 数学的理論からPyTorch実装まで
audience: 一定のコンピュータ基礎知識を持つ大学生
voice: volc
volc_speaker: zh_female_vv_uranus_bigtts
volc_resource: seed-tts-2.0
episodes: ch0,ch1,ch2,ep1_end | ep2_start,ch3,ch4,ep2_end | ep3_start,ch5,ch6
episode_titles: 第一話タイトル | 第二話タイトル | 第三話タイトル
---

## ch0 | オープニング
1. 字幕原文、一文ごとに画面のビート。
   - 読：TTS読み方（字幕と異なる場合のみ記述；記号は読み方に書き換え、「行」(háng) と読む「行」は「航」と表記）
   - 画：この文で画面上に何が現れるか（必須、画面エージェントはこれに従って実装）
> 批注：ユーザーがここに書く

## ep1_end | 次回予告
1. 次回は……
   - 画：EP1 終了カード

• チャプターID：ch0, ch1, …；分割エピソードのオープニング/エンディングには epK_start / epK_end を使用し、画面は汎用EpCardで自動生成され、新しい文もユーザーのレビュー対象となります。
• 総分総：epK_start には2～3文：①今回のエピソードで答える質問 ②「この回ではNつのことを説明します：……」（今回のチャプターと一対一対応）； epK_end には2～3文：各章一文の結論 + 次回予告。第1話のオープニングチャプター（ch0）も同様に、今回のエピソードマップを含める必要があります。 front matter の episodes がマップ内のセクションを決定し、セクション名は各章のタイトルが使われます。
• 字幕は手動で短文に分割する必要はなく、tts.pyが句読点に基づいて22文字幅以内の短いセグメントに自動分割します。

フェーズ3：動画生成

ショットごとに、原理を明確に説明できる制作方法を選択：2Dの関係性、コード、データにはWeb Canvas、Remotion、またはManim；空間構造やカメラワークにはBlenderなどの3Dツールを使用できます。また、より適切な新しいツールを使用しても構いませんが、特定のツールを使用するために説明の複雑さを増やさないでください。既存の template/ はRemotion合成と納品パイプラインです；他のツールで制作したショットは、最初にビデオまたは画像素材として出力し、そのパイプラインに統合でき、字幕、ナレーション、ビートの同期が保たれることを検証した上で、本番チャプターに使用します。references/visual-guide.md と references/agent-brief.md 内のコンポーネント、パス、コマンドはRemotionチャプターにのみ適用され、他のツールはそのレイアウト、配色、実データ、画面セルフチェックの原則を継承します。

1. template/ をユーザー指定のディレクトリ（デフォルトは ~/Videos/<トピック>、まず確認する）にコピーし、py/、script/ を配置します。 依存関係は一箇所にのみインストール：シリーズ（複数のプロジェクトを同じ親ディレクトリ、例：~/Videos/nudgecode-アルゴリズム/<章>/ に配置）の場合、親ディレクトリに一度 node_modules をインストールし（templateのpackage.jsonをコピーして npm install）、各プロジェクトは ln -s ../node_modules node_modules でシンボリックリンクを作成します；単一プロジェクトの場合は、プロジェクト内にインストールします。 npm install は同時に一つだけ実行します。並行実行するとパッケージが破損する可能性があります。インストール後、node_modules/react-dom/index.js が存在することを確認します（npmキャッシュでこのパッケージが破損することがあり、ファイルがない場合は別のプロジェクトから同じバージョンをコピーします）。
2. python3 tools/md2json.py（未処理の批注があると拒否）→ python3 tools/scaffold.py → python3 tools/tts.py これにより public/audio/*、src/timeline.json が生成されます。ナレーションはキャッシュされ、変更された文のみが再合成されます。
3. 自分でオープニングと第1章を最初に制作し、画風を確立します（最も難しいショットを最初に；テンポ、トランジションは references/plotome-lessons.md を参照）。Remotionショットは node tools/stills.mjs ch1 && tools/sheet.sh ch1 でチェックします；外部ツールで制作したショットは、元の素材と統合後の合成フレームをチェックし、プレビューをユーザーに送信します。 シリーズ内で画風が既にユーザーに確認されている場合（例：同じシリーズの最初のプロジェクト）、別途ユーザーに確認することなくそのまま続行します。 stills.mjsは out/bundle を再利用し（tools/bundle.mjs、ソースファイルが変更された場合のみ再バンドル）、毎回 $TMPDIR に約90MBのバンドルディレクトリを新規作成することはありません。
4. ユーザーの承認後、残りのチャプターを複数のエージェントに1つのメッセージで同時に振り分けます（各エージェント1～2章）：
   • Remotionチャプター：references/agent-brief.md を埋めてプロジェクトルートディレクトリに AGENT_BRIEF.md として作成し、references/visual-guide.md を VISUAL_GUIDE.md としてコピーします。外部ツールのショットは別途、素材のフォーマット、尺、ファイルの場所、Remotionへの統合責任を定めた簡潔なタスク説明を書き、ChN.tsx のみの変更を許可する制約は適用しません。
   • ナレーションが変更された場合は、関連するエージェントにSendMessageで変更内容（どの文が変わったか、タイムラインが更新されたこと）を通知します。
5. すべてのチャプターが戻ってきたら、メインセッションで各チャプターの合成フレームを順にチェック：重なり、字幕への影響、画面と「画：」の一致、数値が values.json から来ているか；外部素材については、インポート後の尺とビートも確認します。
6. npx tsc が通ったら、バックグラウンドで tools/render.sh を実行します：エピソードごとに out/epK.mp4 + out/epK.srt + out/covers/epK.jpg を出力し、-16 LUFSに正規化します。レンダリング時間はビデオ1分あたり約1分です。 レンダリング中はオーディオとコードを変更しないでください：ミキシングは最後のステップでオーディオを読み込むため、途中で上書きすると新旧のオーディオが混ざります。 render.sh は全機ロック（lockf /tmp/remotion-render.lock）を使用して、同時に一つのエピソードのみレンダリングすることを保証します：複数のプロジェクトを同時にレンダリングしても速くならず（CPUは既にフル稼働）、メモリとディスクを余分に消費するだけです。複数のプロジェクトで同時に render.sh を起動することは可能で、自動的にキューイングされます。
7. カバー：references/cover-guide.md に従い、各エピソードに src/covers/CoverEpK.tsx を作成し、src/covers/index.ts に登録します（黒背景、フックを大きい文字 + 黄色背景でハイライト、右側に大きなビジュアル）；render.sh が自動で out/covers/epK.jpg を出力し、登録されていないエピソードはデフォルト版が使用されます。すべてのカバーを1枚の画像にまとめてユーザーに送信します。個別に再出力：npx remotion still out/bundle cover-epK out/covers/epK.jpg。
8. 納品：SendUserFile を使用して、各エピソードのmp4、srt、カバー、py/tutorial.py を送信します。ユーザー自身にsrtを読んでもらい、問題を発見してもらうように依頼します。
9. 公開が必要な場合は、video-publish スキルに移行します。公開前に references/plotome-lessons.md のコンプライアンスチェックリスト（AIタグ付け、音楽ライセンス、クレジット表記）を確認します。

シリーズ一括制作（複数プロジェクトの並行処理）

• 同時に開くセッションは3～4つに制御します：増やしすぎるとすぐに利用上限に達し、Volcano TTSも同時実行制限超過を報告します（tts.pyにはバックオフリトライ、同時実行2が実装済み）。
• 並行処理は台本作成と画面制作に限定；レンダリングは render.sh の全機ロックでキューイングします。
• ディスク：各章の out/bundle は約90MB、スクリーンショット out/check は数十MB、完成品は各エピソード十数MBです。新しいバッチを開始する前に df -h を確認し、 $TMPDIR/remotion-webpack-bundle-* は古いスクリプトの一時バンドルで、削除可能です。
• ユーザーが「レンダリング完了 → 直接アップロード → 完成品を削除」に同意した場合は、video-publish の「バッチパイプライン」を参照してください。

メインセッションスケジューリングパイプライン（2026年10月30日～11月3日運用、2記事ずつ処理）

1. 台本作成フェーズエージェント（各記事に1つ、2記事同時）：アウトライン → tutorial を実際に実行し values.json をエクスポート → 逐語台本 → ゼロベースチェック（別エージェントを起動、最大8ラウンド、最終ラウンドで全面的に修正）→ ファクトチェック（別エージェントを起動、ノートと照合）→ humanizer → エピソードごとの尺計算 → templateのコピー、node_modulesのシンボリックリンク作成 → md2json / scaffold / tts → AGENT_BRIEF.md、VISUAL_GUIDE.md、共有物理図コンポーネント src/lib/<名前>.tsx の作成（まずレイアウト定数を定義）→ ch0、ch1の制作。報告には「ノートと実測の不一致点」をリストアップします。
2. メインセッションでch0/ch1の画像確認、画風に問題がなければそのまま続行し、ユーザーを待ちません。
3. 画面fan-out：references/agent-brief.md を埋めて共有のbriefを作成し、/tmp/claude-501/brief_<記事>.txt に書き込みます（2記事目はsedでパス/コンポーネント名/ロック名を置換し、「本プロジェクト補足」を追加）、 各エージェントのプロンプトは「まずReadでbriefを完全に読み、厳密に従ってください。あなたはchX、chYを担当します」の一文だけ、各エージェント2～3章、カバーは最後のエージェントに任せます。1つのメッセージで同時に起動します。
4. 既知の問題を収集：各画面エージェントが戻ってきたときに、報告された「既知の問題 / values.jsonにない数値 / 修正後に再確認していないもの」を記録します。
5. 全編レビューエージェント（各記事に1つ、テンプレート references/review-brief.md）：手順4で収集した問題を「既知の修正項目」として項目ごとに書き込みます。
6. レンダリング：2記事それぞれバックグラウンドで tools/render.sh を起動し、全機ロックで自動キューイング；バックグラウンドのuntilループで out/ep3.mp4 の出現を待ちます。
7. スポットチェック（メインセッション自身が行い、報告は信用しない）：各エピソード ffmpeg -af volumedetect（通常のmeanは約-19dB、max ≤ -1.2dB）； 各記事から一つのエピソードを選び -vf "fps=1/60,scale=480:-1,tile=4x3" でグリッド画像を作成し、Readで確認；out/covers/ の3枚すべてが存在することを確認します。
8. アップロード：out/parts/P<k> <フック>：<トピック>.mp4 のハードリンク + out/upload_meta.md（概要の補足文を含む）を作成し、video-publish の「既存原稿に追記」に従ってキューイングします。アップロード後、PROGRESS.mdとカンバンを更新し、概要の段落をユーザーに送信します。

利用上限到達 / 中断

• 利用上限に達すると、実行中のすべてのエージェントが強制終了されます。復旧後、SendMessageで各エージェントに「続行」と送信すると、コンテキストを保持して作業を再開します；新しいエージェントを起動しないでください（重複作業や相互上書きの原因になります）。
• 同時実行エージェント数は～12以内に制御します（2記事 × 5～6の画面エージェント）。

ノートと実測の不一致

• ナレッジベースのノート（vault）は読み取り専用です。実測とノートが一致しない場合、動画は実測に基づいて説明し、報告で項目ごとにユーザーにリストアップし、ユーザーがノートを修正するかどうかを決定します。

確定後の修正

• ナレーションの修正：script.mdを修正 → md2json → tts（変更された文のみ再合成）→ 影響を受けるチャプターの画面をチェックします。
• 文の数が変わると画面がずれる可能性があります：既に画面ができているチャプターでは、主に言い回しを変更し、文の追加・削除は行いません；内容を追加する必要がある場合は、新しいエピソードのチャプター（例：epK_start）として追加します。
• 画面エージェントは visual に従ってのみ実装し、疑問があればメインセッションに報告し、自分でナレーションを変更しない。

音声

• Volcano Engineプリセット音声（デフォルト、voice: volc）：zh_female_vv_uranus_bigtts、リソース seed-tts-2.0、GQAの回でユーザーが選択、edge-ttsより明らかに高品質です。 front matter に volc_speaker がなければこれを使用します。認証情報は ~/.volc_tts.env（設定済み）にあり、VOLC_APPID / VOLC_TOKEN のみ必要です；オプションで VOLC_SPEED 話速（1.0 標準）。
• 音声変更：front matter に volc_speaker: <音声ID> を記述します。プリセット音声は自動で seed-tts-2.0 を使用；S_ で始まるクローン音声は自動で seed-icl-2.0（または env 内の VOLC_RESOURCE）を使用します。 volc_resource で明示的に指定することも可能；v1 と書くと旧バージョンのインターフェースを使用し、その場合はさらに VOLC_CLUSTER（デフォルト volcano_icl）を設定できます。
• ユーザーのクローン音声（env 内の VOLC_SPEAKER_ID、S_ で始まる）は現在 resource ID is mismatched with speaker エラーを報告するため、Volcanoコンソールで音声バージョン、トレーニングステータス、所属アプリIDを確認し、動作確認ができるまでは使用しないでください。
• envファイルの内容は印刷しないでください。新しいプロジェクトでは、まず --only で一つのエピソード内の数文を合成して試聴し、その後全編を合成します。
• edge-tts（代替）：voice: zh-CN-XiaoyiNeural、他のオプション：YunxiNeural、YunyangNeural、XiaoxiaoNeural。Volcano Engineの認証情報がない場合、tts.pyは自動で暁伊を使用します。
• 音声変更はtts.pyを再実行するだけで、画面はビートに合わせて自動調整され、スポットチェックで確認できます。

英語ナレーション（2026年11月3日）

• edge-tts en-US-AndrewMultilingualNeural：ユーザーが9つの音声を試聴して選択。無料、キー不要ですが、Edge読み上げの非公式インターフェースを利用しています：レート制限/切断の可能性あり（ttsはリトライが必要）、商用利用の可否が不明確、インターフェースが変更された場合は交換が必要です。front matter voice: en-US-AndrewMultilingualNeural。
• Volcano seed-tts-2.0 の en_male_tim_uranus_bigtts、en_female_dacey_uranus_bigtts も利用可能（代替）；seed-tts-1.0 の *_mars_bigtts 英語音声はこのアカウントでは403エラー（未開通）。中国語音声vvも英語を読めますが、アクセントが顕著です。
• 試聴：同じ～20秒の英語オープニング文を、各音声でmp3を出力し、ffmpeg concat（各音声の後にapad 1.2秒）で繋いだ合集をユーザーに送信します。

中日バイリンガル（試験運用中）

• 試験プロジェクト ~/Videos/知識庫/llm-13-rag-agent-en：新しく書かれた英語口語ナレーション（中英翻訳ではない）、各文に中国語訳付き、下部に2行字幕（上：英語、下：中国語やや小さい）、画面ラベルは英語。
• 字幕コンポーネントとmd2jsonの具体的な変更方法は、試験運用終了後にこことtemplateに書き戻します。
• 英語版は中国語の合集に追加しないでください；公開先（B站の新規原稿 / YouTube）はユーザーが決定します。

ファイル一覧（template/）

ファイル	役割
tools/md2json.py	script.md → script.json（批注チェック、分割エピソード解析）
tools/scaffold.py	チャプター用プレースホルダーコンポーネントと src/chapters/index.ts を生成
tools/tts.py	一文ごとにナレーション、短い字幕に分割、timeline.jsonを書き出し；edge-tts / Volcano Engineをサポート
tools/stills.mjs + sheet.sh	各文の80%地点でスクリーンショットを撮り、3×3のグリッド画像に結合（SCALE=1でフルサイズ）
tools/render.sh	エピソードごとにレンダリング + 字幕結合 + ラウドネス正規化
src/lib/beat.tsx	ビート同期（useBeat）、チャプタータイトルカード、字幕
src/lib/ui.tsx	CodePanel / Matrix / Fade / Tag / H / Tex（KaTeX数式）
src/lib/EpCard.tsx	分割エピソードのオープニング/エンディングカード
src/lib/Cover.tsx + src/covers/	カバーコンポーネント（CoverFrame / Hl / CodeVisual / BigNumber）+ 各エピソード特注カバー登録
src/lib/algo.tsx	アルゴリズム系コンポーネント：配列セル、dict、traceテーブル、問題カード
tools/bundle.mjs	一度バンドルして out/bundle を再利用
src/lib/library.tsx	オプション：テンソル「図書館」比喩コンポーネント（Building / Corridor）

参照ドキュメント

• references/script-guide.md：逐語台本の書き方；outline-template.md：アウトラインテーブル
• references/visual-guide.md / agent-brief.md：画面仕様、画面エージェント説明
• references/cover-guide.md：カバー仕様
• references/plotome-lessons.md：テンポ、トランジション、音楽、コンプライアンス（plotome参考）
• references/production-retro-2026-10.md：nudgecode 13章一括制作の振り返り、ハマりどころと対策
• references/production-retro-2026-11.md：ナレッジベース2記事ずつのスケジューリングパイプライン振り返り
• references/review-brief.md：全編レビューエージェントテンプレート
• rethinkfun-style.md / cishoon-style.md：ユーザーが好きなUP主の分析

ハマった穴

• macOS say は機械的すぎるので、edge-ttsを使用。
• コードと記号は「読：」内で読み方に書き換える；多音字「行」(háng) は「航」と表記。
• 実際のモデルの数字を説明する前に、その構造を確認する（例：Llama-2-70B自体はGQA、64ヘッドで10GBと言う場合「MHAと仮定して」と断る）。
• ランダム初期化のアテンションは平均的すぎて意味がない：手動で重みを設定するか、乱数シードを変えてコントラストの明確なものを選ぶ。
• スクリーンショットは tools/stills.mjs（一度だけバンドル）を使用し、remotion still よりはるかに高速；初回レンダリングではヘッドレスChromeをダウンロードする。
• Bashで入力なしの cat > file を書かない。stdin待ちでハングする。
• スクリーンショットは各文の80%地点：80%以降に出現するアニメーション（バツ印、後から出る大きな文字）はキャプチャできないため、個別にキャプチャするか、出現時間を早める。
• 画面エージェント並行時に、他人のチャプターの構文エラーでバンドルが失敗する：1～2分待ってリトライし、他人のファイルを変更しない。
• レビューエージェントが古いスクリーンショットを「クリーンアップ」したことがある：briefには「いかなるファイルも削除しない（スクリーンショットの上書きは可）」と明記必須。
• ディスク：各プロジェクト約0.5GB、完成品は各エピソード十数MB；レンダリング中にディスクがいっぱいになると No space left on device エラーが発生する。新しいバッチを開始する前に df -h を確認し、～15GB未満の場合は、まず削除可能なグループ（各種ツールキャッシュ、conda cleanなど）をリストアップしてユーザーに提示し、削除にはユーザーの同意を得る。
• チャプタータイトルカードとオープニング/エンディングカードにより、各エピソードに約10秒追加されるため、TTS実測尺 + 10秒で完成品尺を推定する。
• 画面エージェントが src/covers/index.ts を登録することがある：これはカバー作成に必要なため、許可する。
• バックグラウンドのレンダリング待機に pgrep -f render.sh を使用しない：待機コマンド自身のコマンドラインにもその語が含まれるため、pgrepが常に自分自身にマッチし、何時間も空回りする。out/epK.mp4 の出現（またはログのエラー）を待つこと。