web-video-presentation
ConardLi/garden-skills
記事やスクリプトを、動画のような見た目のクリック操作型16:9ウェブプレゼンテーションに変換し、オプションでAIによるナレーション合成も追加できます。
...すべて拡張しますWeb動画プレゼンテーション
記事やナレーション原稿を、画面録画可能な「動画風ウェブページ」に段階的に変換します。ナレーション音声の合成も選択可能です。 成果物 = Vite + React + TS プロジェクト + 章ごとに分割された音声ファイル。
適用シーン
- 「ナレーション原稿/記事があるので、それを動画にしてほしい」―― ナレーション主導のコンテンツ
- 「動的なPPT」を作りたい
- 16:9の横画面録画、大きな文字、余白、各画面にアニメーション効果が必要
- チュートリアル/製品デモ/Keynoteで映画のような雰囲気を演出したい
- Bilibili / YouTube / TikTok向けの動画コンテンツ
本スキルは、方法論とコラボレーションプロセスを中核としています。テンプレートにはトークンやプリミティブが用意されていますが、 配色、フォント、アニメーションの雰囲気といった美的判断は、それぞれテーマに合わせて再設計する必要があります―― そのまま流用しないでください。
ワークフローの概要
Phase 1 内容编写
1.1 识别用户输入
1.2 一次产出 script.md + outline.md
(口播稿 + 开发计划)
▼
[Checkpoint Plan] ← 必须停。一次对齐 5 件事:
稿子 / outline / 主题 / 素材 / 开发模式
▼
Phase 2 网页开发
2.1 脚手架(按选定主题)
2.2 第 1 章 = 主线程 + 完整版本(强制 anchor)
▼
[硬节点] 用户验收第 1 章 ← 不可跳过
▼
2.3 第 2~N 章(按选定模式:A 逐章 / B 顺序 / C 并行)
▼
[Checkpoint Audio] ← 必须停。是否合成音频
▼
Phase 3 音频合成(可选)
▼
Phase 4 录屏 + 后期
作業ディレクトリの規約(エージェントはユーザーの現在のディレクトリ下に作成/編集を行います):
my-video/
├── article.md # 用户给原文时必有 —— 不删!开发阶段画面信息源
├── script.md # 必有:保持原文语言的平台化口播稿(决定节拍)
├── outline.md # 必有:开发计划(章节切分 + 每步内容 + 信息池)
└── presentation/ # 脚手架产出的 Vite + React + TS 项目
├── src/chapters/-/
│ ├── .tsx # 视觉实现
│ ├── .css
│ └── narrations.ts # ★ step 数 + 口播文本的唯一真相源
├── scripts/
│ ├── extract-narrations.ts # 扫所有 narrations.ts → audio-segments.json
│ ├── synthesize-audio.sh # provider-agnostic runner(循环 segments)
│ └── tts-providers/ # 每 provider 一个 .sh(内置 2 个)
│ ├── README.md # 三函数契约 + 5 段现成代码片段(11labs / edge-tts / say / azure / gcloud)
│ ├── minimax.sh # 默认 provider,用 mmx-cli
│ └── openai.sh # 内置 OpenAI TTS(curl + OPENAI_API_KEY)
├── audio-segments.json # extract 产出(合成前 review)
└── public/audio//.mp3 # 可选:合成的音频
重要:
narrations.tsステップ数と音声合成に関する唯一の真実の源です。 セクション.tsxにif (step === N)に現れる最大値 N + 1 は、narrations.lengthでなければなりません。これにより、5か所(スクリプト/アウトライン/章のコード/ chapters.ts/音声ファイル)の値が決してずれることがなくなります。
厳格な自己検査プロトコル(Skill全体に適用)
以下の3つの成果物については、それぞれ完了後に「自己検査 → 修正 → 再報告/進捗確認」のプロセスを経る必要があります:
| 成果物 | 自己点検チェックリストの出典 |
|---|---|
script.md |
SCRIPT-STYLE.md 3段階の自己点検(形式/文体/読み上げ) |
outline.md |
OUTLINE-FORMAT.md 自己点検 |
| 単章の実装完了 | CHAPTER-CRAFT.md 完了時の自己点検 |
実行方法(能力に応じて段階的に簡略化し、より隔離された方法を優先):
- Agent Teams(最適) :独立したレビュアーエージェントを起動し、「出力ファイルの パス+対応するチェックリスト+重要なコンテキスト」を渡し、項目ごとに検証させて結論 を厳格に報告させる(どの項目が合格/不合格か+証拠+修正提案)。
- subAgent(次善の策):Teamsの機能はないが、subAgentを起動できる場合はsubAgentを使用し、 同様のプロセスを実行する。
- 自己点検(最終手段) :現在使用中のエージェントがいずれも上記の機能を備えていない場合は、自身で項目ごとに厳格に確認 を行う――目視確認だけで通過させることは許されない。
鉄則:結論が出たら、まず「不合格」項目に基づいて成果物を修正し、その後ユーザーに「完了しました
- 自己点検の結果+修正内容」を報告する。修正せずに元の結論をそのまま報告することは=違反となる。
各段階におけるファイル参照ガイド
段階ごとに異なる文書を参照する。長時間のセッションでは、エージェントが原則を忘れがちになる。特に Phase 2.4の「実装に関する章」はN回繰り返されるため、その都度、中核となる制約条件を再確認する必要がある。
| フェーズ | 必読(毎回確認) | 一度に読み切る/必要に応じて参照 |
|---|---|---|
| Phase 1.1-1.2 コンテンツ作成 | references/SCRIPT-STYLE.md + references/OUTLINE-FORMAT.md + article.md(ユーザーによる原文、ある場合) |
—— |
| チェックポイントプラン:テーマの選定 | —— | themes/*/theme.json(動的に全文を読み込み、リストを作成 + bestFor 推奨 + descriptionZh);references/THEMES.md(ユーザーがテーマシステムについて知りたい場合) |
| Phase 2.1 スケルトン | —— | SKILL.md このセクションを一度確認 |
| Phase 2.4 単一チャプターの実装(×N回、2.2 / 2.3から呼び出される) | references/CHAPTER-CRAFT.md 単一のエントランス —— Part 0 10の原則 / Part 1 着手前の5つの質問 / Part 2 関係→アクションの決定木 / Part 3 ビジュアルツールボックス / Part 4 所要時間の目安 / Part 5 AI的でないアンチパターン / Part 6 コードの鉄則(narrations.tsによる強制制約を含む)/ Part 7 完了時の自己点検 / Part 8 フィードバッククイックリファレンス + 現在のトピックに関する themes/ + 現在の章の outline.md の段落 + article.md 本章に対応する段落 + 素材リスト |
references/EXAMPLES/(構造の例であり、テンプレートの丸写しではありません);references/THEMES.md 完全なトークン契約 |
| フェーズ3 音声合成 | references/AUDIO.md(narrations.ts → segments.json → 任意のプロバイダーへのプロセスを含む、ミニマックス+OpenAIを内蔵) |
templates/scripts/tts-providers/README.md(プロバイダーを変更する場合/独自のTTSを使用する場合) |
| フェーズ4 画面録画+ポストプロダクション | references/RECORDING.md( ?auto=1 自動画面録画) |
—— |
| テーマの選定/作成/分割 | —— | references/THEMES.md |
章を書く際は、
CHAPTER-CRAFT.mdの1つのファイルのみを参照する。10の原則/着手時のセルフプロンプティング/ 意思決定ツリー/AI臭を排除するアンチパターン/完成時の自己点検をすべて、この単一の入口に統合する。EXAMPLES/必読ではない ――まずは内容に基づいて自由に設計し、行き詰まったら参照すること(アンカーに従って「形」を参照し、そのまま真似てはならない)。
フェーズ1 —— コンテンツ作成(一回の制作)
1.1 ユーザー入力の特定
| ユーザーから提供されたもの | 行うべきこと |
|---|---|
| 元の記事(文章/WeChat公式アカウント/論文/ブログ) | 一度の制作 script.md + outline.md(1.2)、Checkpoint Planを通過 |
| 直接的なナレーション原稿/動画スクリプト | を script.md、一度の制作 outline.md(1.2 簡略版)、チェックポイントプランを通過 |
| 何も指定せず、「Xをテーマにした動画を作って」とだけ伝える | 反問:「まずは素材かアウトラインをください」。Skillはユーザーに代わってコンテンツを考案しません |
1.2 1回の作業で script.md + outline.md を出力
2つの成果物を1回の思考プロセスで完成させる:
script.mdの生成:references/SCRIPT-STYLE.mdのルールに従い、記事を原文の言語を維持したプラットフォーム向けのナレーション原稿に変換します。article.mdは削除せず残しておきます——これは アウトラインで情報プールや各章の画面構成を記述する際の詳細情報のソースとなります(二重ソースの原則)。outline.mdの生成:references/OUTLINE-FORMAT.mdルールに従って章を分割し、ステップを割り出し、各章の冒頭段落から情報プールを抽出する。
outlineの境界(重要):
| outlineには必ず | outlineに記述すべきでないもの |
|---|---|
| 章の分割/各章のステップ数/所要時間の見積もり | 具体的なアニメーションの種類(ぼかし・クリア/ワイプ/スプリング) |
| 各ステップの画面内容(ヒーロー画像/データ/スローガン/リスト項目) | CSSによる実装方法(filter/SVG/clip-path) |
| セクション単位の情報プール:articleから抽出した数値/引用/事例/タグ | 再生時間の数値(120 |
| ステップ間の関係を示す接頭辞(「対比」/「段階的リスト」/「名言」などのオプションヒント) | 持続的な微動/タイミングのずれ量などの微細なリズム |
アウトラインにアニメーションを記述しない理由:アニメーションを固定化すると、チャプターエージェントが単なる翻訳機に退化してしまう; 余白を残すことで、チャプターエージェントが各ステップの開始時に
CHAPTER-CRAFT.md「コンテンツ駆動の意思決定ツリー」に基づいて自由に設計できるよう、余白を残すことで初めて真の動画感が生まれる。詳細はCHAPTER-CRAFT.mdPart 0 の原則 7 を参照。
プラン確定後は、必ず自己検査を経てからチェックポイント・プランに進む:前述の「厳格な自己検査プロトコル」に従い、
それぞれ script.md / outline.md 実行し(優先順位:Agent Teams → subAgent → 自己診断)、
結論に基づいて修正を完了してからCheckpoint Planに進む。
Checkpoint Plan —— 5つの事項を一度に整合させる(ハードノード)
script.md + outline.md 書き終えたら一旦停止しなければならない。ユーザーはこのノードで同時に
5つの事項を確認する。
この時点でエージェントが行うべき準備作業
- すべてを読み込む
themes/*/theme.json取得nameZh/descriptionZh/bestFor/mood—— チェックリストをハードコーディングしない - 内容の種類/キーワード/口調に基づき、
script.md内容の種類/キーワード/口調に基づき、トピックから2~3 セットの最も適合するおすすめ(適合bestForフィールド)を - をざっと確認し
outline.md末尾の「素材リスト」セクション
テンプレートをまとめ(骨組み、エージェントが状況に応じて記入)
内容计划写完,产出文件:
📄 article.md {若用户给原文则保留}
📄 script.md {X} 字 / ~{T} 分钟
📄 outline.md {N} 章 / {M} 步 + 每章信息池 + 末尾素材清单
章节速览:
1. <章节标题> 步 ~s
2. ...
接下来一次对齐 5 件事:
1. 稿子 (script.md) 要不要改?
可以直接编辑文件,或口头告诉我修改方向。
2. 开发计划 (outline.md) 要不要改?重点看:
- 章节切分 / step 数 / 估时是否合理(合理判断:每章 30~60s)
- 每步屏幕内容是否清晰
- 每章首段「信息池」是否有足够的 article 细节供画面挂
- 末尾素材清单是否完整
3. 选哪个主题?我的推荐:
★ <推荐 1:nameZh (id)> — 因为 ;
★ <推荐 2 / 推荐 3>
其它可选:<剩余主题,nameZh + 一句话>
也可以让我帮你做新主题(详见 references/THEMES.md)。
4. 真素材怎么准备?粗看本视频要的图:<列粗略清单>
a) 我从 <现有素材路径> 帮你挑 b) 你自己提供 c) 全部 placeholder
5. 开发模式选哪个?
**第 1 章无论哪种模式都必须主线程做完 + 用户验收**(强制 anchor)。
差异在第 2 章及之后:
A) 默认 · 逐章确认(推荐)
每章做完都暂停验收 → 风险可控 / 节奏最稳
B) 第 1 章后顺序开发(不并行)
第 2~N 章主线程顺序做完后统一验收 → 速度中 / 适合 agent 不支持并行
C) 第 1 章后并行开发(subagent)
第 2~N 章用 subagent 并行 → 最快 / 用户控并行数(一次几章)
⚠️ 风格各章会有差异(这是预期,主题禁区兜底)
フィードバック受領後:
- 原稿/アウトラインの修正が必要な場合:ファイルを直接編集し、編集完了後に一度連絡する(または口頭で説明し、エージェントに修正してもらう)
- テーマが明確になって初めてPhase 2に進む。ユーザーから「テーマを選んでほしい」と言われた場合 → あなたが推薦した第1候補を採用し、 何を選んだか、その理由をユーザーに伝え、撤回する機会を与える
- 形式が決定 → Phase 2へ移行
Phase 2 —— ウェブ開発
2.1 スケルトン
bash /scripts/scaffold.sh \
./presentation \
--theme=<用户选的主题 id>
bash /scripts/scaffold.sh --list-themes
カスタムテーマ → まず
references/THEMES.md「新しいテーマを作成」のフローに従ってthemes/、その後/ --theme=。
スキャフォールドで 01-example デモを組み込みます。第1章の実際のコンテンツを記述する前に、以下を削除してください:
rm -rf presentation/src/chapters/01-example
そして presentation/src/registry/chapters.ts 中の EXAMPLE_CHAPTER
の import と配列の要素を削除してください。
2.2 第1章 —— メインスレッド + 強制的な検収
要点:第1章=完成版を一発で仕上げる(リズム+ビジュアル+実際の素材がすべて揃っている)。 「骨組み版」という概念はない――第1章では、ユーザーが直接検収できるサンプルを作成しなければならない。
なぜ第1章はメインスレッドでなければならないのか:
- それは
CHAPTER-CRAFT.mdこのガイドラインが、現在の テーマ+題材の下で初めて具現化されるものだから - ガイドラインに不備があったり、テーマカラーやフォントのトークンが不足していたりする場合、第1章で必ず露呈する―― この時点で人間からのフィードバックがあれば、ガイドラインを修正したりテーマを調整したりでき、早期の修正がコストを最小限に抑える
- 以降の章(順序や並行進行を問わず)はすべて第1章のコードパターンを参照する必要があるため、第1章は 当該プロジェクトの「スタイルの基準点(章間の一致は必須ではないが、単一の章として完全な説得力を持たなければならない)」となる
第1章を完成させた後は、必ず一旦停止してユーザーの検収を待つ:
第 1 章 做完了,dev server 在 localhost:5173 运行。
验收重点:
□ 视觉气质对不对?符合 的预期吗?
□ 节奏对不对?某些步太快 / 太慢 / 信息太薄?
□ 内容驱动动画是否到位?还是有几步是无脑入场动画?
□ 双源原则:屏幕画面有没有"口播没念但 article 能挂"的细节?
□ 反 AI 味检查:紫粉渐变 / 圆角彩色边框 / 假插画 / emoji 是否有?
问题告诉我,我针对性改。OK 了告诉我"继续",我按选定模式做第 2 章及之后。
2.3 第2~N章 —— 選定されたパターンに従う
すべてのパターンに共通するルール:各章は独立して CHAPTER-CRAFT.md
開発する。スタイルについては
、章間で完全に一致することを求めない
――テーマカラー/フォントのトークンで視覚的な
統一性を確保し、アニメーション/リズム/視覚的な表現は各章が自由に展開することが設計上の意図である。
モード A・デフォルト・章ごとの確認
第2章完了 → 確認のため一時停止 → OK → 第3章 → 一時停止 → ... → 第N章。各章を 個別に確認し、問題は随時修正するため、リスクが最も低く、ペースも最も安定しています。ユーザーがモードを明確に選択していない場合は 、デフォルトでこの方式を採用します。
モード B ・ 第1章終了後に順次開発
第2章 → 第3章 → ... → 第N章。メインスレッドで順次完了させ、最後に一括で検収を行います。 スピードは中程度で、エージェントが並列タスクに対応していない環境に適しています。
モード C ・ 第1章終了後の並列開発(サブエージェント)
サブエージェントを使用して第2章~第N章を並行して完了させます。最大並行数はユーザーが制御します(「一度に4章」 /「一度に2章」)。最も高速ですが、各章のスタイルにばらつきが生じます――これは想定内です。その理由は:
- 各サブエージェントは他のサブエージェントの成果物を見ることができず、機械的に同期させることができない
- 各章のコードは物理的に分離されており(各章ごとに1つのフォルダ/独自のCSSプレフィックス)、互いに 干渉することはない
- テーマトークンがビジュアルの統一性を保証(色/フォント/ヒーローの数字/カード/区切り線 キャラクター/装飾)、雰囲気が崩れることはない
- スタイルの不統一=手書き動画のような息づかい(複数のボイス/複数の視点)
並行して動作するサブエージェントのプロンプトには、以下を含める必要があります:
- 現在の章のアウトライン段落(情報プールを含む)
references/CHAPTER-CRAFT.mdのパス(必須の単一文書 —— 視覚的プレゼンテーション要件 + 段階的な開示 + 二重ソースの原則 + AIっぽさを排除 + コードのレッドライン + 完了時の自己チェックがすべてこの1つの文書に含まれる)- 現在のテーマ
theme.jsonのdescriptionZh/mood/bestFor(雰囲気の参考に すれば十分です。アニメーション/再生時間/文字サイズ/絵文字は、チャプターエージェントが自由に決定してください) - 第1章のコードは「コーディングスタイル」の参考として(「視覚的な模倣対象」ではない)
- 厳守ルール:各章ごとに独自のCSSプレフィックス(
.cd-/.mg-/.pm-/ ...); 変更禁止chapters.ts;完成後に実行npx tsc --noEmit
重要:どのモードを選択しても、ユーザーはいつでも途中でモードを切り替えることができます。第2章 OK 後、ユーザーが「残りを並行して」/「残りを章ごとに」のいずれを選択しても構いません。
2.4 単一章の実装(各章は必ず実行)
詳細なガイドラインは references/CHAPTER-CRAFT.md ――
単一の必須閲覧エントリ。カバー範囲:視覚的デモンストレーションの要件/段階的な開示/コンテンツの取捨選択/デュアルソースの原則
/動画デモンストレーションの基本的な美学/AIっぽさを排除/コードのレッドライン/完了時の自己点検。
核心となる要点(CHAPTER-CRAFT.md に詳述):
- 各章には必ず CSS / SVG / Canvas / JS による視覚的デモを含めること。テキストのみの章は禁止
- 段階的な開示:チェックリスト/リストは「1項目=1ステップ」とし、一度にすべてを表示することは禁止
- デュアルソース原則:リズムはナレーション原稿に合わせる(順序を乱してはならない)、詳細は元の記事から抽出する(情報プール + 当該章の article 段落)
- 完了時の自己点検は項目ごとに通過を確認し、基準に達していない場合は修正して再提出 —— 上記の「厳格な自己点検プロトコル」に従って実行 (優先順位:Agent Teams → subAgent → 自己点検)、修正完了後にユーザーへ本章の納品を報告
2.5 大規模変更後は STORAGE_KEY を更新
変更点 chapters.ts(章の追加/削除/再配置、または特定の章の narrations.ts
長さの変化)の後
、 presentation/src/hooks/useStepper.ts の
STORAGE_KEY(例: v4 → v5)、カーソルが存在しないステップに固定されるのを防ぐ。
Checkpoint Audio —— オーディオを合成するか(ハードノード)
Phase 2 終了後、処理を一時停止し、ユーザーに確認する:
网页做完,{N} 章 {M} 步,dev server 在 localhost:5173 跑着。
要不要合成音频做"自动播放录屏"?
✓ 合成 → 扫所有章节的 narrations.ts 出 audio-segments.json,
调 TTS provider 合成每步一个 mp3 到 public/audio/。
合成完后用 ?auto=1 模式可以一镜到底录屏(音视频天然同步)。
内置两个 provider:
• minimax (mmx-cli) —— 默认,中文音色稳
• openai (OPENAI_API_KEY) —— curl-based,多数已有 key
其它后端 (ElevenLabs / edge-tts 免费 / macOS say 离线 /
Azure / Google) 见 scripts/tts-providers/README.md 的现成片段。
✗ 不合成 → 跳过 Phase 3,直接 Phase 4 用手动录屏 + 后期配音。
合成する → Phase 3。合成しない → 直接 Phase 4。
Phase 3 —— オーディオ合成(オプション)
詳細なフローについては references/AUDIO.md。簡易版:
cd presentation
npm run extract-narrations # 扫所有 narrations.ts → audio-segments.json
# 让用户扫一眼 audio-segments.json 确认文本对
npm run synthesize-audio # 默认 minimax provider,增量
# 或用内置 openai (要 OPENAI_API_KEY):
PRESENTATION_TTS=openai npm run synthesize-audio
# 或自定义:写一个 scripts/tts-providers/.sh,见该目录的 README.md
合成完了後、ユーザーに以下の情報を伝える:出力位置/総セグメント数/どのセグメントの長さが異常か(長すぎる=そのステップを分割 する;短すぎる=台本が薄すぎる)―― 最後にリズムを調整する機会を与える。その後、Phase 4へ進む。
Phase 4 —— 画面録画 + ポストプロダクション
詳細は references/RECORDING.mdを参照。2つのアプローチ:
| シナリオ | 推奨フロー |
|---|---|
| フェーズ3:音声合成済み | Autoモードでのワンカット撮影:ブラウザを起動し localhost:5173/?auto=1 → SPACEキーを押す → 動画全体が自動再生される → 録画停止 → 冒頭と末尾をトリミングすれば完成。音声トラックの後処理は不要 |
| フェーズ3をスキップ | デフォルトのManualモードで手動でクリックして進行 → 任意の編集ツールで音声を追加 |
agentは、Phase 3 / Checkpoint Audioの後に、ユーザーに適した画面録画の進め方を能動的に案内します。
10の原則(一言リスト)
完全な展開はこちら references/CHAPTER-CRAFT.md
Part 0 —— 章を書く際はそちらを参照してください。以下は索引です。
| # | 原則 | 一言 |
|---|---|---|
| 1 | 16:9 固定ステージ | 内容 1920×1080 + 変形スケール、レスポンシブ対応なし |
| 2 | グローバル step カウンター | セクションは step の純粋関数であり、タイマーは使用しない |
| 3 | 各ステップで画面全体を独占 | if (step === N) return |
| 4 | ナレーションのビート = step | 1ビート = 1ステップ = 1つの焦点を絞ったアイデア |
| 5 | 画面隅に隠されたコントロール | プログレスバー/ページめくりバーのデフォルトの不透明度(opacity)は0 |
| 6 | ステージにクロムなし | ヘッダー/フッター/ページ番号/ブランドバーなし |
| 7 | コンテンツ主導のアニメーション | まずは内在的な動きを探し、見つからない場合にのみ登場アニメーションで補う;持続的な微動は控えめに |
| 8 | 複数の要素を順次表示 | 1項目=1ステップとし、N項目を同時にずらして表示することは避ける |
| 9 | 作品全体で統一されたテーマ | 章間では表面の色を変更しない;色/フォントはトークン単位で統一し、その他の規模については章ごとに自由に設定 |
| 10 | 二重ソースの原則 | scriptがテンポを決定し、articleが画面密度を決定する(情報プールに落とし込む) |
よくあるユーザーフィードバックのクイックリファレンス
表を簡略化して表示 references/CHAPTER-CRAFT.md
Part 8「よくあるフィードバックのクイックリファレンス」。ポイント
:まずどのレイヤー(リズム/ビジュアル/コンテンツ
/コード)の問題かを特定し、最小限の変更を行う。章全体を作り直さないこと
。
関連リソース
「いつ読むか」をタグ付けし、一度に全部読まないようにする:
| ファイル | いつ読むか | 内容 |
|---|---|---|
references/SCRIPT-STYLE.md |
Phase 1.2 必読 | 記事 → ナレーション原稿のルール、プラットフォームごとのバリエーション |
references/OUTLINE-FORMAT.md |
Phase 1.2 必読 | outline.md のフィールド仕様、命名規則、章の区切り、情報プール |
references/CHAPTER-CRAFT.md |
Phase 2.4 各章ごとの必読エントリー | Part 0 10の原則 / Part 1 着手前の5つの質問 / Part 2 関係→アクションの意思決定ツリー / Part 3 ビジュアルツールボックス / Part 4 所要時間 / Part 5 AIっぽさを排除するアンチパターン / Part 6 コードの厳格なルール / Part 7 完了時の自己点検 / Part 8 フィードバックのクイックリファレンス |
references/EXAMPLES/ |
オプション —— 構成を確認 | 章の構成例(hook / list-reveal / case-tech-review);テンプレートの丸写しではありません |
references/THEMES.md |
テーマを選定/構築/切り分ける際 | 完全なトークン契約 + 組み込みテーマリスト + 創作プロセス |
references/AUDIO.md |
Phase 3 になってから読む | プロバイダー非依存の音声合成プロセス、組み込みminimaxの使用法、プロバイダー変更の手順、トラブルシューティング |
templates/scripts/tts-providers/README.md |
TTSプロバイダーの変更・追加時 | 3つの関数契約 + 標準搭載の2つ(minimax / openai) + 5種類の既成コードスニペット(ElevenLabs / edge-tts / macOS say / Azure / Google) |
references/RECORDING.md |
フェーズ4から読む | 画面録画ツール + 事後合成 |
themes/ |
Checkpoint Plan / フェーズ1.2の時点で参照 | 組み込みテーマ(各テーマに以下を含む theme.json + tokens.css) |
scripts/scaffold.sh |
Phase 2.1で1回実行 | ワンクリックでプロジェクトのスケルトン生成 |
---
name: web-video-presentation
description: Transform articles or scripts into click-driven 16:9 web presentations that look like videos, with optional AI voiceover synthesis.
---
# Web Video Presentation
把一篇文章或口播稿,一步步做成可录屏的"伪装成视频的网页",可选合成
口播音频。产出物 = Vite + React + TS 项目 + 按章节切分的音频。
## 适用场景
- "我有口播稿 / 一篇文章,帮我做成视频" —— 口播驱动的内容
- 想做 "动态 PPT"
- 16:9 横屏录屏,大字、留白、每屏都要有动效
- 教学 / 产品演示 / keynote 想要电影感
- B 站 / YouTube /抖音视频内容
本 Skill **以方法论 + 协作流程为核心**。脚手架模板提供 token 和原语,
但每个美学决策(配色、字型、动效气质)都应该针对你的主题重新设计 ——
不要照搬。
---
## 工作流总览
```
Phase 1 内容编写
1.1 识别用户输入
1.2 一次产出 script.md + outline.md
(口播稿 + 开发计划)
▼
[Checkpoint Plan] ← 必须停。一次对齐 5 件事:
稿子 / outline / 主题 / 素材 / 开发模式
▼
Phase 2 网页开发
2.1 脚手架(按选定主题)
2.2 第 1 章 = 主线程 + 完整版本(强制 anchor)
▼
[硬节点] 用户验收第 1 章 ← 不可跳过
▼
2.3 第 2~N 章(按选定模式:A 逐章 / B 顺序 / C 并行)
▼
[Checkpoint Audio] ← 必须停。是否合成音频
▼
Phase 3 音频合成(可选)
▼
Phase 4 录屏 + 后期
```
工作目录约定(agent 在用户当前目录下创建 / 编辑):
```
my-video/
├── article.md # 用户给原文时必有 —— 不删!开发阶段画面信息源
├── script.md # 必有:保持原文语言的平台化口播稿(决定节拍)
├── outline.md # 必有:开发计划(章节切分 + 每步内容 + 信息池)
└── presentation/ # 脚手架产出的 Vite + React + TS 项目
├── src/chapters/<NN>-<id>/
│ ├── <Chapter>.tsx # 视觉实现
│ ├── <Chapter>.css
│ └── narrations.ts # ★ step 数 + 口播文本的唯一真相源
├── scripts/
│ ├── extract-narrations.ts # 扫所有 narrations.ts → audio-segments.json
│ ├── synthesize-audio.sh # provider-agnostic runner(循环 segments)
│ └── tts-providers/ # 每 provider 一个 .sh(内置 2 个)
│ ├── README.md # 三函数契约 + 5 段现成代码片段(11labs / edge-tts / say / azure / gcloud)
│ ├── minimax.sh # 默认 provider,用 mmx-cli
│ └── openai.sh # 内置 OpenAI TTS(curl + OPENAI_API_KEY)
├── audio-segments.json # extract 产出(合成前 review)
└── public/audio/<id>/<N>.mp3 # 可选:合成的音频
```
> **关键**:`narrations.ts` 是 step 数和音频合成的**唯一真相源**。
> 章节 `.tsx` 里的 `if (step === N)` 出现的最大 N + 1 必须等于
> `narrations.length`。这保证 5 处地方(script / outline / 章节代码 /
> chapters.ts / 音频文件)永远不会漂。
---
## 硬性自检协议(贯穿整个 Skill)
下面三个产出,每一个**完成后必须走自检 → 修复 → 再汇报 / 推进**:
| 产出 | 自检清单出处 |
|---|---|
| `script.md` | [`SCRIPT-STYLE.md`](references/SCRIPT-STYLE.md) 三层自检(形式 / 风骨 / 念出来) |
| `outline.md` | [`OUTLINE-FORMAT.md`](references/OUTLINE-FORMAT.md) 自检 |
| 单章实现完成 | [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) 完工自检 |
**执行方式**(按能力降级,**优先用更隔离的方式**):
1. **Agent Teams(最优)**:开一个独立的 reviewer agent,给它"产出文件
路径 + 对应清单 + 关键上下文",让它逐项核查并**严格汇报结论**
(哪几条 pass / 哪几条 fail + 证据 + 改写建议)。
2. **subAgent(次优)**:没有 Teams 能力但能开 subagent 就用 subagent
走同样流程。
3. **自检(兜底)**:当前 agent 都没有上述能力,就自己**严格逐项**
核查 —— 不允许目测一遍就放行。
**铁律**:拿到结论后**先按 fail 项把产出改完**,再向用户汇报"做完了
+ 自检结论 + 改了什么"。**直接拿原始结论汇报但不修复 = 违规**。
---
## 各阶段文件读取指南
不同阶段读不同的文件。**长会话里 agent 容易遗忘原则**,特别是
Phase 2.4 的"实现单章"会重复 N 次 —— 每次都要回看核心约束。
| 阶段 | 必读(每次都看) | 一次性看完 / 按需查 |
|---|---|---|
| Phase 1.1-1.2 内容编写 | `references/SCRIPT-STYLE.md` + `references/OUTLINE-FORMAT.md` + `article.md`(用户原文,如有) | —— |
| **Checkpoint Plan 选主题** | —— | `themes/*/theme.json`(动态读全部,列清单 + `bestFor` 推荐 + `descriptionZh`);`references/THEMES.md`(用户想了解主题系统时) |
| Phase 2.1 脚手架 | —— | SKILL.md 本节看一次 |
| **Phase 2.4 实现单章(×N 次,被 2.2 / 2.3 调用)** | **`references/CHAPTER-CRAFT.md`** 单一入口 —— Part 0 十条原则 / Part 1 开工 5 问 / Part 2 关系→动作决策树 / Part 3 视觉工具箱 / Part 4 时长参考 / Part 5 反 AI 味反模式 / Part 6 代码硬规则(**含 narrations.ts 强制约束**)/ Part 7 完工自检 / Part 8 反馈速查 + 当前主题的 `themes/<id>/theme.json` + 当前章节的 outline.md 段落 + **`article.md` 本章对应段落** + 素材清单 | `references/EXAMPLES/`(结构示意,不是抄袭模板);`references/THEMES.md` 完整 token 契约 |
| Phase 3 音频合成 | `references/AUDIO.md`(含 narrations.ts → segments.json → 任意 provider 流程,内置 minimax + openai) | `templates/scripts/tts-providers/README.md`(换 provider / 自带 TTS 时) |
| Phase 4 录屏 + 后期 | `references/RECORDING.md`(含 `?auto=1` 自动录屏) | —— |
| 选 / 造 / 切主题 | —— | `references/THEMES.md` |
> **写章节时只读一份 `CHAPTER-CRAFT.md`**。十条原则 / 开工 self-prompting /
> 决策树 / 反 AI 味反模式 / 完工自检全部并入这一份单一入口。`EXAMPLES/`
> **不是必读** —— 先按内容自由设计,卡壳才翻(按 anchor 翻"形",不要照搬)。
---
## Phase 1 —— 内容编写(一次产出)
### 1.1 识别用户输入
| 用户给的东西 | 该做的 |
|---|---|
| 原始文章(书面语 / 公众号 / 论文 / 博客) | 一次产出 `script.md` + `outline.md`(1.2),过 Checkpoint Plan |
| 直接的口播稿 / 视频脚本 | 落盘成 `script.md`,一次产出 `outline.md`(1.2 简化版),过 Checkpoint Plan |
| 啥都没有,只说"帮我做个 X 主题的视频" | **反问**:先给一段素材或大纲。Skill 不替用户构思内容 |
### 1.2 一次产出 script.md + outline.md
**两份产出物在一次思考中完成**:
1. **生成 `script.md`**:按 [`references/SCRIPT-STYLE.md`](references/SCRIPT-STYLE.md)
的规则把 article 转成保持原文语言的平台化口播稿。**保留 `article.md` 不删**——它是
outline 写信息池和章节实现画面时的细节源(双源原则)。
2. **生成 `outline.md`**:按 [`references/OUTLINE-FORMAT.md`](references/OUTLINE-FORMAT.md)
规则切章节 + 切 step + 每章首段抽**信息池**。
**outline 的边界**(关键):
| outline 必须写 | outline 不要写 |
|---|---|
| 章节切分 / 每章 step 数 / 估时 | 具体动画类型(blur clear / wipe / 弹簧) |
| 每步屏幕内容(hero / 数据 / 标语 / 列表项) | CSS 实现手段(filter / SVG / clip-path) |
| 章节级**信息池**:从 article 抽的数字 / 引用 / 案例 / 标签 | 时长数值(不写 ~2.5s / 80~120ms) |
| 步级关系名前缀("反差对照" / "递进列表" / "金句" 等可选 hint) | 持续微动 / 错峰量等微观节奏 |
> **outline 不写动画的理由**:写死动画 = chapter agent 退化为翻译机;
> 留白让 chapter agent 在每步开工时按 [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
> 的"内容驱动决策树"自由设计,才有真正的视频感。详见
> [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) Part 0 原则 7。
**落盘后必须先走自检再进 Checkpoint Plan**:按上文「硬性自检协议」分别
对 `script.md` / `outline.md` 执行(优先 Agent Teams → subAgent → 自检),
按结论修复完成后再进入 Checkpoint Plan。
---
## Checkpoint Plan —— 5 件事一次对齐(**硬节点**)
`script.md` + `outline.md` 写完后必须停下来。**用户在这一个节点同时确认
5 件事**。
### agent 此时要做的预备工作
1. 读所有 `themes/*/theme.json` 拿 `nameZh` / `descriptionZh` / `bestFor`
/ `mood` —— **不要硬编码清单**
2. 根据 `script.md` 的内容类型 / 关键词 / 语气,**主动**从主题里挑 2~3
套**最匹配的推荐**(匹配 `bestFor` 字段)
3. 扫一遍 `outline.md` 末尾"素材清单"部分
### 总结模板(骨架,agent 按情况填充)
```
内容计划写完,产出文件:
📄 article.md {若用户给原文则保留}
📄 script.md {X} 字 / ~{T} 分钟
📄 outline.md {N} 章 / {M} 步 + 每章信息池 + 末尾素材清单
章节速览:
1. <id> <章节标题> <S> 步 ~<T>s
2. ...
接下来一次对齐 5 件事:
1. 稿子 (script.md) 要不要改?
可以直接编辑文件,或口头告诉我修改方向。
2. 开发计划 (outline.md) 要不要改?重点看:
- 章节切分 / step 数 / 估时是否合理(合理判断:每章 30~60s)
- 每步屏幕内容是否清晰
- 每章首段「信息池」是否有足够的 article 细节供画面挂
- 末尾素材清单是否完整
3. 选哪个主题?我的推荐:
★ <推荐 1:nameZh (id)> — 因为 <bestFor 命中>;<descriptionZh 摘要>
★ <推荐 2 / 推荐 3>
其它可选:<剩余主题,nameZh + 一句话>
也可以让我帮你做新主题(详见 references/THEMES.md)。
4. 真素材怎么准备?粗看本视频要的图:<列粗略清单>
a) 我从 <现有素材路径> 帮你挑 b) 你自己提供 c) 全部 placeholder
5. 开发模式选哪个?
**第 1 章无论哪种模式都必须主线程做完 + 用户验收**(强制 anchor)。
差异在第 2 章及之后:
A) 默认 · 逐章确认(推荐)
每章做完都暂停验收 → 风险可控 / 节奏最稳
B) 第 1 章后顺序开发(不并行)
第 2~N 章主线程顺序做完后统一验收 → 速度中 / 适合 agent 不支持并行
C) 第 1 章后并行开发(subagent)
第 2~N 章用 subagent 并行 → 最快 / 用户控并行数(一次几章)
⚠️ 风格各章会有差异(这是预期,主题禁区兜底)
```
收到反馈后:
- 稿子 / outline 要改:直接编辑文件,编辑完 ping 一次(或口头描述 agent 改)
- **主题必须明确**才进入 Phase 2。用户说"主题你帮我选" → 取你推荐的第 1 个,
**告诉用户你选了什么、为什么**,给反悔机会
- 模式选定 → 进 Phase 2
---
## Phase 2 —— 网页开发
### 2.1 脚手架
```bash
bash <path-to-web-video-presentation>/scripts/scaffold.sh \
./presentation \
--theme=<用户选的主题 id>
bash <path-to-web-video-presentation>/scripts/scaffold.sh --list-themes
```
> 自定义主题 → 先按 [`references/THEMES.md`](references/THEMES.md)
> "创作新主题"流程做一个 `themes/<my-theme>/`,再 `--theme=<my-theme>`。
脚手架带一个 `01-example` demo。在写第一章真实内容前**删掉**:
```bash
rm -rf presentation/src/chapters/01-example
```
并把 `presentation/src/registry/chapters.ts` 里 `EXAMPLE_CHAPTER`
的 import 和数组项移除。
### 2.2 第 1 章 —— 主线程 + 强制验收
**核心**:第 1 章 = 完整版本一次到位(节奏 + 视觉 + 真素材齐全)。
**没有"骨架版"概念** —— 第一章就要做出**用户能直接验收**的样板。
为什么第 1 章必须主线程:
- 它是 [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) 这套指引在**当前
主题 + 当前题材**下的第一次落地
- 如果指引有盲区 / 主题颜色 / 字体 token 不够用,第 1 章一定会暴露 ——
这时候有人类反馈就能修指引 / 调主题,**早改成本最低**
- 后续章节(无论顺序 / 并行)都要参考第 1 章的代码模式,所以第 1 章 =
当次项目的"风格锚点(不强求章节间一致,但单章自身得有完整说服力)"
**做完第 1 章后必须停下来**等用户验收:
```
第 1 章 <id> 做完了,dev server 在 localhost:5173 运行。
验收重点:
□ 视觉气质对不对?符合 <theme nameZh> 的预期吗?
□ 节奏对不对?某些步太快 / 太慢 / 信息太薄?
□ 内容驱动动画是否到位?还是有几步是无脑入场动画?
□ 双源原则:屏幕画面有没有"口播没念但 article 能挂"的细节?
□ 反 AI 味检查:紫粉渐变 / 圆角彩色边框 / 假插画 / emoji 是否有?
问题告诉我,我针对性改。OK 了告诉我"继续",我按选定模式做第 2 章及之后。
```
### 2.3 第 2~N 章 —— 按选定模式
**所有模式下的共同规则**:每章独立按 [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
开发。**风格不强求章节间完全一致** —— 主题颜色 / 字体 token 兜底视觉
统一,动画 / 节奏 / 视觉演示由章节自由发挥是设计预期。
#### 模式 A · 默认 · 逐章确认
第 2 章做完 → 暂停验收 → OK → 第 3 章 → 暂停 → ... → 第 N 章。**每章
独立验收**,问题随时改,**风险最低,节奏最稳**。**用户不明确选模式时
默认走这个**。
#### 模式 B · 第 1 章后顺序开发
第 2 章 → 第 3 章 → ... → 第 N 章 **主线程顺序做完,最后统一验收**。
速度中等,适合 agent 不支持并行任务的环境。
#### 模式 C · 第 1 章后并行开发(subagent)
用 subagent 把第 2~N 章并行做完,最大并行数由用户控制("一次 4 章"
/ "一次 2 章")。**最快,但风格各章会有差异** —— 这是预期,因为:
1. 每个 subagent 看不到别的 subagent 产出,无法机械对齐
2. 章节代码物理分离(每章一个文件夹 / 自己的 CSS 前缀),不会互相
破坏
3. 主题 token 兜底视觉统一(颜色 / 字体 / hero 数字 / 卡片 / 分割线
性格 / 装饰),气质不会跑偏
4. **风格不一致 = 人手写视频的呼吸感**(多 voice / 多视角)
并行 subagent 的 prompt 必须包含:
- 当前章节 outline 段落(含信息池)
- `references/CHAPTER-CRAFT.md` 的路径(**单一必读** —— 视觉演示要求 +
逐步揭示 + 双源原则 + 反 AI 味 + 代码红线 + 完工自检全部在这一份里)
- 当前主题 `theme.json` 的 `descriptionZh` / `mood` / `bestFor`(参考气质
即可,动画 / 时长 / 字号 / emoji 由 chapter agent 自由决定)
- **第 1 章代码作为"代码风格"参考**(不是"视觉抄袭对象")
- 硬规则:每章独立 CSS 前缀(`.cd-` / `.mg-` / `.pm-` / ...);
不修改 `chapters.ts`;完工跑 `npx tsc --noEmit`
**重要**:无论选哪种模式,**用户随时可以中途切换模式**。第 2 章 OK
后用户说"剩下的并行" / "剩下的逐章" 都行。
### 2.4 实现单章(每章必走)
详细指引见 [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) ——
**单一必读入口**,覆盖:视觉演示要求 / 逐步揭示 / 内容取舍 / 双源原则
/ 视频演示基本审美 / 反 AI 味 / 代码红线 / 完工自检。
**核心要点**(CHAPTER-CRAFT.md 详述):
- **每章必须有 CSS / SVG / Canvas / JS 视觉演示**,禁纯文字章节
- **逐步揭示**:清单 / 列表必须 1 项 = 1 step,禁一次全展示
- **双源原则**:节奏跟口播稿(顺序不能乱),细节回原文章抽(信息池 +
本章 article 段落)
- **完工自检逐项过**,不达标回去改 —— 按上文「硬性自检协议」执行
(优先 Agent Teams → subAgent → 自检),**改完再向用户汇报本章交付**
### 2.5 大改后 bump STORAGE_KEY
改动 `chapters.ts`(增加 / 删除 / 重排章节,或某章 `narrations.ts`
长度变化)后,**bump** `presentation/src/hooks/useStepper.ts` 的
`STORAGE_KEY`(如 `v4` → `v5`),避免持久化游标落到不存在的 step 上。
---
## Checkpoint Audio —— 是否合成音频(**硬节点**)
Phase 2 结束后必须停下来,问用户:
```
网页做完,{N} 章 {M} 步,dev server 在 localhost:5173 跑着。
要不要合成音频做"自动播放录屏"?
✓ 合成 → 扫所有章节的 narrations.ts 出 audio-segments.json,
调 TTS provider 合成每步一个 mp3 到 public/audio/。
合成完后用 ?auto=1 模式可以一镜到底录屏(音视频天然同步)。
内置两个 provider:
• minimax (mmx-cli) —— 默认,中文音色稳
• openai (OPENAI_API_KEY) —— curl-based,多数已有 key
其它后端 (ElevenLabs / edge-tts 免费 / macOS say 离线 /
Azure / Google) 见 scripts/tts-providers/README.md 的现成片段。
✗ 不合成 → 跳过 Phase 3,直接 Phase 4 用手动录屏 + 后期配音。
```
要合成 → Phase 3。不合成 → 直接 Phase 4。
---
## Phase 3 —— 音频合成(可选)
详细流程见 [`references/AUDIO.md`](references/AUDIO.md)。简版:
```bash
cd presentation
npm run extract-narrations # 扫所有 narrations.ts → audio-segments.json
# 让用户扫一眼 audio-segments.json 确认文本对
npm run synthesize-audio # 默认 minimax provider,增量
# 或用内置 openai (要 OPENAI_API_KEY):
PRESENTATION_TTS=openai npm run synthesize-audio
# 或自定义:写一个 scripts/tts-providers/<name>.sh,见该目录的 README.md
```
合成完告诉用户:输出位置 / 总段数 / 哪些段时长异常(太长 = 该 step 拆
分;太短 = 文案太薄)—— 给最后一次校准节奏的机会。然后进入 Phase 4。
---
## Phase 4 —— 录屏 + 后期
详见 [`references/RECORDING.md`](references/RECORDING.md)。两种路径:
| 场景 | 推荐路径 |
|---|---|
| Phase 3 已合成音频 | **Auto 模式一镜到底**:浏览器开 `localhost:5173/?auto=1` → 按 SPACE → 整片自动播完 → 停录 → 裁头尾即成片,**无需后期对音轨** |
| Phase 3 跳过 | 默认 Manual 模式手动点击推进 → 后期任意剪辑工具配音 |
> agent 在 Phase 3 / Checkpoint Audio 后**主动告诉用户**适合的录屏路径。
---
## 十条原则(一句话清单)
完整展开见 [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
Part 0 —— **写章节时回那里查**,下面只是索引。
| # | 原则 | 一句话 |
|---|---|---|
| 1 | 16:9 固定舞台 | 内容 1920×1080 + transform scale,没有响应式 |
| 2 | 全局 step 计数器 | 章节是 step 的纯函数,无定时器 |
| 3 | 每步独占整屏 | `if (step === N) return <FullScene />` |
| 4 | 口播节拍 = step | 一节拍 = 一 step = 一聚焦想法 |
| 5 | 隐藏的边角控件 | 进度条 / 翻页器默认 opacity 0 |
| 6 | 舞台无 chrome | 没有 header / footer / 页码 / 品牌条 |
| 7 | **内容驱动动画** | 先找内在动作,找不到才入场动画兜底;持续微动慎用 |
| 8 | 多点逐个揭示 | 1 项 = 1 step,禁同步 stagger 上 N 项 |
| 9 | 整片同一主题 | 章节间不翻表面色;**颜色 / 字体走 token**,其它尺度章节自由 |
| 10 | 双源原则 | script 定节拍,**article 定画面密度**(落到信息池) |
---
## 常见用户反馈速查
简化表见 [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
Part 8「常见反馈速查」。**关键**:先定位是哪一层(节奏 / 视觉 / 内容
/ 代码),再改最小切片,**不要重做整章**。
---
## 相关资源
按"何时读"标注,避免一次性全读:
| 文件 | 何时读 | 内容 |
|---|---|---|
| [`references/SCRIPT-STYLE.md`](references/SCRIPT-STYLE.md) | Phase 1.2 必读 | 文章 → 口播稿规则、平台变体 |
| [`references/OUTLINE-FORMAT.md`](references/OUTLINE-FORMAT.md) | Phase 1.2 必读 | outline.md 字段 spec、命名约定、章节切分、信息池 |
| [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) | **Phase 2.4 每章单一必读入口** | Part 0 十条原则 / Part 1 开工 5 问 / Part 2 关系→动作决策树 / Part 3 视觉工具箱 / Part 4 时长 / Part 5 反 AI 味反模式 / Part 6 代码硬规则 / Part 7 完工自检 / Part 8 反馈速查 |
| [`references/EXAMPLES/`](references/EXAMPLES/) | **可选** —— 看结构 | 章节结构示意(hook / list-reveal / case-tech-review);**不是抄袭模板** |
| [`references/THEMES.md`](references/THEMES.md) | 选 / 造 / 切主题时 | 完整 token 契约 + 内置主题清单 + 创作流程 |
| [`references/AUDIO.md`](references/AUDIO.md) | Phase 3 才读 | provider-agnostic 音频合成流程、内置 minimax 用法、换 provider 路径、故障排查 |
| [`templates/scripts/tts-providers/README.md`](templates/scripts/tts-providers/README.md) | 换 / 加 TTS provider 时 | 三函数契约 + 内置 2 个 (minimax / openai) + 5 种现成代码片段(ElevenLabs / edge-tts / macOS say / Azure / Google) |
| [`references/RECORDING.md`](references/RECORDING.md) | Phase 4 才读 | 录屏工具 + 后期合成 |
| [`themes/`](themes) | Checkpoint Plan / Phase 1.2 时翻 | 内置主题(每个含 `theme.json` + `tokens.css`) |
| [`scripts/scaffold.sh`](scripts/scaffold.sh) | Phase 2.1 跑一次 | 一键项目脚手架 |
すべてのファイル
95件のファイルweb-video-presentationをインストール
スキルファイルをダウンロードし、.claude/skills/ ディレクトリに解凍してください。
ZIPをダウンロードリポジトリをクローンし、スキルファイルをプロジェクトにコピーしてください。
git clone https://github.com/ConardLi/garden-skills/tree/main/skills/web-video-presentation # Copy SKILL.md to your .claude/skills/ directory
コピー





家
