card

VoxFlow スキル — カード

テキストを、個性があり統一感のあるビジュアルカード画像のセットに変換します。各カードはそれぞれ独立したウェブページで、すべて同じサイズとスタイルシステムを共有します。Playwright でレンダリングし、PNG として書き出します。

これは静的カード画像スキルです。別の形式の場合は、次のものに切り替えてください。

• 記事 → 縦型カード動画（Slice） — 1080×1920 のリール、13 種類のテーマ → voxflow:slice
• ショート動画／AI クリップ／ナレッジカード動画 → voxflow:video
• 複数話者のポッドキャスト → voxflow:podcast
• TTS／音声／インストール／認証／クォータ → voxflow:hub

`voxflow` コマンドの実行時に、stderr に `` の行が表示された場合は、続行する前にただちに `voxflow upgrade -y` を実行してください。質問したり、先に要約したりしないでください。`voxflow upgrade` が `Unknown command` でエラーになる場合（CLI が 1.12.0 より前の場合）は、`npm i -g voxflow@latest` に切り替えてください。

ステップ 0 · サインイン確認（必須、最初に実行）

このスキルは VoxFlow の一部であり、サインイン済みアカウントが必要です。ほかのことを始める前に、質問や調査、デザインを始める前に、ログイン状態を確認してください。

voxflow status

• アカウントと残りのクォータが表示される → サインイン済みです。ワークフローに進んでください。
• エラーが発生する／「not logged in」と表示される → 停止してください。voxflow login を実行します（ブラウザーが開きます。Google またはメールの OTP を使用）。ユーザーの操作が完了するまで待ってから、voxflow status を再実行してください。ログインに成功するまで、パラメーターを収集したり、カードを生成したりしないでください。
• voxflow: command not found → まず npm install -g voxflow を実行し、その後 voxflow login を実行してください。

この確認を省略したり、未認証のユーザー向けにカードを生成したり、トークンを捏造したりしないでください。キャッシュされたトークンは ~/.config/voxflow/token.json に保存されます。CI では VOXFLOW_TOKEN が使用されます。

概要

ソースコンテンツから、共有しやすいビジュアルカードのセットを作成します。各カードをそれぞれ独立したウェブページとして扱い、すべてのカードでサイズとスタイルシステムを統一します。Playwright でレンダリングして画像を書き出し、弱いカードを改善します。

デザインの基本基準

references/taste.md は、あらゆるカードの型、テーマ、レイアウト、デザイン言語に適用される制約チェックリストです。ワークフローの開始時に読み上げるための儀式ではなく、デザイン時に効力を持つ最低基準として扱ってください。

• references/taste.md を読み込むのは、ワークフローの開始時ではなく、次の 2 つのタイミングだけです。
  • テーマのプリセットとデザイン言語を選ぶとき（ワークフローのステップ 4）。選択が必須制約に違反しないようにします。
  • QA スコアリング時（ワークフローのステップ 7）。明示的な確認項目の 1 つとして使います。
• ほかのステップ（パラメーターの収集、調査、コピーの計画）では、references/taste.md を再読み込みする必要はありません。選択済みのプリセットとデザイン言語を通じて、制約が反映されます。
• 中心となる目標は、AI 生成デザインにありがちな明白な痕跡を取り除くことです。
• 必須制約には、デフォルトの Inter フォントを使わない、純粋な黒を使わない、デフォルトの中央揃えヒーローを使わない、同じ大きさのカードを 3 枚並べた構成にしない、汎用的な AI コピーの語り口にしない、偽物に見えるデータを使わない、などがあります。
• デザインの基本基準は、情報を空にすることを意味しません。references/taste.md の情報密度ルールに従い、ユーザーがポスターのみ、またはシネマティックのみのセットを明示的に求めていない限り、実用的な情報カードを少なくとも 1 枚含めてください。
• テーマのプリセットまたはデザイン言語が references/taste.md と矛盾する場合、ユーザーが禁止されたスタイルを明示的に求めていない限り、デザインの基本基準を優先してください。

入力

以下を収集または推測します。

• content：元の文章、アウトライン、メモ、URL、トピック、または概要。
• ratio：ユーザーが 3:4、9:16、または別の比率を指定しない限り、デフォルトは 1:1 です。
• count：コンテンツの密度に基づいて自動的に数を決定します。明示された数量も受け付けます。
• style：明示的なスタイルの指示、ブランド上の制約、対象読者、雰囲気、プラットフォームを受け付けます。
• content-language：zh / en / mixed。ソースから推測します。曖昧でフォント選択に影響する場合のみ確認します。references/fonts.md の言語オーバーライドに使用します。
• output：ユーザーが指定しない限り、cards/<slug>/ のような分かりやすいローカルフォルダーを選びます。

重要な事実が最新の情報に左右される場合や、見解が分かれている場合は、計画の前に検索または確認します。調査内容がコンテンツに影響する場合は、ユーザーが出典を確認できるようにします。簡易確認ではなく、詳細な調査が必要となる条件については、「調査と事実確認」セクションを参照してください。

調査と事実確認

入力だけではカードのコンテンツとして成立しない場合に限り、パラメーター収集とデザイン作業の間にこの手順を挿入します。

• content が次のいずれかに該当する場合は、詳細な調査を行います。トピックを表す語句、簡潔な概要の一文、まだ本文を読んでいない URL、ツイート程度の長さのアイデア、質問、または「X を説明して／取り上げて／X についてカードを作って」という依頼。
• content がすでに自己完結した記事、文字起こし、構成済みのメモ、完成したアウトライン、またはユーザーがカードの題材として使うことを明確に意図したテキストである場合は、詳細な調査を省略します。
• 調査が必要な場合は、ビジュアルの計画に入る前に、事実のアウトラインを作成します。
  • 中心となる主張または論旨。
  • 具体的な数値、名称、日付、仕組みを含む、3～7 個の補足ポイント。
  • 重要な事実ごとの出典。sources.md に記録できる URL または文書の参照先を含めます。
  • ユーザーが確認すべき未解決の疑問や、見解が分かれている点。
• 事実のアウトラインをユーザーに提示し、テーマやデザイン言語の選定に進む前に、確認、追加、修正を依頼します。これは後のコンセプト／ビジュアル確認とは別の手順です。
• この手順で作るのは「骨子」、つまり主張と根拠であり、完成したカード用の文章ではありません。カードごとの見出し、解説、要点は、確認済みの骨子に基づき、後のコンテンツ構成（ステップ 5）で作成します。
• 事実のアウトラインが確認されたら、この段階で収集した出典を出力フォルダー内の sources.md に記録します。

トリガーの例

次の場合は、詳細な調査を行います。

• 「做一组讲 MCP 协议的卡片」— トピックだけで、本文がありません。
• 「把这篇文章做成卡片：https://example.com/post」— この会話内でまだ内容を読んでいない URL です。
• 「想做一组讲 RAG 优化技巧的卡片,重点放在 chunking 上」— トピックと切り口はありますが、具体的なポイントやデータがありません。
• 「Cloudflare Durable Objects 适合什么场景?做几张卡片」— 質問、または「X を説明して／取り上げて」という形式の依頼です。
• 対象を示しているものの、根拠が含まれていない単独のツイート、見出し、または一行の概要。

次の場合は、詳細な調査を省略します。

• ユーザーが、記事、ブログ投稿、文字起こし、インタビューの本文を全文貼り付けている場合（自己完結したソースコンテンツがおよそ 500 語以上あるもの）。
• ユーザーが構造化されたメモ、議事録、講義ノート、または各カードのタイトルと 2～4 個のポイントがすでに列挙された完成済みのアウトラインを提供している場合。
• ユーザーが自分で完成させた文章を提供し、ビジュアル面の調整だけを依頼している場合（「把这段话排成卡片」、「美化一下这段文案」）。
• 入力の長さにかかわらず、ユーザーが明示的に「不要查资料 / 直接基于这段写 / 不要扩展」と指定している場合。

境界線上の入力

• 短い概要と大きな目標が釣り合っていない場合 — 例：「200語の要約」と「7枚のカードに展開して」。概要の情報量が少なく、目標の枚数を埋められないため、調査を行い、展開する前に概要の根拠が不足していることを伝えます。
• 記事に「最新のデータを少し追加して／事例を加えて」とある場合 — 依頼された追加内容だけを対象に範囲を絞って調査します。ユーザーがすでに書いた部分は再調査しません。
• 根拠のない見出し付き箇条書き — 例：「1. 性能が向上 2. より安価 3. より安全」。具体的な数値や事例を添えるために調査を行います。そうしないと、カードがAIの埋め草のように見えてしまいます。
• 記事にユーザー自身の意見や見解が含まれている場合 — 元の内容についての調査は省略しますが、その意見をそのまま残すか、構成し直すかをユーザーに確認します。
• 本文をすでに取得し、この会話の前のやり取りで確認済みのURL — 貼り付けられた内容として扱い、調査は省略します。ただし、URLは引き続き sources.md に記録します。

入力が曖昧な場合は、推測するのではなく、確認の質問を1つ尋ねます（「この内容はそのままカードにしますか、それとも先に資料を調べてから展開しますか？」）。調査の判断を誤ると、ユーザーの時間かモデルの調査予算のどちらかを無駄にしてしまいます。

ユーザーへの質問

コンセプトの計画を始める前に、生成に必要なパラメーターが不足していないかを確認し、最初に一度だけ質問します。「ユーザーへの質問」は、特定のツールの呼び出しを必須とするのではなく、どの環境でも使える判断方針として扱います。コーディングエージェントによって使用できる対話手段は異なるため、このスキルは、構造化された質問ツールがある場合もない場合も、またエージェントの動作モードで使用が推奨されない場合も、機能する必要があります。

• まず、content、ratio、count、theme/style、platform/audience、output/constraints の既知の値をすべて抽出します。
• 意味のある選択肢が残っている場合は、計画を始める前に生成パラメーターをユーザーに確認します。「作って／生成して／制作して／すぐに画像を出して／すばやくエクスポートして」とユーザーが言った場合も、必ず確認します。これらの表現は作業の実行を求めるものであり、パラメーターを黙って推測してよいという意味ではありません。
• 回答によって出力が大きく変わる場合に質問します。優先順位は、content/source intent、ratio、count、theme/style、platform/audience、output/constraints の順です。
• 原則として、簡潔な質問は最大3つまでにします。ユーザーが設定項目を明示的に選びたいと希望する場合、または出力の影響が大きい場合に限り、最大5つまで質問します。
• ユーザーの最初の依頼ですでに明示されているパラメーターは、再度質問しません。
• 質問しないよう明示されている場合、またはデフォルトのパラメーターを明示的に承認されている場合に限り、質問の手順を省略します。その場合はデフォルトを使用し、実行の前または実行中に前提を簡潔に伝えます。

互換性の方針

現在の環境で最も適した質問手段を使用します。

• 環境に ask_user_question、ask question、または同等のネイティブな確認機能がある場合は、それを使用して作業を妨げている疑問点を確認します。
• 環境にネイティブな質問機能がない場合は、通常の会話で直接質問します。
• 一度に尋ねる質問は2～5つまでにします。
• 不足情報が作業の妨げにならない場合も、最終出力に影響するパラメーターの確認を一度行います。ユーザーがすでにデフォルトを承認している場合、または質問をしないよう求めている場合は、妥当な前提を置いて続行します。
• 重要な前提は、最終回答、sources.md、または credits.md に明記します。

停止条件

次のいずれかに該当する場合に限り、生成を始める前に停止して質問します。

• 利用可能な content、トピック、URL、またはソース資料がない。
• ソースの意図が曖昧で、選択を誤ると作業が無駄になる。たとえば、「この文章をそのまま使う」のか「調査してトピックを展開する」のかが不明である。
• 依頼された比率とプラットフォームの組み合わせが矛盾している、または1回のエクスポートでは実現できない。
• ビジュアルの方向性を決めるブランド、法的要件、アクセシビリティ、または正確な文言に関する制約があるが、必要な情報が不足している。
• 調査によって、中心的な主張を左右する見解の分かれた事実が判明した。

それ以外の場合は、意味のある生成パラメーターの確認を一度行った後、前提を記録したうえで作業を続け、前提を sources.md または最終回答に記録します。

比率の質問

以下のデフォルトの選択肢を使用します。

• 一般的なソーシャル共有向けの正方形カードには 1:1。
• テキストや画像を多く使う投稿向けの縦長グラフィックカードには 3:4。
• ストーリー、リール、ショート動画のカバー、またはモバイルを優先するカードには 9:16。

ユーザーが指定した場合は、4:5、16:9 などの自由形式の比率や、正確なピクセルサイズも受け付けます。

枚数の質問

以下のデフォルトの選択肢を使用します。

• コンテンツに基づいて自動で推奨する。
• コンパクトなストーリーには 3 枚。
• 標準的な解説には 5 枚。
• より詳しいカルーセルには 7 枚。

自動で推奨する場合は、内容を窮屈に詰め込まずにアイデアを網羅できる最小枚数を選びます。解説には3～7枚、告知には1～3枚を優先します。

テーマの質問

プリセットの全カタログをユーザーに直接見せないでください。references/themes/presets.md を読み込み、ビジュアルの方向性が重要な場合は references/design-languages.md も読み込んでください。そのうえで、コンテンツ、プラットフォーム、対象者、共有の目的に基づき、シナリオ別のスタイル候補を3～5個提案します。ユーザーが選んだシナリオを、最終的なテーマプリセットとデザイン言語の組み合わせに内部で対応付けます。

スタイルをユーザーに選んでもらう際は、推奨を1つだけ示して、曖昧な「変更しますか？」と尋ねるだけにしないでください。以下を含む具体的な候補を3～5個提示します。

• ユーザー向けの短いスタイル名
• 最適な状況
• ビジュアルの説明（1行）
• 内部で使用するテーマプリセットとデザイン言語の対応付け

出力が適切なものになり、同じような見た目ばかりにならないよう、2層の選択ロジックを使用します。

1. デフォルトの推奨レイヤー：

   • コンテンツの種類、プラットフォーム、対象者、共有の目的に基づき、適合度の高いスタイルを3～5個提示します。
   • 推奨候補はユーザーのタスクに十分合うものに絞り、どの候補を選んでも大幅な手直しなしで成立するようにします。
   • トークン名だけでなく、見た目に明確な違いのある候補を優先します。たとえば、保守的なレポート、データポスター、ソーシャルノート、雑誌風解説、強い主張などです。

2. バリエーション調整レイヤー：

   • ユーザーがスタイルを明確に指定していない場合は、常に最上位のデフォルトを選ぶのではなく、互換性のあるスタイル群の中でローテーションします。
   • 類似したタスク間では、テーマプリセット、主要なデザイン言語、モディファイア、レイアウトレシピ、ビジュアルアンカー、表面の比喩、タイトル構成のうち、少なくとも2つの要素を変化させます。
   • コンテンツとの意味的な適合性を保ちます。トピック、プラットフォーム、アクセシビリティ、事実の明確さを損なう、ランダムな目新しさは避けてください。
   • 最終的に選んだ組み合わせをコンセプトプランまたは sources.md / credits.md に記録し、バリエーションを確認できるようにします。

以下のような、ユーザー向けのシナリオラベルを使用します。

• エンジニアリングインフォグラフィック：engineering-paper、product-manual、または porcelain-research に対応付けます。
• ビジネスブリーフィング：quiet-report、product-manual、または porcelain-research に対応付けます。
• 強い主張：bold-editorial、magazine-eink、または newsroom-paper に対応付けます。
• ソーシャル向け製品メモ：social-notebook、magazine-eink、または bold-editorial に対応付けます。
• エディトリアル／マガジン：magazine-eink、dune-gallery、field-notes、または kraft-editorial に対応付けます。

デザイン言語の選択には、以下のようなユーザー向けのシナリオラベルを使用します。

• 技術的だがデザイン性もある：editorial-artifact + cutaway + annotation に対応付けます。
• マガジン風解説：image-led-magazine + edge-crop + asymmetric-space に対応付けます。
• 強い主張：swiss-poster + scale-contrast + split-field に対応付けます。
• ニュース速報：newsroom-poster + stamp-label + big-number に対応付けます。
• アーカイブ資料：field-notes + layered-depth + receipt-form に対応付けます。
• 製品見本：product-catalog + edge-crop + annotation に対応付けます。
• データポスター：data-poster + scale-contrast + big-number に対応付けます。

ユーザーが選択したら、コンセプトプランに進む前に、選択されたテーマの方向性、最終的なプリセット、デザイン言語の組み合わせ、およびそれが適している理由を伝えます。

デザインコンテキスト

新しいビジュアルシステムを考案するより、既存のデザインコンテキストを優先してください。

• ビジュアルの方向性を決める前に、必ず references/taste.md を読み込んでください。そこにあるAIらしさを排除するルールを、ビジュアルDNAの要約に反映してください。
• カードを計画する前に、ユーザー提供またはローカルのブランドアセット、過去のカードセット、スクリーンショット、Figma／UIキットのリファレンス、プロジェクトのデザインシステム、既存のウェブページ、コードスタイルなど、結果に影響する要素を探してください。
• ユーザーがエディトリアル、雑誌、電子ペーパー、プレゼンテーション風、または画像主体のカードスタイルを求めた場合は、references/magazine-card-adaptations.md を読み込み、カードに適した要素だけを適用してください。対象は、エディトリアルの外枠、コンパクトなレイアウトの型、落ち着いたインク／用紙の配色、画像スロットのワークフローです。
• カードセットにより強いデザインが必要な場合、またはスタイルが明確にミニマルでない場合は、references/layouts/card-layouts.md を読み込み、HTMLを書く前にレイアウトの指針として使用してください。
• カードセットにより強いデザインやスタイルのバリエーションが必要な場合、またはユーザーがビジュアルの方向性を選べるようにする場合は、references/design-languages.md を読み込み、主要なデザイン言語を1つと、補助要素を1～2つ選んでください。
• 簡潔なビジュアルDNAの要約を作成してください。要約には、配色、タイポグラフィの雰囲気、情報密度、角丸、影／奥行き、画像やイラストの扱い、レイアウトのリズム、コピーのトーンを含めてください。
• 信頼できるデザインコンテキストが見つからない場合は、コンテンツ、対象読者、プラットフォーム、求められる雰囲気からビジュアルの方向性を導き、その前提を計画に明記してください。

テーマプリセット

テーマプリセットは出発点として使用し、CSSをそのままコピーしないでください。カードセットごとに新しいトークンブロックを定義し、配色をコンテンツに合わせて調整してください。

• テーマを選ぶ前に references/taste.md を適用してください。プリセットは配色や雰囲気の参考にはなりますが、Inter、純粋な黒、中央揃えのヒーローセクション、3つの均等なカード、AIらしい紫から青へのグラデーション、ネオングロー、偽のデータ、AI風のコピーを再び取り入れてはいけません。
• ユーザーがスタイルの選択肢を求めた場合、スタイルが曖昧な場合、またはカードセットに明確なビジュアルの方向性が必要な場合は、references/themes/presets.md を読み込んでください。
• 適切な場合は、コーディング前にシナリオに基づくテーマ案を3～5個用意してください。プリセットのカタログ全体をユーザーに提示しないでください。
• 選んだシナリオの方向性をカタログ内の最終プリセットに置き換え、新しいローカルトークンで調整してください。
• 外部のテーマCSSをそのままコピーしないでください。必要な配色や挙動を、カードのローカルスタイルとして再構成してください。

デフォルトの推奨ルール：

• 技術、API、アーキテクチャ、インフラに関するコンテンツ：engineering-paper を優先してください。代替案は product-manual と porcelain-research です。
• ニュース、リリース、製品アップデート、変更履歴、インシデント：newsroom-paper を優先してください。代替案は quiet-report と engineering-paper です。
• ビジネス、資金調達、成長、製品に関するストーリー：quiet-report を優先してください。代替案は product-manual と porcelain-research です。
• 意見、論評、強いフックで共有を促すコンテンツ：bold-editorial を優先してください。代替案は magazine-eink と newsroom-paper です。
• 小紅書、ライフスタイル、消費者向け製品に関するコンテンツ：social-notebook を優先してください。代替案は magazine-eink と bold-editorial です。
• エディトリアル、講演の要約、長文、文化、エッセイ、プレミアムなカルーセルコンテンツ：magazine-eink を優先してください。トピックに応じた代替案は dune-gallery、field-notes、kraft-editorial です。
• CLI、セキュリティ、ターミナルツール：engineering-paper、product-manual、newsroom-paper を優先してください。terminal-green は、ユーザーが明示的にターミナル風を求めた場合にのみ使用してください。
• ユーザーが明示的にそのビジュアル言語を求めない限り、ネオン、サイバーパンク、ターミナル風、光るダークダッシュボード、青から紫へのAIグラデーションをデフォルトにしないでください。

エディトリアルマガジンモード

カードセットにプレゼンテーションや雑誌のデザインを取り入れる場合は、references/magazine-card-adaptations.md を使用します。このモードは op7418/guizang-ppt-skill に着想を得ていますが、静的なカード書き出し向けに調整されています。

• カードに適したアイデアのみを再利用します。エディトリアルな装飾、フッターのメタデータ、視認できるページ番号、セリフ体やディスプレイ書体によるタイトルの階層、等幅フォントのメタデータ、控えめなインク／紙の配色、コンパクトなレイアウトの類型が該当します。
• スライド固有の挙動は再利用しないでください。横方向のナビゲーション、WebGL の背景、Motion One の表示アニメーションシステム、vh によるスライドのサイズ指定、PPT 専用のクラス名が該当します。
• コーディングの前に、各カードの類型を選びます。エディトリアルな表紙、セクションの区切り、大きな数字、左に説明・右にビジュアル、画像による証拠のグリッド、パイプライン／プロセス、問いかけで締めくくるカード、大きな引用、ビフォー／アフター、メイン画像＋サイドバーのいずれかです。
• chrome と kicker は異なるコンテンツ上の役割として扱います。chrome は固定のメタデータまたはシリーズ内のナビゲーション、kicker はそのカード固有のフックです。同じアイデアを両者で繰り返してはいけません。
• 画像を使う場合は、素材を探したり生成したりする前に、画像スロットと比率を定義します。生成画像はカード用素材に限ります。タイトル、ページ番号、透かし、キャプション、カードの枠線を含めてはいけません。

レイアウトの要件

読みやすさだけでなく、視覚的な品質も求められる場合は、references/layouts/card-layouts.md を使用します。

• 最初のレイアウト基準として references/taste.md を適用します。ユーザーが明示的に求め、その選択に妥当な理由がない限り、中央揃えのヒーローを既定とするレイアウトや、均等な3枚のカードのレイアウトは採用しません。
• HTML を書く前に、カードごとに1行を設けたレイアウト計画を作成します。カードの役割、レイアウトの構成、視覚的な主役、テキストの密度、素材のスロット、レイアウト上のリスクを含めます。
• 情報密度はセット全体で計画します。実質的な解説セットでは、すべてのカードを低密度にしないでください。具体的な要点を2～4個含む、仕組み、根拠、チェックリスト、比較、要点をまとめるカードのいずれかを少なくとも1枚含めます。
• すべてのカードに視覚的な主役を設ける必要があります。タイポグラフィ、数字、画像、成果物、図、フォーム、スタンプ、地図、スクリーンショット、カスタム CSS オブジェクトなどを使用できます。主役が「なし」の場合は、カードのコンセプトを再設計します。
• 1～3枚のカードでは、少なくとも2種類のレイアウト構成を使用します。4～7枚では少なくとも3種類、8枚以上では少なくとも4種類を使用し、3～4枚ごとにリセットカードを追加します。
• セット全体で「見出し＋均等なグリッド＋フッター」の構成を繰り返さないでください。スタイルを統一するのはよいことですが、構成まで繰り返すのは避けます。
• 細い線、座標グリッド、枠付きパネルを、デザインの既定の表現にしないでください。より強い視覚的な主役を支える場合にのみ使用します。
• トリミング、重なり、斜めの配置、スケールのコントラスト、切り抜き形状、スタンプ、ラベル、テープ、大きな画像やオブジェクトを主役にする配置、非対称な余白といった構成上の工夫を優先します。
• コンセプトを計画する際、レイアウトやデザインの品質が重要な場合はレイアウト計画を提示します。最終 QA では、レンダリングした各カードに実際に使用したレイアウトを明記します。

デザイン言語システム

テーマプリセットとは独立して、カードセットのビジュアル文法を定義するには、references/design-languages.md を使用します。

• テーマプリセットは配色と文字のトーンを制御し、デザイン言語は構成、視覚的な焦点、視覚的メタファー、質感、テンポを制御します。
• 主要なデザイン言語を1つ選び、必要に応じて修飾要素を1〜2個追加します。ユーザーが折衷的なバリエーションを求めない限り、言語や修飾要素を3つ以上組み合わせないでください。
• 主要なデザイン言語を選んだら、references/design-languages/<name>.md から個別の仕様ファイルを読み込み、「必ず使用」「使用禁止」、タイポグラフィ、レイアウト、密度、アセット、QAの各ルールに従います。
• サポートされている主要言語には、editorial-artifact、swiss-poster、image-led-magazine、field-notes、newsroom-poster、product-catalog、cinematic-still、data-poster があります。
• サポートされている修飾要素には、scale-contrast、edge-crop、diagonal-tension、layered-depth、split-field、asymmetric-space、cutaway、stamp-label、receipt-form、annotation、big-number、paper-cut、map-route があります。
• ユーザーは、「技術的だがデザイン性のあるもの」「雑誌風の解説」「力強い主張」「ニュース速報」「アーカイブ資料」「製品標本」「データポスター」などのプリセットの組み合わせを選べます。
• カードセット全体を通じてデザイン言語の組み合わせを一定に保ちつつ、カードごとにレイアウトのパターンと視覚的なアンカーを変化させます。
• カードセットで複数の主要言語を組み合わせる場合は、セット全体の主要言語を1つ指定し、ほかの言語はカードごとのアクセントとしてのみ使用します。

ワークフロー

1. パラメーターを収集し、必要に応じてユーザーに質問します。

   • 元の依頼から既知のパラメーターを抽出し、繰り返し尋ねないでください。
   • 「ユーザーへの質問」ポリシーを適用します。リスクの低いデフォルト値は推定し、真に作業を妨げる問題についてのみ質問し、現在のエージェントの対話モードに合わせて対応します。
   • この段階では references/taste.md を読まないでください。これは後のステップ4（テーマ／言語の選定）とステップ7（QA）で読み込みます。
   • ユーザーが質問なしで進めるよう明示的に依頼した場合、またはデフォルト値を明示的に承認した場合に限り、質問の手順を省略します。直接生成、クイックエクスポート、「帮我做」の依頼でも、重要な選択肢が不足している場合は、最初に一度だけパラメーターを確認する必要があります。

2. 条件に応じた詳細調査と事実の概要確認。

   • 「調査と事実確認」のトリガールールを適用します。入力がトピック、URL、ブリーフ、質問、または「Xについてカードを作成して」という依頼の場合は調査を行い、すでに記事全文、文字起こし、構造化メモ、完成したアウトラインが入力されている場合は省略します。
   • トリガーされた場合は、事実の概要（中心的な主張、具体的なデータを含む3〜7件の補足ポイント、出典、未解決の疑問）を作成します。事実、切り口、または対象範囲によってカードの構成が変わる可能性がある場合はユーザーに提示して返答を待ちます。それ以外の場合は、最初のパラメーター確認後に、明確で争いのない事実と出典を記録します。
   • 確認を重視するワークフローでは、この確認をステップ6の後続のビジュアル／コンセプト確認とは別に扱います。実行を優先するワークフローでは、「停止条件」に該当しない限り、進行を止めずに短い進捗報告として伝えます。
   • 確認済みの出典は出力フォルダー内の sources.md に保存します。
   • トリガーされない場合、またはユーザーが調査なしで進めるよう明示的に依頼した場合は、完全に省略します。

3. コンテンツを展開し、構成を整えます。

   • 確定した骨子（またはステップ 2 を省略した場合は入力内容）から、中心的なメッセージ、対象読者、感情に訴える要素、主張、裏付けとなるポイントを抽出します。
   • count が指定されていない場合は、内容を詰め込みすぎずにアイデアを網羅できる最小のカード数を選びます。解説コンテンツでは 3～7 枚、お知らせでは 1～3 枚を優先します。
   • 各カードのタイトル、サブタイトル、キーとなるビジュアルのアイデアを決めます。
   • 最終的なコピーを書く前に、セット全体の情報密度の流れを決めます。3 枚の場合は、デフォルトで「フック／解説／まとめ」とします。5 枚の場合は「フック／背景／仕組み／根拠／まとめ」、7 枚の場合は「フック／背景／仕組み／根拠／対比／アクション／締め」とします。
   • ユーザーがポスターのみのカードを希望している場合を除き、具体的な主張と、それを裏付ける 2～4 個のポイント、ラベル、所見、手順、または注釈を含むカードを少なくとも 1 枚入れます。
   • コピーの計画段階で、AI が書いたような表現、一般的な仮置きのブランド名や名前、作り物めいた数字を取り除きます。

4. テーマプリセットとデザイン言語を選び、レイアウト案を作成します。

   • ここで references/taste.md を読み込み、以降のこのステップにおけるデザイン決定すべてに適用されるチェックリストとして確認します。厳守すべき制約はすべて適用してください。
   • ステップ 1 で選んだテーマプリセットを、好みの基準に照らして確認するか、必要に応じて選び直します。厳守すべき制約に反するプリセットは、続行前に差し替えます。
   • 2 層のスタイル選択ロジックを適用します。まず適合度の高い推奨候補から選び、次にユーザーが特定のスタイルを指定していない場合は、互換性のあるバリエーションを加えます。
   • バリエーションはメタデータだけでなく、見た目にも反映させます。テーマやデザイン言語のトークンとともに、レイアウトの構成、ビジュアルの主役、表面のメタファー、構図の工夫も入れ替えます。
   • 各カードに具体的なレイアウト構成を 1 つ割り当てます。より優れたデザインを目指す場合は references/layouts/card-layouts.md を使用します。雑誌風・エディトリアル調のカードでは、references/magazine-card-adaptations.md も使用します。
   • スタイルの選択に幅がある場合、またはユーザーがデザインのバリエーションを求めている場合は、デザイン言語の組み合わせを割り当てます。選んだ主要言語の仕様ファイルを references/design-languages/<name>.md から読み込みます。
   • references/fonts.md を読み込み、フォント選択アルゴリズムを実行します。選択したプリセット × デザイン言語 × コンテンツの言語に基づいて、役割ごとの候補プールを取得し、厳守すべき制約に基づいて絞り込んだうえで、セット全体に使うフォントを役割ごとに重み付きランダムで選びます（出力スラッグをシードにして、同じセットでは同じ結果を再現できるようにしつつ、トピックが異なる場合は選択結果も変わるようにします）。選んだディスプレイ用、セリフ、サンセリフ、等幅の各フォントファミリーを sources.md に記録します。
   • 各カードについて、本文コピーを書く前に、ビジュアルの主役と構図の工夫を特定します。テキストブロックだけ、均等なボックスだけ、または背景グリッドだけで構成される場合は、より強いレイアウトを選ぶか、デザイン性を抑えた実用カードとして意図的に指定します。
   • 低密度を重視する主要言語の制限を守ります。情報の詳細はセット内の別のカードに移し、swiss-poster、cinematic-still、引用、表紙、締めのカードに詰め込みすぎないでください。

5. コンセプトを提示し、確認を求めます。

   • 確定したアスペクト比、カード枚数、選択したテーマの方向性とプリセット、選択したデザイン言語／修飾要素、コンテンツの概要、1枚目のカードのコンセプトを提示します。
   • レイアウトの品質が重要な場合は、カードの役割、レイアウトのレシピ、視覚的なアンカー、構図の工夫、テキストの密度、アセットの配置枠を含むレイアウト計画も提示します。
   • 表紙や主要な言語表現を意図的に低密度にする場合は、有用な詳細をどのカードで伝えるかを明示します。
   • 1枚目のカードは、インパクトのある明確な表紙にします。トピックが瞬時に伝わり、好奇心をかき立て、開いて共有する価値を感じられるものにしてください。
   • コンセプトの確認対象は、表紙のコンセプト、コンテンツの概要、ビジュアルの方向性のみです。すでに確定したアスペクト比、枚数、テーマ、プラットフォーム、出力上の制約については、質問を繰り返さないでください。
   • 影響が大きいタスクの場合、または質問の段階を経てもスタイルが曖昧な場合は、コーディングの前に3～5種類のビジュアルの方向性を提示します。ブランドに沿った保守的な案、構成的なインフォグラフィック案、ソーシャルメディア向けの案、雑誌風／エディトリアルな案、より大胆で共有されやすい案など、明確に異なる選択肢を含めます。
   • 各方向性について、表紙のコンセプト、全体的なビジュアル言語、最適な利用シーンを説明します。
   • ユーザーがすでにビジュアルスタイルを指定している場合、確認なしで進めるよう明示的に求めている場合、または迅速な直接エクスポートを必要としている場合は、コンセプト案の提示を省略します。
   • Stop Conditions が適用される場合、またはコンセプトの方向性によって出力が大きく変わる可能性がある場合は、コーディング前にユーザーへ確認を求めます。ユーザーがすでにパラメーターを確認しており、コンセプトもその選択に沿っている場合は、進捗報告としてコンセプトを簡潔に伝え、そのまま実装に進みます。

6. カードのウェブページを作成します。

   • 各カードにつきHTMLページを1つ作成し、card-01.html、card-02.htmlのように規則的な名前を付けます。
   • 共有のCSSファイルまたは共有のデザイントークンを使用して、サイズ、タイポグラフィ、余白、配色、角丸、コンポーネントのスタイルに一貫性を持たせます。
   • ステップ4で決定したreferences/fonts.mdの選定アルゴリズムに従ってフォントを選び、assets/fonts/fonts.cssをインポートするか、使用するフォントをcards/<slug>/assets/fonts/にコピーしてローカルの@font-faceで参照し、ローカルに埋め込みます。CDNからフォントを読み込まないでください。references/taste.mdを満たす色を選びます。デフォルトでInterを使用せず、純粋な黒を使わず、一般的なAI風の紫から青へのグラデーションやネオングロー効果を避けてください。
   • アスペクト比に基づく固定キャンバスサイズを明示的に指定します。推奨する基本サイズは次のとおりです。
     • 1:1：1080x1080
     • 3:4：1080x1440
     • 9:16：1080x1920
     • カスタムのa:b：ユーザーが正確なピクセル数を指定していない場合は、幅を1080、高さをround(1080*b/a)にします。
   • すべてのカードを単一の固定サイズの.cardルート内に収めます。bodyをスクロールさせないでください。
   • 画像にテキストを埋め込まず、実際のHTML／CSSテキストを使用します。
   • すべてのカードで同じスタイル言語を用い、コンテンツに合わせて構図だけを必要な範囲で変えます。
   • 個々のカードを実装する前に、選択したレシピに対応する共有レイアウトのプリミティブをCSSで定義します。各カードには、.layout-cover、.layout-split、.layout-artifact、.layout-rail、.layout-compare、.layout-quote、.layout-checklistなど、識別できるレイアウト親クラスを設定します。
   • エディトリアルマガジンモードでは、ローカルのCSSにカード専用クラスを定義してシェルを構築します。PPTレイアウトクラスは、カードセットのCSSで定義し、調整したもの以外は貼り付けないでください。

7. 各カードを採点し、再生成します。

   • 採点する前に references/taste.md を再読み込みし、QA の合格基準として確認してください。記憶だけを頼りに採点しないでください。
   • 判定する前に、すべてのカードをレンダリングしてスクリーンショットを撮ってください。
   • 各カードについて、次の項目を採点してください。
     • 境界：明らかな切り抜き、意図しないスクロールバー、キャンバス外のテキスト、端に接しすぎている重要な要素がないこと。
     • 色：配色が読みやすく、魅力的で、意図が感じられ、依頼されたスタイルと一貫していること。
     • レイアウト：階層が明確で、余白のバランスが取れ、コンテンツの密度がアスペクト比に合っていること。
     • 情報価値：セット内に、雰囲気重視の見出しだけではなく、実践的または具体的な詳細を含むカードが少なくとも1枚あること。情報量の少ないカードがある場合は、その役割または主要言語によって正当化されていること。
     • レイアウトの要件：計画したビジュアルの主役が存在し、十分に目立っていること、スクリーンショットからデザインレシピを識別できること、カードごとに同じ構成が繰り返されていないこと。
     • デザイン表現：細い線、グリッド、枠で囲まれたパネルに主に依存していないこと。これらの要素はビジュアルの主役を引き立てる二次的な要素である必要があります。
     • デザイン言語：選択した主要なデザイン言語と修飾要素がスクリーンショットから認識でき、該当する仕様ファイルの Must Use ／ Must Not Use のルールを満たしていること。
     • テイストの最低基準：references/taste.md にあるすべての必須制約を満たしていること。Inter のデフォルト使用、純黒、中央揃えのデフォルトヒーロー、メイン部分を3つの同等なカードで構成するレイアウト、AI っぽい文章、偽物に見えるデータ、ネオンやグローを使った AI 風の美観がないこと。
     • 該当する場合の編集上の規律：クロームとキッカーの内容が重複していないこと、画像フレームのトリミング規則が一貫していること、生成されたアセットに独自のスライド／カード用クロームが含まれていないこと。
   • いずれかの項目に不合格となった場合、そのカードを修正して再レンダリングしてください。カードごとの修正は最大3ラウンドまでです。
   • 3ラウンド後も不合格のカードは、残るリスクを報告し、最良のバージョンを維持してください。

8. 最終画像を書き出します。

   • 手動のブラウザー画面キャプチャではなく、Playwright のスクリーンショットを使用してください。
   • card-01.png のような安定した名前で、カードごとに PNG を1つ書き出してください。
   • 鮮明さを保つため、デフォルトでは2倍のスクリーンショットを書き出してください。1080x1080 のカードは、ユーザーがファイルサイズを小さくするよう明示的に依頼した場合、または --scale 1 を指定した場合を除き、2160x2160 の PNG として書き出してください。
   • 出力パスと、最終的なアスペクト比、枚数、スタイルの簡潔な概要をユーザーに伝えてください。

9. 動画書き出し用の deck.json を作成します（ユーザーが動画／ナレーションを依頼した場合は必須）。

   • すべての HTML カードを確定し、PNG を書き出した後、出力ディレクトリに deck.json を作成してください。
   • このファイルは、次のステップでの TTS ナレーション合成と動画レンダリングに使用します。
   • 形式：

   {
     "meta": {
       "title": "<Series title>",
       "ratio": "<ratio used: 9:16 | 1:1 | 3:4>",
       "language": "<zh | en | ja | ...>"
     },
     "cards": [
       { "file": "card-01.html", "title": "...", "narration": "1-3 sentence spoken caption." },
       { "file": "card-02.html", "title": "...", "narration": "..." }
     ]
   }
   

   • 各フィールドの意味：
     • meta.title — イントロカードのテキストとデフォルトの出力ファイル名に使用されます（スラッグ化：[^a-z0-9一-鿿] → -、小文字化。CJK は保持されます）。
     • meta.language — "zh" の場合にのみ、イントロのサブタイトルが "知识卡片" に切り替わります。それ以外の値（"ja"、"en"、"mixed" を含む）では "Card Series" が使用されます。
     • card.title — card.narration が空の場合、画面上のサブタイトルバーのフォールバックとして使用されます。
     • card.narration — TTS に渡される読み上げ用のキャプションです。デフォルトでは、サブタイトルバーのテキストとしても表示されます。
   • ナレーションのルール：
     • カードのコピーと同じ言語でナレーションを書いてください。
     • 各カードにつき1～3文にしてください。自然な話し言葉のリズムを意識し、リストや箇条書きのような読み上げ方は避けてください。
     • ビジュアルの内容をそのまま言い直すのではなく、背景情報、解釈、または重要なポイントを加えてください。
     • 各カードのナレーションは、画像なしで聞いても理解できる内容にしてください。
   • すべての HTML ファイル内の .card 要素に、透明性を確保するため data-narration="..." も追加してください。
   • ユーザーが画像のみ（動画なし）を明示的に依頼した場合は、この手順を省略してください。

10. 動画をレンダリングします（任意 — ユーザーが動画／ナレーション出力を依頼した場合のみ）。

    • exports/ に PNG があり、deck.json の作成が完了した後に実行します。

    voxflow card render <output-dir>/
    

    • レンダリング後の出力ディレクトリ構造：

      cards/my-topic/
      ├── card-01.html … card-N.html   (ソース HTML)
      ├── deck.json                     (ナレーション＋メタデータ)
      ├── exports/card-01.png …         (PNG エクスポート)
      ├── sources.md                    (出典表記)
      └── my-topic.mp4                  (最終動画 — スラッグは deck.meta.title から生成)
      

    • 音声／TTS：

      • --voice <id> — TTS 音声。音声を確認するには voxflow voices を実行してください。
      • --speed <n> — ナレーション速度 0.5-2.0（デフォルト：1.0）
      • --no-audio — TTS をスキップし、無音動画を生成します（クォータ消費ゼロ）

    • タイミング：

      • --pause <sec> — 各カードのナレーション後に入れる読み取り時間用の無音（デフォルト：2.5）。WAV に組み込まれるため、最終クリップに必ず反映されます。
      • --hold <sec> — --no-audio モードでのカード表示時間（デフォルト：5）

    • 構成：

      • --no-intro / --no-outro — タイトルカード／ブランドカードをスキップします
      • --intro-dur <sec> — イントロカードの表示時間（デフォルト：2.5）
      • --outro-dur <sec> — アウトロカードの表示時間（デフォルト：2）

    • オーバーレイとミックス：

      • --no-subtitle — 下部の字幕バーを無効にします（字幕には libfreetype を含む FFmpeg が必要です。自動検出され、見つからない場合はスキップされます）
      • --bgm <path> — BGM。音量を下げてループ再生します
      • --bgm-volume <n> — BGM の音量 0-1（デフォルト：0.08）

    • 出力：

      • -o <path> / --output <path> — カスタム出力パス（親ディレクトリは自動作成されます）

    • CJK コンテンツ（CLI 1.17.1 以降）：字幕、イントロ、アウトロのオーバーレイでは、meta.title / card.title / card.narration 内の CJK テキストを自動検出し、CJK 対応のシステムフォントファイルを適用します（macOS では PingFang / Hiragino / Heiti、Linux では Noto CJK / WQY、Windows では msyh / SimSun）。プラットフォームに CJK フォントがインストールされていない場合は、VOXFLOW_CJK_FONT=/path/to/font.ttc を設定してフォントを明示的に指定してください。自動検出でも上書き設定でもフォントが見つからない場合、コマンドは警告をログに出力します。□ の豆腐文字を避けるには、代わりに --no-subtitle --no-intro --no-outro を指定してください。

    • デフォルトの出力先：<dir>/<slugified deck.meta.title>.mp4（カードと同じディレクトリ）。meta.title が空の場合は cards.mp4 が使用されます。

    • FFmpeg 以外の外部依存関係はありません（自動検出されます。システムの ffmpeg が見つからない場合は ffmpeg-static npm パッケージにフォールバックします）。

    • 中間ファイル（WAV、クリップ）は <dir>/.card-render-work/ に保存されます。成功時は自動的にクリーンアップされ、失敗時はデバッグ用に保持されます。

    • クォータ：ナレーションを付けるカード 1 枚あたり約 50（tts-synthesize）。--no-audio を指定するとゼロです。5 枚のカードデッキでは合計約 250 クォータを消費します。

    • Slice テーマ（paper-slide、editorial-mag など）を使った記事からカードへの VIDEO には、代わりに voxflow:slice をおすすめします。

アセットと出典の管理

• 生成ファイルは、指定された出力フォルダー内に収めてください。
• ユーザーが別の出力パスを指定していない限り、カードで使用するローカル画像、ロゴ、スクリーンショット、テクスチャ、アイコンなどのアセットは cards/<slug>/assets/ に配置してください。
• 調査資料、外部アセットの出典、重要な事実の参照先は、出力フォルダー内の sources.md または credits.md に記録してください。
• 最終エクスポートでは、外部 URL から直接読み込むアセットに依存しないでください。外部 URL は調査中または一時的なプレビューにのみ使用できます。
• カードセットで実際に使用する最小限のアセットのみをコピーしてください。無関係なアセットフォルダーをまとめてコピーしないでください。
• 生成または再デザインしたカード画像については、sources.md または credits.md にプロンプトの意図、判明している場合はモデル／ツール、およびアセットが合成であるかどうかを記録してください。

レンダリングヘルパー

プロジェクトに同等の Playwright エクスポートスクリプトがない場合は、scripts/render-cards.mjs を使用します。

node /path/to/card/scripts/render-cards.mjs \
  --input ./cards/my-set \
  --output ./cards/my-set/exports \
  --ratio 9:16

ヘルパーは、より鮮明な PNG を出力するため、デフォルトで --scale 2 を使用します。ファイルサイズを輪郭の鮮明さより優先する場合に限り、--scale 1 を使用してください。

スクリプトは次の処理を行います。

• 入力フォルダー内の .html ファイルをスキャンします。
• --ratio または --size に基づいてビューポートを設定します。
• .card がある場合はその要素を、ない場合はビューポートをスクリーンショットにします。
• PNG ファイルを出力フォルダーに書き込みます。
• DOM のオーバーフローと範囲外を示すシグナルを含む audit.json を書き込みます。

対象プロジェクトに Playwright がない場合は、ローカルのパッケージマネージャーでインストールまたは実行し、必要に応じて Chromium をインストールしてください。

npm install -D playwright
npx playwright install chromium

実装ルール

• すべてのカードに共通のトークン、基本レイアウト、文字サイズのスケール、画像の処理を適用し、視覚的に統一感を持たせます。
• デザイン工程（ワークフローのステップ 4）と QA 工程（ワークフローのステップ 7）では、テストやデモも含め、references/taste.md を必ず基準として適用します。短縮経路でも、この 2 回の読み込みは省略しないでください。
• 新しいビジュアルシステムを作り出すより、既存のデザインコンテキストを優先します。
• スタイルが曖昧な場合や、カードセットの影響が大きい場合は、コーディング前にコンセプト案を複数作成します。
• まずテーマトークンを定義します。背景、サーフェスのレベル、境界線のレベル、テキストのレベル、アクセントカラー 3 色、セマンティックカラー、グラデーション、角丸、シャドウ、フォントを含めます。
• コンポーネントの CSS ではトークンを使用します。単発のアセットやデータビジュアライゼーションで本当に必要な場合を除き、トークン定義ブロック以外に色の値を直接散在させないでください。
• デフォルトのカードフォントとして Inter を使用しないでください。references/fonts.md に記載された重み付きランダムアルゴリズム（プリセット × デザイン言語 × コンテンツ言語 → 役割ごとの選択）で具体的なフォントを選びます。ここにフォント一覧を直接記載しないでください。唯一の情報源は references/fonts.md です。すべてのフォントをローカルに埋め込める必要があるため、Avenir Next などの有料フォントやシステムフォントは禁止です。
• 純粋な黒は使わないでください。オフブラック、チャコール、亜鉛のようなダークカラー、またはインクカラーを使用します。
• 外部テーマの CSS をそのまま複製しないでください。必要な配色や動作をローカルのカードスタイルとして再現し、関連する場合はインスピレーションの元を sources.md または credits.md に記載します。
• ユーザーがモノクロのデザインを明示的に求めている場合を除き、単調な配色は避けてください。
• すべてを縮小する前に、文章の編集やグループ化、レイアウトの変更でテキストを収めます。
• すべてのカードを情報量の少ないものにしないでください。実際の解説コンテンツでは、少なくとも 1 枚のカードに構造化された情報（2～4 個の要点、ラベル、観察事項、手順、コールアウト、判断基準など）を含めます。
• あらゆる箇所の文字を小さくして情報量を増やそうとしないでください。まずグループ化、階層、ラベル、補足、チェックリスト、キャプション、対象物に付随するコールアウトで構成を加えます。
• AI が書いたような言い回しは、具体的な表現に置き換えます。原文からの引用でない限り、「可能性を広げる」「シームレス」「解き放つ」「次世代」「スマート化」「再構築」などの、内容の薄い表現は避けてください。
• 架空のデータを作らないでください。出典付きで検証済みの事実、明らかに合成データと分かるデモ用の値、または数値を使わない方法を選びます。
• レスポンシブ CSS は開発プレビューにのみ使用します。エクスポート用のキャンバスは固定したままにします。
• カードの内容にカスタム描画が必要でない限り、canvas よりセマンティック HTML と CSS を優先します。
• アセットと出典表記は出力フォルダー内にまとめます。
• 既存のデザインシステムで大文字の字間を明確に指定している場合を除き、字間は 0 にします。負の字間は使用しないでください。
• 技術的な内容や情報量の多いカードでは、本文にサンセリフ体を使用し、セリフ体やディスプレイ書体は見出し、引用、数値に限定します。エディトリアル／文芸系のプリセット（magazine-eink、field-notes、kraft-editorial）では、references/fonts.md に従い、本文にセリフ体または楷体を使用できます。エディトリアルレイアウトでは、本文の書体にかかわらず、長い中国語のタイトルの改行位置を手動で調整します。
• 画像の多いカードでは、各グループ内で画像の比率またはフレームの高さを統一します。cover を使用する場合は画像の下端から切り取り、図や文字を含むスクリーンショットには contain を使用します。
• ビジュアル検証を省略しないでください。最終回答には、レンダリングとエクスポートが成功したかどうかを明記します。