slidewright

インタラクティブなプレゼンテーションビルダー

ウェブサイトとして動作し、会場のスクリーンに投影するスライドデッキを作成します。デッキはトークの視覚的な部分を担い、話すのはプレゼンターです。作成方法は2通りありますが、デザイン言語は共通です。

まず、基本的な考え方（コードを書く前にお読みください）

1人のオペレーター（プレゼンター）が、1台のマシンを使います。スライドは大きなスクリーンに映し、聴衆は見るだけです。クリック、入力、操作はしません。以下の内容はすべて、この前提に基づいています。避けるべき失敗パターンは4つです。

• テキストが小さすぎる。 スライドはノートパソコンではなく、会場の離れた場所から読まれます。ウェブ閲覧向けのサイズ（text-sm、16px）や固定の Tailwind テキストクラス（text-4xl）は使わないでください。テキストが画面に合わせて拡大縮小するよう、必ず clamp() を使ってください。文字サイズの下限を守ってください（本文は約 30〜36px、1080p のキャンバスでは 28px 未満にしないこと）。references/design-system.md を参照してください。
• コンテンツが端に寄りすぎる。 パディングは2層構造のルールです。スライドのコンテンツはビューポートのセーフエリア内に収め、カード、パネル、コールアウト、枠付きボックスなど、視覚的に区切られたコンテナー内のコンテンツは、そのコンテナーの端から内側に配置してください。親スライドのパディングでは、内側にあるコンテナーは保護されません。また、gap や子要素のマージンは、コンテナー自体のパディングの代わりにはなりません。どちらのスキャフォールドにもセーフエリア用のパディングと、インセット用の .slide-surface ヘルパーが用意されています。fullBleed スライドでも、テキストコンテンツは内側に配置してください。
• アプリを作ってしまう。 入力フィールド、「Submit」、ログイン、データ収集は不要です。バックエンドがなく、データの送信先もありません。インタラクションは、プレゼンターがクリックしてコンテンツを表示したり、次へ進めたりすることだけです。コンポーネントが「このデータはどこに送られるのか」と問いかけるなら、そのコンポーネントは不適切です。
• 聴衆に合わない語り口。 取締役会向けの報告はレッスンではなく、ピッチは進捗報告ではありません。デッキの種類によって構成と語り口が決まります。まず種類を決めてください。references/deck-types.md を参照してください。

プレゼンターはスマートフォンのリモコンを手に持つことがあります（ターミナルから QR コードをスキャンし、「次へ」／「前へ」をタップします）。これは2台目のデバイスを使う同じ1人のオペレーターであり、聴衆による操作ではありません。

references/design-system.md は、このスキルの要となるドキュメントです。文字サイズの下限、2層構造のパディングルール、コンテンツのはみ出し、レイアウトのレシピ、モーション、カラーパレットについて説明しています。スライドのコンテンツをデザインまたはスタイル変更する際は、必ずお読みください。

ワークフロー

1. 講演内容を理解し、明確にします。
   • 内容： プレゼンテーションの内容が曖昧または不明確な場合は、作成を始める前に、トピック、対象者、登壇者（氏名／役職）、主要なメッセージを確認する質問をします。ベトナム語のコンテンツでは、誠実で率直、飾り気のない語り口を標準とし、マーケティング的な誇張は避けます。
   • デッキの種類： 執筆前に、デッキの用途を決めます。上層部への報告、意思決定の依頼、ピッチ、研修、講演、社内向けの最新情報共有のいずれかです。依頼内容から推測し、選んだ種類を一行でユーザーに伝えます。2種類が同じくらい当てはまる場合に限り、質問します。その後、references/deck-types.mdを読み、その種類に適した展開、語り口、禁止事項に従います。
   • スタイル： 希望するビジュアルスタイルをユーザーに尋ね、次のモダンな5つの選択肢を提案します。
     1. ミニマリスト・バウハウス：高いコントラスト、幾何学的なタイポグラフィ、ゆとりのある余白。
     2. ダークモード・シネマティック：濃いスレート色や黒の背景、ドラマチックなコントラスト、光るアクセント。
     3. エディトリアル／マガジン：洗練されたフォントの組み合わせ（セリフ体＋サンセリフ体）、整然としたグリッドレイアウト。
     4. グラスモーフィズム：柔らかな背景グラデーション、ぼかしのある半透明のコンテンツパネル。
     5. ネオ・ブルータリズム：大胆なタイポグラフィ、飾り気のない枠線、硬い影、エネルギッシュな表現。
2. トラックを選びます（下記参照）。判断に迷う場合は一度だけ質問し、それ以外は、小規模／短時間のデッキにはプレーンHTML、大規模で継続的に使う講演にはReactを標準として選びます。
3. 対応するスクリプトでひな形を作成します。ボイラープレートを手作業で組み立てないでください。
4. デッキの種類に適した展開と語り口で、references/design-system.mdに従ってスライドを作成します。1枚につき1つのアイデアに絞り、言葉を少なくし、実際のビジュアルを使い、投影しても読める文字サイズにし、操作は発表者だけが行えるようにします。また、ビューポートとコンテンツコンテナーの両方に適用する2層のパディング仕様に従います。情報量の上限を守り、1枚につき箇条書きは5項目、約60語、表は最大5×4セルを超えないようにします。文字サイズを最小値まで下げても収まらない場合は、スライドを追加して分割します。最小値を下回る縮小や、縦スクロールが発生するスライドの作成は行いません。
5. **必須のUI要素を維持します。**下部に表示されるナビゲーションスライダー（ドット列）とスライド番号を必ず残します。どちらも両方のひな形に含まれています。削除しないでください。
6. ひな形で作成される<deck-name>-notes.mdファイルにスピーカーノートを記述します（スライド自体には記載しないでください）。
7. 検証スクリプトを実行し、文字が小さすぎる問題や情報量が多すぎる問題を検出します。

   bash /mnt/skills/user/slidewright/scripts/verify-slides.sh <path-to-deck>
   

   報告された問題をすべて修正してから次に進みます。
8. 引き渡し前に余白を監査します。1920×1080と、それより小さいビューポート1つで、すべてのスライドを確認します。テキストや主要なコンテンツがビューポートのセーフエリアを越えてはなりません。目に見える境界（background、border、outline、shadow、角丸の面、テキストオーバーレイパネル）を描画するすべての要素について、コンテンツの四辺すべてにパディングがあることを確認します。例外はメディアと、純粋に装飾目的の画面端まで広がるレイヤーのみです。それらの上にテキストを配置する場合は、内側にパディング付きの面を設けます。
9. **スマートフォンのリモコンを使った発表方法をユーザーに伝えます。**どちらのひな形にもリモコン機能が含まれています。HTMLトラックではnode <deck>/slidewright-remote.mjsを実行します。Reactトラックではnpm run devを実行します。ターミナルにスマートフォン用のQRコードが表示されます。references/remote-control.mdを参照してください。ナビゲーションコードを編集する場合は、デッキのwindow.slidewright APIとslidewright:changeイベントを維持してください。
10. 依頼された場合はPDFにエクスポートします。references/export-pdf.mdを参照してください。

デッキごとに専用のフォルダーを作成します。ライブデモ用のアプリは別プロジェクトとし、デッキの中には入れないでください。

トラックの選び方

選択肢	用途	リファレンス
プレーンHTML	セットアップ不要。ファイルを開くだけで実行でき、手早くデッキを作成してどこでも共有できます。ツールチェーンも不要です。情報量の多いスライドが約15～20枚を超えると、扱いにくくなります。	references/html-track.md
Vite + React	スライド数が多い場合、再利用可能なコンポーネント、状態に応じたインタラクション、TypeScript、Framer Motion、継続的に更新・再実行する講演に適しています。	references/react-track.md

どちらのトラックでも、投影時の体験は同じで、同じデザインシステムに従います。異なるのは実装方法だけです。

スキャフォールディング

プレーン HTML — 単一の自己完結型 index.html、CDN 経由の Tailwind、ビルド不要：

bash scripts/new-html-deck.sh <deck-name> [target-dir] [--title "Deck title"]

Vite + React — 公式の Vite ツールでスキャフォールディングし、最新の React、Tailwind、Framer Motion、Lucide をインストールします（バージョンは意図的に固定していないため、各デッキで常に最新のツールを利用できます）。その後、App → Deck → Slide アーキテクチャを追加します：

bash scripts/new-react-deck.sh <deck-name> [target-dir] [--no-install]
cd <deck-name> && npm run dev

どちらのスキャフォールディングにも、スマートフォン用リモート（依存関係ゼロの slidewright-remote.mjs）が含まれます。リモート機能が追加される前にスキャフォールディングしたデッキの場合：

bash scripts/add-remote.sh <path-to-deck>

スキャフォールディング後、該当するトラックのリファレンスを読んでスライドの構成方法や追加・並べ替えの方法を確認してから、コンテンツを作成してください。

このスキルに含まれるファイル

• references/design-system.md — 投影時のルール、タイポグラフィの最低基準、レイアウトのレシピ、モーション、配色。中核となる資料です。コンテンツやデザインに関する作業では必ず参照してください。
• references/deck-types.md — 6 種類のデッキと、それぞれの展開、語り口、禁止事項。スライドのコンテンツを書く前に読んでください。
• references/html-track.md — プレーン HTML デッキの構成、テンプレートの内部仕様、スライドの追加方法。
• references/react-track.md — Vite + React のアーキテクチャ、スライドの順序、Tailwind の設定。
• references/export-pdf.md — PDF のエクスポート方法とスピーカーノートの規約。
• references/remote-control.md — スマートフォン用リモート：起動方法、デッキ API の仕様、セキュリティ、トラブルシューティング（誤った IP、ファイアウォール、会場の Wi-Fi）。
• scripts/new-html-deck.sh — プレーン HTML デッキをスキャフォールディングします。
• scripts/new-react-deck.sh — Vite + React デッキをスキャフォールディングします。
• scripts/add-remote.sh — 既存のデッキにスマートフォン用リモートを追加します。
• assets/remote/slidewright-remote.mjs — スマートフォン用リモート：WebSocket リレー、リモートページ、ターミナル QR コード、静的サーバー（HTML トラック）、Vite プラグイン（React トラック）。スキャフォールディング時に各デッキへコピーされます。コピーではなく、このソースを編集してください。
• scripts/export-deck-pdf.py — デッキをコンテンツをすべて含む PDF にエクスポートします（レンダリングの完了を待ち、非表示のコンテンツを表示します。画像ベースです）。
• scripts/verify-slides.sh — デッキファイルを静的解析します。タイポグラフィの最低基準を下回るテキスト、固定 px のフォントサイズ、過剰な箇条書き、高いスライドあたりの単語密度を検出します。スライドの作成後、引き渡し前に実行してください。