create-slide

open-slide でスライドを作成する

このスキルは、新しいデッキを作成するワークフローを担当します。技術的なリファレンス（ファイルの仕様、1920×1080 のキャンバス、文字サイズ、配色、レイアウト、アセット）は slide-authoring スキルにあります。ページの構成方法が必要になったら、そのスキルを参照してください。このスキルでは、コードを書く前に参照することを前提としています。

ファイルは slides/<id>/ の下にのみ作成してください。package.json、open-slide.config.ts、既存のスライドは変更しないでください。

ステップ 1 — テーマを選ぶ

themes/ のファイルを一覧表示します。テーマの Markdown ファイル（README.md 以外）がある場合は、それぞれのテーマ ID と、最後に 「テーマなし — ゼロからデザインする」 を選択肢として AskUserQuestion を呼び出します。（AskUserQuestion の選択肢は最大 4 つです。テーマが 4 つ以上ある場合は、トピックに最も関連性の高い 3 つと「テーマなし」を提示します。自動追加される「その他」で、提示されなかったテーマをユーザーが指定できます。）

• ユーザーがテーマを選んだ場合：themes/<id>.md を最初から最後まで読みます。テーマの配色、タイポグラフィ、レイアウト、Title/Footer コンポーネントが正式な仕様となるため、スライドにそのまま反映してください。テーマに Web フォントのインポートが記載されている場合は、slide-authoring の references/webfonts.md に従って読み込んでください（モジュールレベルでスライドごとに注入）。スライドが気付かないうちにシステムフォントへフォールバックしないようにしてください。また、index.tsx の meta エクスポートに theme: '<theme-id>' を設定してください（例：export const meta: SlideMeta = { title: '…', createdAt: '…', theme: '<theme-id>' };。createdAt は slide-authoring のファイル仕様に従います）。これにより、スライドからテーマへのリンク（スライドカードのチップと /themes/<id> の一覧）が設定されます。ステップ 2 では、テーマによって方向性がすでに決まっているため、美的な方向性についての質問は省略します。トピック自体は確認が必要なので、先に確認してください。ページ数とテキストの密度はテーマとは独立しているため、通常どおり質問してください。モーションについては、テーマの「Motion」セクションで方針が定められている場合、その方針を「（推奨）」の選択肢として提示し、すぐに貼り付けて使えるテーマのキーフレームを再利用してください。ユーザーは引き続き変更できます。
• ユーザーが「テーマなし」を選んだ場合、または themes/ にテーマの Markdown ファイルがない場合：変更せずにステップ 2 に進みます。

テーマを選んだために美的な方向性に関する質問を省略した場合は、スライドの作成を始める前に、ステップ 2 でテーマ名をもう一度伝えて、ユーザーが変更できるようにしてください。

ステップ 2 — 要件を明確にする（コードを書く前に必ず質問する）

コードを書く前に、以下の4つの重要なスタイル上の決定事項について、AskUserQuestion を使って確認してください。 これらは、その後のすべての選択（レイアウト、文字サイズ、アセットの要否、モーションコード）に影響するため、最初に決めておくことで手戻りを防げます。すでに明確に回答されている場合に限り、質問を省略してください。回答済みとは、ユーザーの最初のメッセージ、またはステップ 1 で選択されたテーマによって、明確に示されている場合を指します（テーマが決めるのは美的な方向性なので、残りの3項目だけ質問します）。質問を省略する場合は、前提を言い直し、ユーザーが訂正できるようにしてください。

まずトピックを確認します。 意味のある美的提案には、デッキのテーマを知る必要があります。ユーザーの最初の依頼が簡素（「デッキを作って」「スライドを何枚か作って」など）な場合は、まず別の AskUserQuestion 呼び出しでトピック、対象者、草案のアウトラインがあればその内容を確認してください。ユーザーのメッセージですでにトピックが明らかな場合に限り、この確認を省略できます。その場合は、次の呼び出しでトピックについての理解を言い直し、ユーザーが方向性を修正できるようにしてください。

次に、以下の4項目を1回の AskUserQuestion 呼び出し（複数質問形式）で尋ねます。

1. 美的な方向性 — このトピックに合わせて、ビジュアルの方向性を3つ提案します。固定のプリセット一覧から選んではいけません。各選択肢には、雰囲気を表す言葉と具体的なビジュアル要素（配色、タイポグラフィ、モチーフなど）を組み合わせ、ユーザーがイメージできるようにしてください。「ミニマル」「コーポレート」のような曖昧なラベルだけでは不十分です。3つの選択肢は、それぞれ明確に異なるものにしてください。同じアイデアのバリエーションを3つ並べてはいけません。

   トピックに合わせた選択肢の例：

   • 「バックエンドエンジニア向け Rust 入門」 → ラスティックオレンジのテクニカルエディトリアル（温かみのある錆色とチャコール、モノスペースの見出し、コードグリッドのレイアウト） · ブループリント風の開発ドキュメント（黒に近い背景にシアンのグリッド、モノスペース書体、設計図のような雰囲気） · ブルータリストなターミナル（黒地にライムグリーン、ASCII の罫線、飾り気のないデザイン）
   • 「関係者向け Q2 製品ロードマップ」 → 落ち着いたクリーンなコーポレートデザイン（オフホワイト、アクセントカラーは1色、ゆとりある余白） · 自信に満ちたエディトリアルデザイン（大きなディスプレイセリフ体、緻密なグリッド、力強いアクセントカラーを1色） · データ重視のダッシュボード（チャートを主役に、落ち着いたニュートラルカラーとステータスカラー）
   • 「幼稚園の保護者会」 → クレヨンのような遊び心（紙の質感、手描きのアクセント、原色） · 柔らかなパステル調の絵本風（ピーチとミント、丸みのある書体、イラストアイコン） · 写真を主役にした温かみのあるデザイン（子どもの写真を全面に使い、シンプルなキャプションを添える）

   トピックと対象者に最も合う選択肢には「(Recommended)」を付け、ユーザーが選びやすいようにしてください。AskUserQuestion が自動で「Other」を追加するため、汎用的な選択肢を自分で追加してはいけません。

2. ページ数 — おおよその長さです。範囲を提示します：3～5（短め）、6～10（標準）、11～20（詳細）。カスタムのページ数には、自動で追加される「Other」を使います。

3. ページごとのテキスト量 — 各ページにどれくらいの文章を載せるか確認します。次の選択肢を提示してください：最小限（1行または大きな数字）、少なめ（見出し＋箇条書き2～3項目）、標準（見出し＋箇条書き4～5項目、または短い段落）、多め（複数列または詳細な内容）。この選択は、文字サイズとレイアウトに直接影響します。

4. モーション — CSS／React のアニメーションやトランジションを使うか、完全に静的なデッキにするかを確認します。次の選択肢を提示してください：静的（モーションなし）、控えめ（フェード／登場時のみ）、リッチ（キーフレーム、段階的な表示、ループするビジュアル）。アニメーションを使う場合は、まずフレームワークのプリミティブを使って計画してください。段階的な表示には <Steps>／<Step>、ページ切り替えには SlideTransition、共有要素の連続性にはモーフを使います（slide-authoring を参照）。ページ内のモーションには、追加ライブラリを使わず、CSS の @keyframes／インラインの style と useEffect を使ってください。

この4項目を確認した後、まだ不明な点がある場合に限り、ブランドカラーや必要なアセットについて追加質問してください。すでに回答済みのことを聞いて、会話を長引かせないでください。

ステップ 3 — スライド ID を決める

短く、内容がわかりやすい kebab-case を使います。例：rust-intro、q2-roadmap、team-offsite-2026。重複を避けるため、slides/ を確認してください。

Step 4 — 構成を計画する

コードを書く前に、ページの役割をリストにしてスライドの構成を大まかに決めます。よくあるページの種類は次のとおりです。

役割	目的
表紙	タイトル＋サブタイトル、印象的なビジュアル
アジェンダ	これから扱う内容（3～5項目）
セクション区切り	章の間に置く大きなラベル
コンテンツ	見出し＋箇条書き2～5項目、または見出し＋ビジュアル1点
大きな数字	キャンバスいっぱいの大きさで見せる統計データ
引用	出典付きの引用文
比較	2列での変更前／変更後、またはA対B
クロージング	CTA、お礼、連絡先

目安：1ページにつき1つのアイデアにします。2つ入れたくなったら、ページを分けてください。

スライドのテーマに、ユーザーから提供してもらう必要がある特定の実画像（製品のスクリーンショット、チーム写真、顧客ダッシュボードなど）が自然に含まれる場合は、それらを配置する場所を計画し、@open-slide/core の <ImagePlaceholder> を使います。詳しくは slide-authoring の 画像プレースホルダー セクションを参照してください。デフォルトではプレースホルダーを使いません。実画像が本当に必要な場合にのみ挿入してください。

Step 5 — ビジュアルの方向性を決める

一貫性のある配色／文字サイズのスケール／美的スタイルを1つ選び、すべてのページで統一します。制約（配色の構成、文字サイズのスケール、パディング、美的スタイルの選択肢）は slide-authoring に記載されています。そちらに従ってください。

**デフォルト：**選んだ配色／文字サイズのスケールを使って、index.tsx の先頭（インポートの後）にトップレベルの export const design: DesignSystem = { … } を宣言し、インラインスタイルから var(--osd-X) で値を参照します。これにより、生成後にデザインパネルからスライドを調整できます。これは、ほとんどのユーザーが希望する方法です。配色を意図的に固定し、テーマ変更を想定しない単発のスライドに限り、design 定数を省略し、代わりにローカルの palette 定数パターンを使ってください。形式と使用可能なトークンについては、slide-authoring の「デザインシステム」セクションを参照してください。

frontend-design スキルが利用できる場合、ユーザーが大胆なデザインを求めているときは、より踏み込んだ美的指針を得るために参照してください。

Step 6 — slides/<id>/index.tsx を作成する

作成前に slide-authoring スキルを読んでください。ファイルの仕様、キャンバスのルール、文字サイズのスケール、間隔、アセットのインポートについて説明されており、コピーして使えるスターターテンプレートも含まれています。ここで同じ内容を重複して説明せず、スキルを参照してください。

ユーザーがスピーチ原稿／スピーカーノートを依頼した場合（最初の依頼時でも、その後のどの時点でも）、スライドの export const notes 配列に記述してください。これはフレームワークに組み込まれたスピーカーノート機能で、プレゼンタービューに表示されます。仕様については slide-authoring の スピーカーノート を参照してください。原稿を Markdown ファイルやテキストファイルとして渡してはいけません。

Step 7 — 自己レビューする

slide-authoring のチェックリスト（「完了前の自己レビュー」）を実行してください。構造の正しさ、レイアウトの規律、アセットの存在を確認できます。

開発サーバーがすでに起動している場合は、プレビューのルートから各ページのスクリーンショットを撮り、表示に問題があれば修正してください。詳しくは slide-authoring の ページを視覚的にプレビューする を参照してください。

Step 8 — ユーザーに引き継ぐ

ユーザーに次の内容を伝えてください。

• 作成したスライドのIDとファイルパス。
• 開発サーバーはホットリロードするため、http://localhost:5173/s/<id> を開くか、ホームページを更新すればよいこと。
• スピーカーノートを作成した場合：スライドの notes エクスポートに記述されており、ビューアーのノートドロワーとプレゼンターモードのプレゼンタービューに表示されること。
• 開発サーバーが起動していない場合：プロジェクトのルートから、プロジェクトのパッケージマネージャーで dev スクリプトを実行すること（npm run dev、pnpm dev など。ロックファイルに合わせてください）。

ユーザーから依頼されない限り、自分で開発サーバーを起動しないでください。