GitHub 単一リポジトリビデオオーケストレーション

このスキルは、GitHub 単一リポジトリビデオの唯一のオーケストレーションエントリポイントです。各リポジトリは、事実、企画、スクリプト、録画、タイムライン、オーディオ、カバーデータ、リリースパッケージを独立して持ちます。共通コンポーネントのみを再利用します。過去の作品やサンプルは参考としてのみ使用し、事実、スキーマ、または視覚的なハードスタンダードとして使用してはなりません。

1. 読み取り順序と責任

最初にリポジトリの AGENTS.md で規定されたドキュメントを読み、次にフェーズに従って完全に読み取り、実行します。

work-library-api-registration：ワークベンチへの登録またはタスク複製フィールド。
~/.codex/skills/selfmedia-github-research/SKILL.md：公式ソースと高リスク声明。
~/.codex/skills/douyin-tech-content-planner/SKILL.md：オーディエンス、唯一のベネフィット、フック、証拠の順序。
~/.codex/skills/record-web-demo/SKILL.md：証拠リスト、アクションプラン、実画面録画。
~/.codex/skills/selfmedia-script-storyboard/SKILL.md：最初に最終ナレーションと読み取り可能なストーリーボードを確定し、最終的なオーディオ時間を推定しない。
このスキルのオーディオルール：シリアルに生成してオーディオを実測し、最初に実際の持続時間と字幕時間を取得する。
~/.codex/skills/selfmedia-script-storyboard/SKILL.md：録画アクション時間と実測オーディオを使用してタイムライン v1.2 を完了する。
~/.codex/skills/selfmedia-cover-design/SKILL.md：3:4 と 4:3 の2サイズのカバー。
~/.codex/skills/selfmedia-remotion-render/SKILL.md：共通テンプレートでのレンダリング。
このスキルのフローゲート：フェーズ順序、必須成果物、ワークベンチステータスを確認。5ファイルのマシンコントラクトが通過した後、直接アトミックに正式リリースパッケージを生成する。

コンテンツエージェントは自分のコンテンツユニットのみを変更できます。apps/studio/src/root.tsx、共通テンプレート、共通カバー、スキーマ、プリフライト、リリースバリデーターは、メイン統合エージェントのみが変更できます。複数のエージェントが同時に共有ファイルを変更してはなりません。

2. 登録と正式コンテンツユニット

ユーザーが正式なトピックを提出した後、最初にワークベンチへの登録を完了する必要があります。新規コンテンツは POST /api/production-requests を呼び出し、既存のディレクトリは POST /api/works を呼び出した後 POST /api/production-requests/adopt を呼び出します。どちらの方法でも有効な work_id とプロダクションリクエスト ID を返す必要があります。これらの2つのIDがない限り、調査、録画、またはレンダリングを行ってはなりません。
登録が成功した後、projects/github/videos/<content-id>/ に独立したコンテンツユニットを作成または引き継ぎ、projects/index.yaml と projects/task-index.yaml を同期します。content.yaml、task.yaml、制作单.md はすべて同じ work_id でディスクに書き込まれなければなりません。ワークベンチフローインターフェースの最初のフェーズは「ワークベンチ登録」と固定表示されます。
ワークベンチはタスク要件のみを保存します。テンプレートを複製する際は、古いリポジトリ URL、Star、バージョン、ライセンス、スクリプト、タイムライン、録画、ソース、カバーデータ、リリースパッケージをクリアします。
renderer.composition_id は GitHubProjectDemoTemplate に固定されます。テンプレート ID はワークベンチ/API から返され、過去の作品のテンプレート ID に手動で依存してはいけません。
ユーザーが正式なタスクを提出すると、ワークベンチは8つのフェーズを連続して release_ready まで実行できます。ユーザーがテストを明示的に要求し、停止ポイントを指定した場合のみ stopAfterStageId を設定します。planning は制作指示書のみを渡し、render はレンダリングの一時保存のみを行い、正式なディレクトリは生成しません。ワークベンチが連続して実行する場合、同じ Codex セッションを再利用し、フェーズゲートは保持しますが、各フェーズのコンテキストを再構築しません。
正式なコンテンツユニットには以下が必須です。
- project.json
- content.yaml
- task.yaml
- research/facts.json
- 制作单.md
Pipeline の調査出力が一時的なワークスペースにある場合、公式ソース、現在使用中の動的フィールド、高リスク声明の結論を正式なコンテンツユニットに書き戻さなければなりません。一時的なディレクトリを正式なプロジェクトの代わりにしてはいけません。

GitHub 単一プロジェクトビデオは、1つの手動メインドキュメント 制作单.md のみを維持し、decision、voiceover、storyboard、assets、release の5つの固定マーカーブロックを使用します。新しいタスクでは research/decision.md、research/content-plan.md、script/voiceover.md、script/script.json、创作提示词.md、qa/ を作成しません。事実、タイムライン、アクションプラン、録画リスト、オーディオ、SRT、レンダリング Props は引き続き独立したマシンファイルを使用します。

3. ソース、リスク、企画ゲート

GitHub リポジトリページを使用してプロジェクトの ID を確認し、公式 URL を保存します。このビデオに実際に現れる高リスク声明に対してのみ、README、公式ドキュメント、またはリリースページにアクセスし、全機能の百科事典的な検証は行いません。
高リスク声明には以下が含まれます：動的な数字とランキング；価格、コスト、節約率、パフォーマンス比較；セキュリティ、プライバシー、法的な結論；ライセンス、バージョン、メンテナンスステータス、公式 ID；絶対的な約束；および実際の画面や公式ソースに裏付けられていない具体的な結果。
Star、バージョン、ライセンスなどのフィールドは、画面やコピーで使用する場合にのみ検証します。使用する際は、正式なレンダリングの前にリフレッシュします。facts.json には正確な値、ソース、リスク結論を保存します。追加の高リスク声明がない場合は、空のリストを記録すれば十分です。
一般的なペインポイント、疑問文、感情、アナロジー、軽いユーモア、実際のデモの口語的な要約については、一文ごとの検証は行いません。ユーザーが提供または承認したフックはデフォルトでロックされ、明らかな事実誤認、法令順守リスク、または深刻な誤解を招く場合にのみ却下できます。その他のリスクについては、最小限の単語レベルの修正のみ行います。
1本のビデオで約束するコアベネフィットは1つだけです。最初にオーディエンス、わかりやすいフック、最初の12秒での約束の実現、ユニークな CTA を決定してからスクリプトを書きます。事実ファイルは、README の技術的な言い回しをナレーションに注入してはいけません。実際に使用の可否に影響するハードルがある場合のみ、対応する機能と一緒に自然に説明します。リスク注意ページ、検証待ちページ、免責事項の壁、適用範囲ページを個別に作成することは禁止されています。
公開された完成品には、完全な URL、QR コード、ダウンロードボタン、外部サイトへのアクション指示、または一般的なツールの具体的な金額を表示してはいけません。
プロジェクトの ID が確認できない場合、または公開されたコピーに未解決の高リスク声明が含まれている場合は停止します。高リスク声明がない場合、録画やレンダリングをブロックしてはいけません。

4. 実際の証拠と素材時間

最初に record-web-demo を実行する必要があります。

800×600 の論理ビューポートを使用して、README、画像/GIF、候補スクリーンショット、セレクターを収集します。
最初に GitHub リポジトリ ID のショットを計画します。実際のリポジトリ名には細い角丸ボックス、Star またはバージョンには細い楕円を使用します。このショットは、すべての README または外部デモの前に配置しなければなりません。
次に、コアベネフィットを証明できる README または公式デモの証拠を1～3つ選択します。ファイルリスト、インストールログ、ロゴ、ライセンスは、デフォルトで結果の証拠として機能してはいけません。
GitHub ID と外部デモには、独立したアクションプランと録画ファイルを使用します。それぞれの検証が合格した後に録画します。1600×1200 のエンコードソースが必要な場合は、--pixel-scale 2 を使用して後処理し、Web ページのレイアウトを拡大しません。
録画リストには、各実際のアクションの startMs、endMs、ページ、操作、証拠オブジェクト、実行結果を記録しなければなりません。
録画スクリプトは正常に完了する必要があり、リスト内のアクションには実際の startMs、endMs、完了ステータスが必要です。失敗したアクションはタイムラインに入れてはいけません。
タイムラインの trimStartMs と trimEndMs は録画リストからのみ取得できます。完成品のシーン時間を素材のイン点として使用することは禁止されています。

5. スクリプトとタイムライン

所要時間は、情報量、実測ナレーション、画面の読み取り時間によって決定され、25秒に固定されません。デフォルトのナラティブ参照：

0～3秒    GitHub リポジトリページ、プロジェクト名、Star、コアバリュー
3～6秒    README 結果または公式デモの最初の実際の証拠
最初の12秒 最も強力な実際の証拠が表示される
中盤      1～2つの証拠のデモを継続
後半      適用シーン、ハードル、制限
最後      1文の要約と自然な CTA

まず最終ナレーションと読み取り可能なストーリーボードを 制作单.md の voiceover と storyboard ブロックに書き込みます。オーディオフェーズの完了後、実測のオーディオ持続時間、字幕時間、録画リストを使用して、唯一のマシン監督ファイル timeline.json を生成します。タイムライン：

packages/timeline-schema/timeline.schema.json を使用し、バージョンは 1.2。
Scene の role は hook、proof、process、result、identity、cta のみ許可。
direction.proofByMs <= 12000。
direction.demoLayoutPreset は fixed-demo-v1 に固定。デモの外枠は x=86, y=420, width=908, height=681 に固定。
最大1つの visualPeak: true。
focus は検証済みのソースフレームから得られた正規化座標を使用。
デモシーンでは identityTop、evidenceTop、captionTop を設定してはいけません。強調はデモ枠の内部でのみ許可されます。
録画に既に注釈がある場合、Remotion で重複して注釈を付けてはいけません。
シーン、字幕、オーディオは完全な時間をカバーし、重複、範囲外、無効な空白があってはなりません。

タイトル、カバー、最初の画面、ナレーション、字幕、リリースコピーには GitHub とプロジェクト名が含まれ、プロジェクト ID、数字、その他の高リスク事実との一貫性を保たなければなりません。3つのプラットフォームのタイトルはそれぞれ30 Unicode 文字を超えてはいけません。3つのプラットフォームの 话题/标签 行にはそれぞれ #github优质项目 #github开源 が含まれていなければならず、合計 5～7 個で重複がなく、プロジェクトタグと、このコンテンツに一致する少なくとも2つの価値/シナリオタグを補完します。リアルタイムのホットタグは最大2つまで補完でき、その回のプラットフォーム証拠がある場合にのみ追加できます。

6. 共通 Remotion アーキテクチャ

新しいリポジトリは共通の Composition のみを使用します。

GitHubProjectDemoTemplate
GitHubProjectCoverPortrait
GitHubProjectCoverLandscape

GitHubProjectCoverFeed は過去互換用のみであり、新しいプロジェクトの Composition リスト、レンダリングタスク、リリースパッケージには含めません。

プロジェクトは、構造化入力として、タイムライン、プロジェクト名、Star、フック、結果、プリセット、素材を渡します。以下は禁止されています。

リポジトリ専用の TSX ビジュアルシステムを新規作成すること。
Root にリポジトリ専用のビデオまたはカバー Composition を登録すること。
OpenMontage または過去のプロジェクトを共通テンプレートのデフォルト事実としてハードコードすること。
レンダリングフェーズで事実を変更したり、素材時間を推測したり、シーンを並べ替えたりすること。

GitHubProjectDemoTemplate はテンプレート ID であり、プロジェクト ID ではありません。Studio は常に http://localhost:3000/ を使用し、入力プロパティを通じてプロジェクトデータを選択します。通常の TSX、CSS、JSON、素材の変更はホットリロードに依存します。依存関係、設定、エントリポイントの変更、サービス応答なし、または回復不可能なコンパイルエラーの場合のみ、再起動を許可し、理由を記録します。CLI の正式レンダリングは Studio ポートに依存しません。

正式レンダリングの前に、統一プリフライトを1回実行します。正式ファイルが完全であること、公開コンテンツで使用される動的フィールドと高リスク声明が有効であること、アクションプランと録画が通過していること、素材時間が有効であること、タイムラインスキーマが通過していること、タイトル長が通過していること、オーディオモードが一致していること、カバーデータが完全であることを確認します。いずれかが失敗した場合は直ちに停止します。

7. オーディオモード

ワークベンチ、content.yaml、task.yaml で一貫した voice.mode のみに従います。

generate-and-mix：Edge-TTS をシリアルに生成し、公開ビデオにミックスします。最終は AAC 48kHz ステレオ、平均音量約 -20～-28dB でなければなりません。
generate-reference：参照オーディオを生成しますがミックスしません。公開ビデオは実際にオーディオトラックなしでなければなりません。
self-recorded：TTS を生成しません。公開ビデオは実際にオーディオトラックなしでなければなりません。SRT はユーザーがナレーションを録音した後の微調整のために保持します。

モードがない場合、または3か所で不整合がある場合、プリフライトは失敗します。オーディオフェーズはタイムラインフェーズの前になければなりません。コピーが変更された後は、オーディオを再生成して実測し、古い持続時間を再利用してはいけません。タイムラインと SRT は今回の実測持続時間を使用しなければなりません。オーディオまたは SRT がタイムラインの持続時間を超える場合、レンダリングに入れてはいけません。

8. カバーと正式レンダリング

カバーは selfmedia-cover-design を実行しなければなりません。ビデオ完成後に一時的に1枚作成することはできません。ビデオは固定で2枚の独立したレイアウトのカバーを生成します：3:4、4:3。ビデオフレームをハードクロップしてはいけません。9:16 のビデオストリームカバーは生成しません。

GitHub シリーズの固定情報順序：GitHub セクション ID、プロジェクト名、プロジェクト名の下のゴールド Star、6～12 文字の具体的な結果。カバーデータはこのプロジェクトからのものでなければならず、3:4 と 4:3 の2つのファイルをそれぞれ生成します。

すべてのプロジェクトがプリフライトを通過した後、一度だけバンドルし、承認された企画に従ってバッチでビデオとカバーをレンダリングします。同じバージョンのために繰り返しプレビューしたり、シーンごとにフレームを抽出して再レンダリングしたりしてはいけません。QA 画像ディレクトリも作成してはいけません。

9. メディアアセット、カバー、マルチプラットフォーム公開

9.1 まず4種類の画像成果物を区別する

1つのプロジェクトで単一の「画像」フィールドのみを登録してはいけません。それぞれ個別に管理する必要があります。

成果物	用途	推奨生成方法	AI 画像生成を使用するか
記事内の挿絵	アーキテクチャ、フロー、インストール手順、実際の機能を説明	公式スクリーンショット、録画フレーム、Remotion 静止画、または SVG。必要に応じて AI を事実を伝えない背景に使用	デフォルトでは使用しない。事実画面を AI で捏造してはいけない
記事カバー	CSDN、知乎、公众号などの記事一覧サムネイル	Remotion/HTML/CSS でのオーバーレイレイアウト	テキストなしの背景には AI を使用可能。ただしタイトル、プロジェクト名、Star、数字は後からオーバーレイする必要がある
ビデオカバー	抖音/Bilibili のビデオまたはフォトエントリカバー	`selfmedia-cover-design` + 共通 Remotion Composition。3:4 と 4:3 を独立生成	AI でビジュアル主体を生成可能。ただしビデオフレームをカバーの代わりにハードクロップしてはいけない
スキルアイコン	SkillHub 探索ページ、スキルパッケージメタデータ	プロジェクトアイコンを再利用、または selfmedia-imagegen でテキストなしのアイコンを生成し、512px にクロップ/エクスポート	使用可能。アイコン内に小さな文字や読めない英語を配置してはいけない

結論：記事カバーとビデオカバーはビデオの最初のフレームを切り取ったものではありません。記事内の挿絵も毎回画像生成を呼び出す必要はありません。実際のスクリーンショットが証拠を担当し、Remotion が安定したレイアウトを担当し、AI 画像生成は事実リスクのない視覚的な背景やアイコンのみを担当します。

9.2 画像アセットの生成順序

各プロジェクトは以下の順序でアセットを準備し、先にカバーを作成してから事実を補完することを禁止します。

公式ソースと事実検証
  → 実際のスクリーンショット/録画/README 証拠
  → 記事構造とビデオストーリーボード
  → どの挿絵が必要かを決定
  → 画像アセットの生成または整理
  → Remotion でプロジェクト名、タイトル、数字、ブランドレイアウトを統一的にオーバーレイ
  → 記事カバー、3:4ビデオカバー、4:3ビデオカバーを生成
  → サイズ/安全エリア/事実一貫性の確認

画像ソースの選択：

実際の製品画面：GitHub、公式デモ、公式ドキュメント、実際の実行ページから直接スクリーンショットまたは録画フレームを抽出。
説明図：優先的に Remotion、SVG、HTML/CSS で生成。アーキテクチャ図、フローチャート、比較表、インストール手順に適しています。
雰囲気背景：selfmedia-imagegen を使用して生成。検証されていないロゴ、Star、バージョン番号、価格、機能の約束は配置しない。
記事カバータイトル：Remotion/HTML/CSS でオーバーレイする必要があり、AI がピクセル内で中国語のテキストを生成することに依存してはいけません。

9.3 カバーフィールドとレイアウトルール

各プロジェクトのカバーデータは個別に保存する必要があり、少なくとも以下を含みます。

cover:
  eyebrow: "GitHub 开源项目"
  project_name: "<プロジェクト名>"
  hook: "<6～12文字の具体的な結果>"
  star_text: "<実際の Star、検証日付付き>"
  focal_asset: "<実際のスクリーンショットまたは事実リスクのない背景画像パス>"
  palette: "<このプロジェクトで選択されたカラーパレット>"
  source_checked_at: "<YYYY-MM-DD>"
  outputs:
    portrait: "02-竖封面-3比4.png"
    landscape: "03-横封面-4比3.png"

GitHub シリーズの固定情報順序：セクション ID → プロジェクト名 → ゴールド Star → 1つの具体的な結果。カバーのメインタイトルは1つのベネフィットのみを表現し、「100 个项目」、完全な機能リスト、インストールコマンドをカバーに詰め込んではいけません。

3:4：1080×1440、上境界約 115px、下境界約 216px、左右各 86px。
4:3：独立して再レイアウトし、3:4 カバーを引き伸ばしたり、ハードクロップしたりしない。
9:16 ビデオフレーム：1080×1920、コアコンテンツは上部 170px、下部 288px、左右 86px のプロジェクト安全エリアに従う。これはビデオカバーのサイズではありません。
タイトル、プロジェクト名、Star、バージョン、その他の正確な数字は、確定的なレイアウトを使用します。AI 画像内に正確なテキストを生成してはいけません。

9.4 記事画像と Remotion の役割分担

記事公開前に記事の種類に応じて選択します。

記事内容	推奨アセット	説明
プロジェクト紹介	1枚のプロジェクトカバー + 1枚の実際の GitHub スクリーンショット + 1枚のコア機能図	コア機能図には SVG/Remotion を使用し、AI で製品スクリーンショットを偽装しない
インストールチュートリアル	コマンドスクリーンショット、ターミナルスクリーンショット、フローチャート	コマンドとパスは実際のプロジェクトからのものでなければならない
アーキテクチャ解説	SVG/Remotion アーキテクチャ図 + 公式 README スクリーンショット	構造を可視化し、事実ソースは公式リポジトリを指す
比較レビュー	Remotion/HTML テーブル + 各プロジェクトの公式リンク	検証済みフィールドのみを比較する
純粋な意見記事	カバー + 少数の雰囲気画像	雰囲気画像は AI 生成可能だが、製品機能の証明に使用してはいけない

9.5 公開プラットフォーム階層

公開はすべてのプラットフォームに同じ原文を送信するのではなく、「コードソース、スキル配布、記事検索、ビデオ配布」の階層に従います。

階層	プラットフォーム	主なタスク	公開内容
コードメインソース	GitHub	権威ある事実、バージョン、Issue、Star	ソースコード、README、CHANGELOG、License、Release
国内コードミラー	Gitee	国内アクセス、ミラーエントリ、代替ダウンロード	GitHub と同期したソースコードと README、GitHub がメインソースであることを明記
スキル配布	SkillHub	スキル検索、インストール、バージョン管理	有効なスキルパッケージ、manifest、中国語説明、アイコン、バージョンチェンジログ
記事検索	CSDN、知乎、掘金、今日头条、公众号	長文検索、説明、トラフィック誘導	プラットフォームに適応した記事、カバー、実際のスクリーンショット、公式リンク
ビデオ/フォト配布	Bilibili、抖音	発見、デモ、フォロー、トラフィック誘導	ビデオ、コラム/フォト、3:4 またはプラットフォーム要求のエントリ画像
オプション拡散	少数派、SegmentFault、开源中国、博客园	技術読者と開発者コミュニティ	内容が実際に適応する場合のみ公開し、数を稼ぐために重複して投稿しない

100プロジェクトの最小公開組み合わせの提案：

GitHub メインソース + Gitee ミラー
  → スキルがあるプロジェクトはさらに SkillHub に公開
  → CSDN / 知乎 / 公众号 から適したプラットフォームの記事バージョンを選択
  → Bilibili / 抖音 にデモビデオまたはフォトを公開

すべての GitHub プロジェクトが SkillHub に公開できるわけではありません。実際に実行可能なスキルパッケージ構造、SKILL.md/manifest.yaml、トリガーワード、自己テスト説明を持つプロジェクトのみが公開されます。一般的なツールリポジトリは GitHub、Gitee、記事/ビデオコンテンツのみを公開します。

9.6 公開前のプラットフォーム適応

各プラットフォームに対して独立した release フィールドを生成し、1つの Markdown をすべてのプラットフォームにそのままコピーすることを許可しません。

release:
  github:
    repo_url: ""
    release_url: ""
    status: "pending"
  gitee:
    mirror_url: ""
    sync_checked_at: ""
    status: "pending"
  skillhub:
    skill_slug: ""
    package_path: ""
    icon_path: ""
    status: "not_applicable"
  articles:
    csdn: { title: "", url: "", status: "pending" }
    zhihu: { title: "", url: "", status: "not_applicable" }
    wechat: { title: "", url: "", status: "not_applicable" }
  media:
    bilibili: { url: "", status: "pending" }
    douyin: { url: "", status: "pending" }

各プラットフォームの完了後、タイトル、本文/README キーセクション、プロジェクトリンク、画像、公開ステータスを読み戻さなければなりません。公開ログには実際の URL、時間、バージョン、ブラウザ環境、検収結論を記録します。公開、送信、削除、古い原稿の上書きは、依然として手動確認アクションです。

10. Release Check

エージェントは以下のマシンフローゲートを完了した後、5つのファイルを renders/release-package/ に書き込みます。ワークベンチの検証が通過した後、アトミックに 发布成品/ に名前を変更し、直接 release_ready に入ります。

ワークベンチプロダクションリクエストが有効な work_id に関連付けられており、ライブラリレコードディレクトリが source_dir と完全に一致すること。そうでない場合は停止し、ソースとリスク検証、録画、レンダリングフェーズに入らない。
Pipeline validate --require-assets が通過していること。
タイムラインスキーマ、素材時間、最初の12秒の証拠ゲートが通過していること。
レンダリングコマンドが成功し、ビデオ出力が 1080×1920、30fps、H.264 であること。
オーディオトラックが voice.mode に準拠しており、TTS と SRT の末尾がビデオの長さを超えないこと。generate-and-mix の最終平均音量は -28～-20dB の範囲内であること。
2枚のカバーのサイズと名前が正しいこと。
3つのプラットフォームがそれぞれ実質的に異なるタイトルと説明を持ち、タイトルは30 Unicode 文字を超えず、説明は実際の段落を保持していること。
3つのプラットフォームのタグにそれぞれ #github优质项目 #github开源 が含まれ、各行 5～7 個の重複しないタグがあり、プロジェクトタグと価値/シナリオタグが現在のコンテンツに一致していること。
projects/index.yaml、projects/task-index.yaml、task.yaml、content.yaml のステータスが一致していること。

不完全な再生、フレーム抽出、画像ごとの確認、OCR、コンタクトシート、20:9 ストレスチャートは行いません。QA 画像や主観的なレポートは生成しません。最終的な画面はユーザーが確認します。

rendered → visual_reviewed の手動確認フェーズを設定しません。重複した候補パッケージもコピーしません。いずれかのマシンコントラクトが失敗した場合、发布成品/ を生成したり、release_ready を報告したりしてはいけません。正式なリリースパッケージは必須で5つのファイルのみです：リリース文案、ビデオ、3:4カバー、4:3カバー、SRT。SRT は固定で 04-字幕.srt と命名します。最終的な画面はユーザーが正式ディレクトリで確認します。

自動アップロードはせず、プラットフォームアカウントを操作せず、公開後のデータも収集しません。

xxjrq/github-project-intro

github-project-intro とは？

お気に入りのAIに質問する

ドキュメント

GitHub 単一リポジトリビデオオーケストレーション

1. 読み取り順序と責任

2. 登録と正式コンテンツユニット

3. ソース、リスク、企画ゲート

4. 実際の証拠と素材時間

5. スクリプトとタイムライン

6. 共通 Remotion アーキテクチャ

7. オーディオモード

8. カバーと正式レンダリング

9. メディアアセット、カバー、マルチプラットフォーム公開

9.1 まず4種類の画像成果物を区別する

9.2 画像アセットの生成順序

9.3 カバーフィールドとレイアウトルール

9.4 記事画像と Remotion の役割分担

9.5 公開プラットフォーム階層

9.6 公開前のプラットフォーム適応

10. Release Check

Individual skills in this repo

xxjrq/geo-article-production

関連スキル

steipete/video-frames

steipete/summarize

openclaw/openclaw

obra/superpowers

affaan-m/ECC

affaan-m/everything-claude-code