資料作成キット — スライド

16:9 の HTML スライドを、選んだテーマに完全準拠して生成する。 構成設計・HTML 生成・機械検査・視覚検証・部分編集・PDF 化までをカバーする。

このスキルは雛形を配らない。 固定するのはトークン・部品・原則だけで、 ページの骨格は毎回、内容から設計する（core/structure.md §1）。

---

1. モード判定

ユーザー入力を上から順に判定する。

モード	判定基準	読むワークフロー
to-pdf	slides/*.html が既存 ＋「PDF にして」「PDF 化」	workflows/to-pdf.md
edit	slides/*.html が既存 ＋ 修正指示（「N 枚目」「変えて」「直して」）	workflows/edit.md
quick	確定したアウトラインが提供済み、または「すぐ作って」「構成は決まってる」	workflows/quick.md
full	それ以外（議事録・メモ・断片・テーマだけ）	workflows/full.md

---

2. スタイル・用途・テーマを 1 回で確認する

最初に必ず 1 回、選択式で確認する（ユーザー指定 2026-08-07: 入力から推定できる場合でも省略しない）。それ以外は聞かずに進む。

AskUserQuestion ツールが使える環境では、必ずそれで確認する（テキストで聞かない）。1 回の呼び出しに次の 3 問をまとめる:

1. スタイル（3 択）: スタンダード（整理型・迷ったらこれ） / ビジュアル（図解多め・カジュアル） / フォーマル（端正な法人提案）
2. 用途（2 択）: 社内向け資料 / 提案資料
3. テーマ（選択肢は 4 つまで）: 入力・スタイルに合う 4 テーマを説明付きで提示し、残る 1 つは選択肢の description で触れる（Other で指定可能）。 A 紺（金融・行政・大企業への提案） / B テラコッタ（一般的な BtoB・迷ったらこれ） / C ティール（スタートアップ・登壇） / D 緑＋黄（教材・勉強会・社内共有） / E 朱（登壇・SNS・軽さ重視）

入力から推定できる場合は、聞かずに進むのではなく、その推定を各問の先頭の選択肢にして「（推奨）」を付ける （例:「クライアントへの提案書」→ スタイル先頭 = フォーマル（推奨）・用途先頭 = 提案資料（推奨））。

AskUserQuestion ツールが無い環境では、同じ 3 問をテキストで 1 回にまとめて聞く。 確認せずに進んでよいのは、ユーザーが「聞かずに作って」と明示した場合と、明らかにバッチ的な入力の場合だけ（§2-1 の例外の例外と同じ）。

このスキル内の他の確認（§2-1 の材料確認・edit モードの対象ファイル選択・用途の確認など）も、 選択肢が切れる質問は AskUserQuestion で行う。自由記述で聞くのは選択肢を作れない質問だけ。

スタイルの判定ヒント: 提案書・決裁・行政 → formal ／ 勉強会・教材・SNS・「図解多め」 → visual ／ それ以外 → standard。 ビジュアル度（high/mid/low）はスタイルの既定に従い、ユーザーが「図解多め/控えめ」と言ったときだけ上書きする。 ビジュアル度の共通定義: high = 全枚モチーフ駆動 ／ mid = キー枚（表紙・結論・比較・まとめ）のみモチーフ化 ／ low = 要所 1〜2 枚だけ図解。スタイル既定と異なる指定（例: formal + high）ではこの定義を優先する。

2-1. 例外 — 材料が足りないとき

必須ブロックの過半が TODO になりそうなら（例:「新規事業の提案書作って」の一行だけ）、 材料をもう 1 問だけ聞いて、答えを待つ。

提案書の骨格を作れますが、いまの情報だと 4 枚中 3 枚が「記入してください」の枠になります。 何についての提案か、相手が今どう困っているかだけ教えてください。

例外の例外: 明らかにバッチ的な入力・「聞かずに作って」と指示された場合のみ、 「N 枚が TODO になります」と宣言して進む。

---

3. テーマ

themes/ の 5 つ。色・書体・角丸・面ルール・見出しサイズはテーマ定義が正本。

	名称	地 / アクセント	想定
A	白 × 紺	#ffffff / #3d5dc6	金融・行政・大企業への提案。硬めの業務資料
B	クリーム × テラコッタ	#faf9f5 / #d97757	一般的な BtoB 提案。迷ったらこれ
C	寒色グレー × ティール	#F0F4F4 / #0D9488	スタートアップ・登壇・SNS 共有前提
D	クラフト × 緑＋黄	#F6F3EA / #1E8A3C	教材・勉強会・社内共有。黄を差せる唯一のテーマ
E	生成り × 朱	#FAF4EF / #EE5D43	登壇・SNS・軽さ重視。5 テーマで最も明るい

色相が紺・橙・青緑・緑・朱と散っているので、並べたときに互いを打ち消さない。

テーマを決めたら themes/theme-<x>.md を必ず全文読む。

3-1. テーマの差し替えは「色の付け替え」ではない

既存デッキのテーマだけを差し替えることはできない。 テーマは見出しサイズ・本文サイズ・ウェイトも規定するため、 1 枚に入る情報量が変わり、構成そのものを作り直す必要が出る。

実際に確認された例:

• テーマ B で 2 行に収まった表紙コピーが、テーマ C（h1 76px）では 3 行になり語中で改行した
• テーマ B で 1 枚に収まった 4 行の表が、テーマ C では収まらず、2×2 の塊に作り替えが必要だった
• 逆にテーマ B で下部が空いていたスライドが、テーマ C ではちょうど埋まった

「テーマを変えたい」と言われたら、edit ではなく作り直し（full / quick）として扱う。 そのことをユーザーに伝えてから進める。

---

4. 必読ファイル

着手前に必ず読む:

1. workflows/<mode>.md（1 本だけ）
2. core/rules.md — 全テーマ共通の禁止事項・整列・preflight
3. themes/theme-<x>.md — 選んだテーマ
4. styles/style-<style>.md — 選んだスタイル（スタイルの規定はこのファイルが正本）
5. templates/<use>.md — proposal.md（提案）または internal.md（社内）

追加で読むもの:

• full モード: core/structure.md
• 生成後・edit モード: core/validation.md
• 実装値に迷ったとき（必読ではない）: refs/<theme>.html

refs/*.html は実例集であって雛形ではない。骨格をなぞらず、実装値（クラス設計・密度・SVG の書き方）を拾う参照元として使う。

---

5. 出力先

カレント作業ディレクトリ配下の slides/。

ファイル	いつ
slides/<name>.html	常に。<body> 直後にマーカー必須
slides/<name>-structure.md	構成を設計した場合（full モード）
slides/.work/iter-<N>/	視覚検証の撮影 PNG
slides/<name>.pdf	明示的に指示された時だけ

マーカー（必須）:

<!-- kit:slide-zukai-kit v1.1 theme:B use:proposal style:formal viz:low -->

旧形式（v1.0・style なし）は style:standard viz:mid として扱う（後方互換）。

<name> は内容に応じた英語ケバブケース（例: support-ai-proposal.html）。

---

6. Playwright

視覚検証に必要。ローカルとグローバルの両方を探す:

node -e "require('playwright')" 2>/dev/null \
  || NODE_PATH="$(npm root -g 2>/dev/null)" node -e "require('playwright')" 2>/dev/null \
  || echo "NEED_INSTALL"

NEED_INSTALL なら案内する:

npm install -g playwright && npx playwright install chromium

未導入でも生成は行う。 ただし完了報告の冒頭で「視覚検証は未実施です」と明示する。 黙ってスキップすると、崩れたスライドがそのまま使われる。

scripts/capture.js / scripts/to-pdf.js はグローバル npm root を自動解決するので NODE_PATH 指定は不要。 貼り付け型のスニペット（node - <<'NODE'）には自動解決が無いので、先頭に NODE_PATH="$(npm root -g)" を付ける。

---

7. このスキルでやらないこと

• 単発の図解画像（PNG）の納品（スライド内の図解は担当する）
• PowerPoint (.pptx) 生成
• スライドアニメーション・トランジション（禁止事項）
• 外部画像・外部 CSS / JS（Google Fonts の <link> のみ例外）

---

8. 実行フロー

ユーザー入力
    ↓
モード判定（§1）
    ↓
スタイル + 用途 + テーマを選択式で必ず確認（AskUserQuestion・§2）／材料不足なら 1 問追加して待つ（§2-1）
    ↓
必読ファイル読み込み（§4）
    ↓
構成を数行で宣言する ← 返事は待たない
    ↓
HTML 生成（マーカー付与）
    ↓
iter-0 preflight（core/rules.md §12 の 21 項目 ＋ 面ルール検査
                  ＋ templates/<use>.md の追加検査）← 必ず全件
    ↓
視覚検証ループ（core/validation.md。全枚 × 最大 2 周）
    ↓
完了報告

iter-0 preflight は必須。 ヒットを放置して撮影に進まない。

to-pdf モード

対象 HTML を特定 → Playwright 確認 → scripts/to-pdf.js → ページ数とパスを報告

このモードでは workflows/to-pdf.md と core/validation.md §1 だけ読めば足りる。

---

9. 完了報告に含めること

• テーマ名・用途・スタイル（と viz）
• TODO ブロックの一覧（あれば）
• 叩き台から書き直した見出し（提案資料の場合）
• preflight で例外として残した項目とその理由
• 視覚検証の実施有無（未実施ならその旨を冒頭に）

---

10. 完了前セルフチェック

• 表紙が 4 型（C / E / G / H）のいずれかで、直前に作ったデッキと同じ型になっていないか（core/structure.md §4-B）
• 同じ体裁のスライドが 3 枚連続していないか（core/rules.md §3）
• 並列カードの中で 1 枚だけ色が違う箇所がないか
• マーカーコメントが入っているか
• マーカーの style / viz が、実際の作り（構図の第一候補・密度・面ルール運用）と一致しているか
• フォントのローカル代替が書かれているか
• 面ルールの許容枚数を超えていないか
• TODO ブロックを推測で埋めていないか
• PDF を、指示されていないのに作っていないか
• カード grid・表・箇条書きで済ませた枚について、core/structure.md §8 のモチーフ候補を 2 つ検討して退けた理由を言えるか