Slide Forge — 骨子からスライドを鍛造する

骨子（アウトライン）やリサーチ結果を、そのまま投影・共有できる自己完結HTMLスライドに変換するスキル。スライド1枚ごとにデザインを考えるのではなく、共通テンプレートに中身を流し込むことで、全体の体裁を自動的に揃えるのがポイント。

概要

• 出力形式は既定で 自己完結HTML（16:9、1280×720）。外部CDN（インターネット上の別サーバーから読み込むJS/CSSライブラリ）・外部画像・外部フォントに依存しない＝ネット接続が無い環境でもファイルを開けば表示できる状態にする
• 1スライド＝1メッセージを徹底し、詰め込みすぎを防ぐ
• 全ページ共通のヘッダー（章ラベル＋タイトル）／フッター（プロジェクト名・ページ番号）を最初に定義してから中身を流し込む

スキル名について

このスキルは特定プロジェクト専用ではなく、汎用スキルとして命名している。同名の slide-forge スキルが環境に既に別定義で存在する場合は、導入時にその有無を確認し、無ければそのまま追加し、有る場合は本SKILL.mdの内容を正として上書き・統合する（重複登録によるトリガー先の不定化を避けるため）。

なお、本リポジトリのコース lesson03「module29-slide-forge」で扱う slide-forge は、外部OSS github.com/minicoohei/slide-forge（編集可能PPTX等を生成するPython CLI）を指す別物である。本スキルは骨子から自己完結HTMLを素早く作る軽量版で、/slide-forge と打つと本スキルが起動する（レッスンのPython CLIではない）。編集可能PPTXや多形式が必要な場合はレッスンの手順を使うこと。

ユースケース

このスキルが効く具体的なシーン:

1. リサーチ結果 → 提案デッキ: 調査・分析の結果（出典付きの事実・数値）を、意思決定者向けの提案スライドに整形したいとき
2. 骨子 → 投影用HTML: すでにアウトライン（章立て・キーメッセージ）ができていて、それを見た目の揃ったスライドに落とし込みたいとき
3. 既存メモ・ドキュメントの体裁統一: バラバラな見た目のメモや箇条書きを、統一されたテンプレートのスライドとして整理し直したいとき
4. 多言語版スライドの量産: 同じ骨子・同じテンプレートで、言語違いのスライドセットを複数作りたいとき
5. 社内向けの軽量デッキ: PowerPointを開かずに、その場ですぐ見せられる形のスライドが欲しいとき
6. 写真・グラフ画像を含む提案デッキ: プロダクト写真やグラフ画像を貼りたいとき（画像はbase64データURIとしてHTMLに埋め込み、外部参照は作らない）

使わない方がよいケース（スコープ外）:

• 緻密なアニメーション・画面切り替え効果が必要なPPTX（→ 明示要求があれば別途PPTX変換を検討。既定はHTML）
• 1枚だけの単発の図解・インフォグラフィック（→ diagram-generator スキルの方が適している）
• 既存のPowerPoint／Google Slidesテンプレートをそのまま直接編集したい場合
• 大量データを扱うインタラクティブなダッシュボードやフィルタ付きレポート（→ interactive-dashboard-builder スキルの方が適している）
• 出典のある事実・数値がまだ揃っていない段階（→ 環境に ycp-research-factcheck 等のファクトチェックスキルがあれば先にそれでリサーチ・ファクトチェックを済ませてから使う。無ければ自前で出典を確認してから使う）
• 大量スライド（目安50枚超）や複数セクションに跨る長尺デッキ（→ 1ファイルが肥大化し保守困難になるため、章単位でファイルを分割するか、枚数を絞ってから使う）

Workflow

1. インプットと保存先の慣例を確認する まず案件名・プロジェクト名（ファイル名に使う）をユーザーに確認する。骨子ファイル（プロジェクトの慣例に従う。例: outline/proposal.md）があればそれを使う。無ければその場でヒアリングするか、環境に ycp-proposal-outline 等の骨子作成スキルがあればそれで先に骨子を作ってから進める。数値・事実を使う場合は、出典付きのリサーチ結果（プロジェクトの慣例に従う。例: research/<テーマ>/findings.md）を参照する。保存先の慣例が無いプロジェクトでは、ステップ4で使う出力先をここでユーザーに確認しておく
2. 共通テンプレートを定義する（1ファイル内のCSSで完結させる）
   • 16:9（1280×720）固定・1セクション＝1スライド
   • 全枚共通: 上部ヘッダー（章ラベル＋タイトル）／下部フッター（プロジェクト名・ページ番号）
   • 配色は2色＋グレー階調まで。特に指定が無い場合の既定はネイビー（#1F3A5F）をメインカラー、オレンジ（#E8833A）をアクセントカラーとし、本文はグレー（#333333/#666666）を使う。プロジェクトのブランドカラーが分かっている場合はそちらを優先する
   • フォントはシステムフォント（外部フォント読み込み禁止）。本文フォントサイズは18px以上を既定とする
   • 数値・事実を引用したスライドには、該当箇所の下に出典（媒体名・年月、または脚注番号）を8px前後の小さめの文字で明記する
   • 画像を使う場合はbase64データURIとしてHTML内に埋め込む（外部ファイル参照・外部URLは禁止）。埋め込みでファイルが極端に肥大化する場合は圧縮してから埋め込む
3. 1枚＝1メッセージで組む
   • タイトル行＝キーメッセージ（断定形の1行）。「〜について」のような説明的な見出しは禁止
     • 悪い例: 「市場動向について」
     • 良い例: 「国内市場は今後3年で1.5倍に拡大する」
   • ボディは箇条書き最大4個（1項目は日本語で全角40字以内を目安とする）、または図解1つまで。詰め込まない
   • 図解が必要な枚は中央に図解エリアを確保する（プレースホルダ可。後から画像を差し込める構造にし、alt代替テキストを設定しておく）
4. 出力する プロジェクトの慣例（無ければ output/slides/<プロジェクト名・テーマ名>.html）に自己完結HTML（外部CDN・外部画像・外部フォントに依存しない）で保存する。ブラウザで開けばそのまま投影できる形にする。多言語版を作る場合は、既定言語版を完成・レビューまで終えてから、言語ごとに <同名>_<言語コード>.html（例: _ja.html / _en.html）として保存し、テンプレート（配色・レイアウト）は共通のまま文言だけを差し替える。文字量は言語によって増減するため、ボディの文字数上限を言語ごとに再確認し、はみ出しがあれば文言を調整する（レイアウト自体は変更しない）
5. セルフレビューする 保存したHTMLファイルをダブルクリックして既定のブラウザで開き、実際に1枚ずつ表示を確認しながら、下記「チェック項目」に沿って提出前に必ず確認する

チェック項目（提出前）

• 1枚1メッセージになっているか（1枚に2つ以上の主張が混在していないか）
• タイトルだけを拾い読みして、全体のストーリーが通るか（確認方法: 全スライドのタイトル行だけを上から順に声に出して読み、話が急に飛んだり同じ話が繰り返されたりしていないか確認する）
• 全枚でヘッダー・フッター・余白・配色が統一されているか
• 出典のある数値・事実だけを使い、かつスライド上に出典表記（脚注またはフッター）があるか
• 自己完結HTMLになっているか（外部CDN・外部画像・外部フォントへの参照が残っていないか）
• **16:9（1280×720）**で崩れずに表示されるか（文字あふれ・要素のはみ出しがないか）
• 本文フォントサイズが投影距離で読める大きさか（目安: 本文18px以上、箇条書き1項目は日本語で全角40字以内）
• 背景色と文字色のコントラストが十分か（薄いグレー文字を薄い背景に置いていないか）
• 色だけで意味を区別していないか（例: 赤=NG／緑=OKを色以外の記号・ラベルでも示しているか）
• 図解プレースホルダ・画像にalt代替テキストが設定されているか
• 保存先・ファイル名がプロジェクトの慣例（無ければ output/slides/<名称>.html）に沿っているか
• 誤字脱字、数字の桁・単位（円／ドル、％等）に誤りがないか
• 多言語版を作る場合、言語ごとに文字がはみ出したり、改行位置がおかしくなったり、フォントが崩れたりしていないか

注意

• 保存先は必ず output/slides/ 配下に固定する。ファイル名は英数・ハイフン・アンダースコアのみに正規化し、..・先頭スラッシュ・制御文字を含む入力は拒否する（意図しない場所への書き込みを防ぐため）。

• PPTXでの出力は明示的に要求された場合のみ検討する（既定はHTML）

• 数値・事実は出典付きのリサーチ結果にあるものだけを使う。出典の無い数字を飾りで入れない

• 骨子や出典データが無い状態でスライド化を始めない。先にインプットを揃える（Workflowのステップ1を飛ばさない）