Communitygithub.com

デザインスキル - フロントエンドスライド

スクラッチまたはPowerPointファイルの変換から、アニメーション豊かなHTMLプレゼンテーションを作成します。プレゼンテーションの作成、PPT/PPTXのWeb変換、トークやピッチ用のスライド作成時に使用します。デザイナーでないユーザーが、抽象的な選択ではなく視覚的な探索を通じて自分自身の美的感覚を発見できるように支援します。

デザインスキル - フロントエンドスライド とは?

このスキルは、ブラウザ上で完全に動作する、ゼロ依存・アニメーションリッチなHTMLプレゼンテーションを作成するためのツールです。Claude Code、Codex、CursorなどのAIエージェント上で動作し、ユーザーからの自然言語での指示に基づいてプレゼンテーションの作成、PowerPointファイルの変換、既存のHTMLスライドの強化を行います。特徴は、すべてのスライドが固定の16:9(1920×1080)のキャンバス上に作成されることです。これにより、あらゆる画面サイズでスライドのアスペクト比が維持され、レスポンシブなレイアウト変更による崩れを防ぎます。また、ユーザーに抽象的なデザイン設定を尋ねるのではなく、3つの異なるスタイルプレビューを実際に生成して提示することで、ユーザーは見た目で好みを選ぶことができます。これにより、非デザイナーでも高品質で個性的なプレゼンテーションを簡単に作成できます。さらに、プレゼンテーションの目的(ピッチ、会議、チュートリアルなど)と密度(スピーカー主導型か読書主体型か)に基づいて、適切なコンテンツ量とレイアウトを自動的に調整します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/webiscorp/designskill-open/tree/HEAD/skills/frontend-slides

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

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

フロントエンドスライド

ゼロ依存、アニメーション豊かなHTMLプレゼンテーションを作成。ブラウザ上で完全に動作します。

基本原則

  1. ゼロ依存 — CSS/JSをインライン化した単一HTMLファイル。npm不要、ビルドツール不要。
  2. 見せる、言わない — 抽象的な選択肢ではなく、ビジュアルプレビューを生成。人は見ることで自分が何を望むかを発見します。
  3. 個性的なデザイン — 一般的な「AIスロップ」は禁止。すべてのプレゼンテーションは手作りのように感じられること。
  4. 段階的な開示 — まずは軽量なスタイルインデックスを読み込みます。大胆なテンプレートの場合は、小さなプレビューカードでスタイルをプレビューし、ユーザーがそのテンプレートを選択した後にのみ完全な design.md を読み込みます。
  5. 固定16:9ステージ(譲れない) — すべてのデッキは、ビューポートに合わせて全体がスケーリングされる1920×1080のスライドキャンバスを使用します。スライドは、スマートフォンを含むあらゆる画面で16:9を維持すること。デバイスに合わせてスライドのコンテンツをリフローしないでください。

デザイン美学

あなたは、「配布用」の一般的な出力に収束しがちです。フロントエンドデザインにおいて、これはユーザーが「AIスロップ」と呼ぶ美学を生み出します。これを避けてください。驚きと喜びを与える、創造的で個性的なフロントエンドを作りましょう。

重点的に行うこと:

  • タイポグラフィ: 美しく、ユニークで、興味深いフォントを選びましょう。ArialやInterのような一般的なフォントは避け、代わりにフロントエンドの美学を引き立てる個性的なフォントを選びましょう。
  • カラー&テーマ: 一貫性のある美学を追求しましょう。一貫性のためにCSS変数を使用します。控えめで均等に配分されたパレットよりも、支配的な色と鋭いアクセントカラーの方が効果的です。インスピレーションとして、IDEテーマや文化的な美学を参考にしましょう。
  • モーション: 動きのためにアニメーションとマイクロインタラクションを使用します。HTMLではCSSのみのソリューションを優先し、Reactでは利用可能な場合にMotionライブラリを使用します。インパクトのある瞬間に集中しましょう。段階的な表示(animation-delay)を用いた、よく調整された1回のページロードは、散発的なマイクロインタラクションよりも多くの喜びを生み出します。
  • 背景: 単色にデフォルト設定するのではなく、雰囲気と奥行きを生み出しましょう。CSSグラデーションをレイヤリングしたり、幾何学模様を使用したり、全体的な美学に合った文脈に応じた効果を追加します。

避けるべき一般的なAI生成の美学:

  • 過度に使用されているフォントファミリー(Inter、Roboto、Arial、システムフォント)
  • 決まりきったカラースキーム(特に白背景に紫のグラデーション)
  • 予測可能なレイアウトとコンポーネントパターン
  • 文脈特有の特徴が欠けた既製のデザイン

創造的に解釈し、文脈に合わせて真にデザインされたと思わせるような予想外の選択をしましょう。生成ごとにライトテーマとダークテーマ、異なるフォント、異なる美学を変えてください。それでもあなたは一般的な選択(例えばSpace Grotesk)に収束しがちです。これを避けてください。枠にとらわれずに考えることが重要です!

固定ステージルール

これらの不変条件は、すべてのプレゼンテーションのすべてのスライドに適用されます:

  • すべてのデッキには、ブラウザウィンドウを埋めるビューポートラッパーがあります。
  • すべてのスライドは、固定された1920×1080のステージ内で作成されます。
  • ステージはビューポートに合わせて均一にスケーリングされます。レターボックス/ピラーボックスになる場合があります。コンテンツを再レイアウトしてはいけません。
  • スマートフォン用にスライドコンテンツを再配置するために、レスポンシブブレークポイントを使用しないでください。
  • 1920×1080のデザインサイズで固定の内部スライド測定値を使用します。
  • スライドの可視性は、viewport-base.css の visibility、opacity、pointer-events を使用して .active / .visible で制御する必要があります。スライドの切り替えに display: none / display: block を使用しないでください。後続のレイアウトクラス( .slide-content { display: flex; } など)がこれらをオーバーライドし、すべてのスライドを一度に可視にする可能性があります。
  • clamp() は、ステージ外の非スライドUI、またはフルステージが非現実的な小さなフォールバックプレビューにのみ使用します。
  • prefers-reduced-motion のサポートを含めます。
  • CSS関数を直接否定しないでください(-clamp()、-min()、-max() は黙って無視されます)— 代わりに calc(-1 * clamp(...)) を使用してください。

生成時には、viewport-base.css を読み、その完全な内容をすべてのプレゼンテーションに含めてください。

コンテンツ密度モード

これが主に読むためのデッキか、話すためのデッキかをユーザーに尋ね、その回答に基づいてデザインしてください:

密度モード最適な用途デザインの振る舞い
低密度 / スピーカー主導公開トーク、基調講演形式の共有、ライブ説明スライドあたり1つのアイデア、大きなタイプ、強い視覚的階層、十分な余白、最大1〜3箇条書き、必要に応じてスライドを増やす
高密度 / 読書優先レポート、配布資料、非同期レビュー、詳細な内部ドキュメントより自己完結型のスライド、構造化されたグリッド/テーブル/注釈、読みやすい場合は4〜8箇条書きまたは4〜6カード、タイトでありながらも意図的なスペーシング

基本制限は変わりません。スクロール禁止、オーバーフロー禁止、パネルの重なり禁止、快適な読み取りサイズ未満のテキスト禁止。選択された密度モードをコンテンツが超える場合は、詰め込んで窮屈にするのではなく、より多くのスライドに分割してください。


フェーズ0: モード検出

ユーザーの希望を特定します:

  • モードA: 新規プレゼンテーション — スクラッチから作成。フェーズ1へ進む。
  • モードB: PPT変換 — .pptxファイルを変換。フェーズ4へ進む。
  • モードC: 拡張 — 既存のHTMLプレゼンテーションを改善。内容を読み、理解し、拡張します。以下のモードC変更ルールに従ってください。

モードC: 変更ルール

既存のプレゼンテーションを拡張する場合、固定ステージへの適合が最大のリスクです:

  1. コンテンツを追加する前に: 既存の要素をカウントし、密度制限を確認します。
  2. 画像の追加: 1920×1080のスライドキャンバス内に収めます。スライドにすでに最大コンテンツがある場合は、2つのスライドに分割します。
  3. テキストの追加: スライドあたり最大4〜6箇条書き。制限を超える場合?継続スライドに分割します。
  4. 変更後は毎回確認: スライドステージが16:9であること、テキストがカードから溢れていないこと、パネルが重なっていないこと、スクリーンショットが1280×720および1つの電話ビューポートで正しく見えること。
  5. 事前に再構成: 変更がオーバーフローを引き起こす場合は、自動的にコンテンツを分割し、ユーザーに通知します。尋ねられるのを待たないでください。

既存のスライドに画像を追加する場合: 画像は新しいスライドに移動するか、他のコンテンツを削減してから追加します。既存のコンテンツがすでに1920×1080のスライドステージを埋めているかどうかを確認せずに、画像を追加しないでください。


フェーズ1: コンテンツ発見(新規プレゼンテーション)

すべての質問をまとめて行い、ユーザーが一度にすべてを記入できるようにします。現在の環境がネイティブの構造化質問UIを提供している場合はそれを使用し、そうでなければ明確に番号付けされた選択肢とともに1つの簡潔なメッセージで質問します:

質問1 — 目的(ヘッダー: "目的"): このプレゼンテーションの目的は何ですか? 選択肢: ピッチデッキ / 教育・チュートリアル / カンファレンストーク / 社内プレゼンテーション

質問2 — 長さ(ヘッダー: "長さ"): おおよそのスライド数は? 選択肢: 短い(5-10) / 中程度(10-20) / 長い(20+)

質問3 — コンテンツ(ヘッダー: "コンテンツ"): コンテンツは準備できていますか? 選択肢: すべて準備完了 / 大まかなメモのみ / トピックのみ

質問4 — 密度(ヘッダー: "密度"): デッキの密度はどの程度にすべきですか? 選択肢:

  • "低密度 / スピーカー主導" — 大きなアイデア、少ない言葉、より視覚的な余裕
  • "高密度 / 読書優先" — 非同期読書のためのより自己完結型の詳細

フェーズ1ではインライン編集について質問しないでください。 ユーザーはドラフトを見る前に編集動作を選択する必要はありません。インライン編集はドラフト後の機能です。ユーザーが明示的にロックまたはエクスポート専用ファイルを要求しない限り、デフォルトで含めてください。

ユーザーの密度選択を記憶します。これはスライド数、タイポグラフィスケール、スライドあたりのテキスト量、レイアウト密度、映画的なプレゼンタースライドと自己完結型の読書スライドのどちらを優先するかに影響します。

ユーザーにコンテンツがある場合は、共有を依頼します。

ステップ1.2: 画像評価(画像が提供された場合)

ユーザーが「画像なし」を選択した場合 → フェーズ2にスキップ。

ユーザーが画像フォルダを提供した場合:

  1. スキャン — すべての画像ファイル(.png、.jpg、.svg、.webpなど)をリストアップします。
  2. 各画像を検査 — エージェントの利用可能な画像理解機能を使用します。画像読み取りが利用できない場合は、ファイル名/メタデータを使用し、必要な場合にのみユーザーに確認を求めます。
  3. 評価 — 各画像について: 何が写っているか、使用可能(USABLE)か使用不可能(NOT USABLE)(理由を含む)、それが表す概念、支配的な色。
  4. アウトラインを共同デザイン — 厳選された画像は、テキストとともにスライド構造に情報を提供します。これは「スライドを計画してから画像を追加する」というものではありません。最初から両方を中心にデザインします(例: 3つのスクリーンショット → 3つの機能スライド、1つのロゴ → タイトル/クロージングスライド)。
  5. アウトラインを確認 利用可能な場合は同じ構造化質問メカニズムを使用します。「このスライドアウトラインと画像選択は正しいですか?」 選択肢: 良さそう / 画像を調整 / アウトラインを調整

プレビュー内のロゴ: 使用可能なロゴが特定された場合は、それを(base64として)フェーズ2の各スタイルプレビューに埋め込みます。ユーザーは自社ブランドが3つの異なるスタイルで表現されているのを見ることができます。


フェーズ2: スタイル発見

これが「見せる、言わない」フェーズです。 ほとんどの人はデザインの好みを言葉で表現できません。

ステップ2.0: 3つのスタイルプレビューを直接生成

目的、オーディエンス、ムード、コンテンツ密度に基づいて、タイポグラフィ、カラー、アニメーション、全体的な美学を示す3つの異なる単一スライドHTMLプレビューを生成します。

オプションやプリセットピッカーが必要かどうかをユーザーに尋ねないでください。デフォルトの探索体験は常に視覚的な比較です。

ユーザーがすでに雰囲気を与えている場合はそれを使用します。与えていない場合は、機会、オーディエンス、コンテンツ、重要度から推測します。ユーザーが自分の好みを言葉で表現する必要がなく、視覚的に反応できるように、選択肢は十分に多様に保ちます。

ユーザーが明示的にプリセットまたは大胆なテンプレートを指定した場合は、それを1つの選択肢として尊重し、残りのプレビュースロットをその周りに生成します。

安全なプリセット候補については STYLE_PRESETS.md を読んでください。もし bold-template-pack/selection-index.json が存在する場合は、そのコンパクトなインデックスも読みますが、まだ design.md ファイルは読まないでください。

ムード推奨プリセット
感銘/自信ボールドシグナル、エレクトリックスタジオ、ダークボタニカル
興奮/活力クリエイティブボルテージ、ネオンサイバー、スプリットパステル
冷静/集中ノートブックタブ、ペーパー&インク、スイスモダン
感動/心を動かされるダークボタニカル、ヴィンテージエディトリアル、パステルジオメトリー

プレビューミックスのルール:

  • デフォルトで3つのプレビューを生成: STYLE_PRESETS.md からの安全なプリセット1つ、bold-template-pack/selection-index.json からの大胆なテンプレート少なくとも1つ、ワイルドカード1つ。
  • ワイルドカードは、2つ目の大胆なテンプレート、または自己生成のカスタムデザインのいずれかです。ユーザーの機会、オーディエンス、ムード、コンテンツに対して最も強力で有用なコントラストを生み出す方を選択してください。
  • すべての表現力豊かなオプションをテンプレートライブラリから強制的に取得しないでください。利用可能なテンプレートよりも、よりシャープで具体的なデザインの機会がブリーフにある場合は、ワイルドカードスロットを使用して自由にデザインしてください。
  • 保守的または重要度の高いデッキの場合、安全なプリセットは特に控えめにします。落ち着いた、よりフォーマルな大胆なテンプレートを選択し、ワイルドカードは別の控えめなテンプレートか、装飾的ではなく権威的に感じられるカスタムデザインにします。
  • 表現力豊かなデッキの場合、安全なプリセットは読みやすいフォールバックとして維持し、1つの強い大胆なテンプレートを選択し、ワイルドカードは冒険的で文脈に特化し、他の2つのプレビューとは明らかに異なるものにします。
  • 大胆なテンプレートのマッチが弱いと感じる場合は、テンプレートを強制する代わりに、ワイルドカードをカスタムデザインとして使用するか、別の安全なプリセットにフォールバックします。

カスタムワイルドカードデザインのルール:

  • 上記のデザイン美学セクションに従います。一般的な「AIスロップ」、デフォルトのフォント/カラー/レイアウト選択、白背景に紫グラデーションの決まり文句、既製のダッシュボード/カードの外観は禁止です。
  • ユーザーの指定された機会、オーディエンス、ムード/雰囲気、コンテンツ密度に一致させます。カスタムデザインは、単に「スタイリッシュ」であるだけでなく、このデッキのために作成されたと感じられるべきです。
  • 意図的なビジュアルテーゼを作成します。個性的なタイポグラフィ、確固たるパレット、認識可能なレイアウトシステム、そして1つの強い雰囲気またはグラフィックデバイス。
  • フルデッキで実現可能であることを確認します。プレビューは、セクション、コンテンツ、引用、比較、クロージングスライドに拡張できるデザインシステムを示唆している必要があります。
  • 固定の1920×1080ステージルールを使用し、他のすべてのオプションと同じプレビュー信頼性チェックに合格します。
  • スライド自体に「カスタム」「ワイルドカード」「AI生成」またはデザインプロセスのラベルを決してレンダリングしないでください。

大胆なテンプレート選択ルール:

  • ユーザーの目的とムードを、mood、tone、best_for、avoid_for、formality、density、scheme に対してマッチングします。
  • best_for の例は、厳格な業界フィルターではなく、ソフトシグナルとして扱います。
  • 3つのプレビューが互いに真に異なるように保ちます。
  • 大胆なテンプレート候補を選択した後、選択インデックスの preview_md パスから、それらの候補の preview.md ファイルのみを読みます。
  • preview.md はタイトルスライドのプレビューのみに使用します。ユーザーが最終テンプレートを選択するまで、完全な design.md ファイルは読まないでください。
  • 選択された最終 design.md に重要な実装の詳細がない場合を除き、template.html を読んだりコピーしたりしないでください。

プレビュー信頼性ルール(譲れない):

  • すべてのスタイルプレビューは、診断カードではなく、ユーザーのデッキの実際の最初のスライドのように見える必要があります。
  • スライド上に内部ワークフローテキストを決してレンダリングしないでください。preview、generated from、preview.md、template、preset、style option、Option A/B/C、ファイル名、パス、ソースドキュメントラベルなど。
  • スライド自体にテンプレート名やスラッグ名を決してレンダリングしないでください。テンプレート/スタイル名はユーザーへのメッセージにのみ属します。
  • ユーザーがその正確なフレーズをデッキに表示することを明示的に望まない限り、「シャープで挑発的」、「安全なオプション」、「大胆なオプション」、「社内共有用」、または「オーディエンス: ...」などのユーザー要件メモをスライドコンテンツとしてレンダリングしないでください。
  • スライドに装飾が必要な場合は、実際のデッキ装飾のみを使用します。デッキタイトル、セクションタイトル、日付、作成者、会社、ページ番号、またはユーザーの資料からの実際のコンテンツフレーズ。
  • プレビューを開く前に、表示されているテキストを検査し、内部メタデータが表示されている場合は修正します。

プレビューを .frontend-slides/slide-previews/(style-a.html、style-b.html、style-c.html)に保存します。各プレビューは[truncated]

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル