VoxFlow 卡片技能

VoxFlow スキル — カード

テキストの一部を、特徴的で一貫性のあるビジュアルカード画像のセットに変換します。各カードは独自のウェブページであり、すべてのカードが1つのサイズとスタイルシステムを共有します。Playwright でレンダリングし、PNG としてエクスポートします。

これは静的カード画像スキルです。他の用途には以下を切り替えてください:

• 記事 → 縦長カード動画 (スライス) — 1080×1920 リール, 13 テーマ → voxflow:slice
• ショート動画 / AI クリップ / ナレッジカード動画 → voxflow:video
• 複数話者ポッドキャスト → voxflow:podcast
• TTS / 音声 / インストール / 認証 / クォータ → voxflow:hub

ステップ 0 · サインインゲート (必須、最初に行うこと)

このスキルは VoxFlow の一部であり、サインインアカウントが必要です。何よりも先に — 質問、調査、デザインの前に — ログインを確認してください:

voxflow status

• アカウントと残りクォータが表示される → サインイン済み。ワークフローを続行します。
• エラーになる / 「ログインしていません」と表示される → 停止。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）。明示的な検証の次元として。
• 他のステップ（パラメータ収集、調査、コピー計画）では references/taste.md を再ロードする必要はありません。制約は、すでに選択されたプリセットと言語を通じてそれらに流れ込みます。
• 中核的な目標は、明らかな AI 生成デザインの痕跡を取り除くことです。
• ハードな制約には以下が含まれます: デフォルトの Inter フォント不使用、純粋な黒不使用、デフォルトの中央寄せヒーロー不使用、3枚均等カード構成不使用、一般的な AI 生成コピーボイス不使用、偽のデータ不使用。
• 味わいとは空っぽを意味しません。references/taste.md の密度ルールを使用して、実際のカードセットには、ユーザーが明示的にポスターのみやシネマティックのみを要求しない限り、少なくとも1枚の有用な情報カードを含めます。
• テーマプリセットまたはデザイン言語が references/taste.md と競合する場合、ユーザーが禁止されたスタイルを明示的に要求しない限り、味わいのベースラインが優先されます。

入力

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

• content: ソーステキスト、アウトライン、メモ、URL、トピック、またはブリーフ。
• ratio: デフォルトは 1:1。ユーザーが 3:4、9:16、または他の比率を要求した場合を除く。
• count: コンテンツの密度に基づく自動カウントがデフォルト。明示的な数量も受け入れます。
• style: 明示的なスタイル指示、ブランド制約、オーディエンス、ムード、プラットフォームを受け入れます。
• content-language: zh / en / mixed。ソースから推測します。曖昧でフォント選択に影響する場合のみ質問します。references/fonts.md の言語オーバーライドを駆動します。
• output: ユーザーが指定しない限り、cards/<slug>/ などの明確なローカルフォルダを選択します。

重要な事実が最新または議論の余地がある可能性がある場合は、計画する前に検索または確認を行います。調査がコンテンツに影響を与える場合は、ソースの帰属をユーザーが利用できるようにしておきます。これが簡単な確認ではなく、完全な深層調査パスになる場合については、「調査と事実確認」セクションを参照してください。

調査と事実確認

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

• 以下の場合に深層調査をトリガーします: content がトピックフレーズ、単一の文のブリーフ、本文がまだ読まれていない URL、ツイート長のアイデア、質問、または「X を説明する / X をカバーする / X に関するカードを作る」というリクエストである場合。
• 以下の場合に深層調査をスキップします: content がすでに自己完結型の記事、トランスクリプト、構造化されたメモのセット、完全に草稿されたアウトライン、またはユーザーが明らかにについてではなくからカードを構築したいテキストである場合。
• トリガーされた場合、視覚的な計画の前に事実のアウトラインを作成します:
  • 中核となる主張またはテーゼ。
  • 具体的な数字、名前、日付、またはメカニズムを含む3～7の裏付けポイント。
  • 重要性のない各事実のソース。sources.md に記載される URL またはドキュメント参照を含む。
  • ユーザーが解決すべき未解決の質問や議論の余地のあるポイント。
• 事実のアウトラインをユーザーに提示し、テーマ/デザイン言語の選択に進む前に確認、追加、または修正を求めます。これは後のコンセプト/ビジュアル確認とは別の確認です。
• このステップの出力は「骨格」— 主張と証拠 — であり、完成したカードコピーではありません。カードレベルのフック、説明、要点は、後のコンテンツ構造化（ステップ5）で、確認された骨格の上に書かれます。
• ここで収集されたソースは、事実のアウトラインが確認されたらすぐに、出力フォルダ内の sources.md に記録します。

トリガー例

以下の場合に深層調査を実行:

• 「MCP プロトコルについてのカードセットを作って」— 裸のトピック、本文なし。
• 「この記事をカードにして：https://example.com/post」— この会話で内容がまだ読まれていない URL。
• 「RAG 最適化テクニックについてのカードセットが欲しい。チャンキングに焦点を当てて」— トピック + 角度、具体的なポイントやデータなし。
• 「Cloudflare Durable Objects はどんなシナリオに適している？カードを数枚作って」— 質問または「X を説明する / X をカバーする」という枠組み。
• 件名を挙げているが証拠を提供していない単一のツイート、見出し、または1行のブリーフ。

以下の場合に深層調査をスキップ:

• ユーザーが完全な記事、ブログ投稿、トランスクリプト、またはインタビュー本文（約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、またはソース資料がない。
• ソースの意図が曖昧で、間違った選択が作業を無駄にする可能性がある（例: 「このテキストをそのまま使う」 vs 「このトピックを調査して拡張する」）。
• 要求された比率/プラットフォームが矛盾しているか、単一のエクスポートで満たすことが不可能である。
• ビジュアルの方向性が、欠落しているブランド、法的、アクセシビリティ、または正確なコピーの制約によって支配されている。
• 調査により、中核となる主張を変える可能性のある議論の余地のある事実が見つかった。

それ以外の場合は、意味のある生成パラメータについて一度確認を求め、その後、文書化された仮定を 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-po...

... [翻訳のため一部省略]