kudo-deck-generation-router v1.1¶

§0 正体とCanon関係¶

正体：資料作成の「生成ルート選択」を司る実装子スキル。動詞群3の子。

親子関係： - 親：kudo-proposal-deck（Phase 3 PPTX生成の意思決定層に挿入） - 兄弟：kudo-briefing（実装子）／kudo-schedule-budget（実装子）／kudo-deck-aesthetic-qa（実装子★仮説）／kudo-client-template-factory（実装子・v1.1で連携明記） - 辞書型孫との協働：kudo-presenter-lens-library（レンズ選定→本スキルのレーン選択にフィードバック）

Canon関係： - Canon-外（工藤独自概念の直接操作はしない） - ただし Phase 3 で版木／記憶の箱／Pre-POSITIONING 等を視覚化する際、どのレーンが概念を損なわないかを判定する補助役

§0.1 起動の前提（必ず先に読む）¶

本スキルを単独起動することは推奨されない。原則として： 1. 先に親 kudo-proposal-deck の Phase 0〜Phase 2 を通過していること 2. Phase 0.3 で5型×2モード（Narrative／Consulting／Editorial／Lecture／Hybrid × Dialogue／Final）が確定していること 3. Phase 0.4 で「クライアント別 .potx の存在確認」が完了していること（v1.1新設） — python-pptx ルート選択時には必須 4. Phase 2 のワイヤーフレームが工藤承認済みであること 5. スライド枚数・用途・クライアント編集の要否・即応性要求が把握できていること

これらが未定の場合、本スキルより先に親スキルを起動して上流を埋める。

§1 3レーン判断マトリクス¶

§1.1 3レーンの特性比較¶

軸	A. python-pptx	B. Claude Design	C. Claude Code SVG
得意領域	大量ページ／編集可能性／一貫性／正確な座標制御／スケジュール・ガント・表	HP型Hero／モダンレイアウト／タイポ映え／高解像度プレビュー／プロトタイプ兼用	1ページ極審美／印刷対応／ロゴ組込み／ベクター精度
苦手領域	審美の伸び代／モダン感／HP型フリーレイアウト	PPTXネイティブ出力なし／大量ページ／表・ガントの精密制御／クライアント編集後の継続更新	大量生成・テンプレ化／動的データ差替／複数ページ統一運用
出力形式	.pptx（編集可）	HTML／画像／プロトタイプ URL（Figma的な地続き）	.svg／.png／.pdf（ベクター）
編集継承	クライアント側で容易	再プロンプト前提／直接編集は制限	再生成 or 手動SVG編集
スピード	テンプレ熟度次第（1日〜）	高速（数時間で初稿）	中（1〜3時間／枚）
審美上限	中	高	極高（1枚）

§1.2 4軸スコアリング（レーン選択の判断軸）★仮説：重み調整は戻り次第レビュー¶

各案件につき、以下4軸を 1〜5 で採点し、合計スコアでレーンを判定する。

軸	1（低）	5（高）
S1 枚数	1〜5枚	30枚〜
S2 編集可能性要求	クライアントは見るだけ	クライアントが後日大幅編集
S3 審美要求水準	社内共有レベル	投資家・大規模講演・対外公表
S4 即応性	1週間後でOK	今日中・明日朝

レーン選択ルール（★仮説）： - S1≥4 かつ S2≥4 → A（python-pptx）メイン、核スライドのみ B or C - S1≤2 かつ S3≥4 → C（Claude Code SVG）メイン or B（Claude Design）メイン - S4≥4 かつ S3≥3 → B（Claude Design）即応ルート（数時間で初稿） - バランス型（S1=3, S2=3, S3=3, S4=3）→ ハイブリッド運用（§1.3）

§1.3 ハイブリッド運用パターン（標準化）¶

実案件の多くは単一レーンでは最適化できない。工藤の過去運用から抽出した4パターン：

パターン1：HPヒーロー型ピッチ¶

用途：投資家向けピッチ／新規事業提案／ブランド刷新初回
構成：表紙〜第1章頭（B）＋本体（A）＋核概念図解1枚（C）
例：10枚デッキのうち、表紙・冒頭2枚 = B、本体6枚 = A、核概念1枚 = C

パターン2：中規模編集可能デッキ¶

用途：定常クライアントへの中期提案／社内稟議用
構成：全編A（python-pptx）、表紙のみB差し替え
例：20〜30枚、全て編集可能PPTXで納品、表紙だけ別ファイルでB生成の高解像度を貼り込み

パターン3：講演資料・審美特化¶

用途：工藤自身の講演・書籍企画PR
構成：全編B（Claude Design）＋印刷対応ポスター1枚C
例：30分講演用15枚すべてB、ポスター1枚Cでベクター出力

パターン4：超速即応モード¶

用途：クライアント急ぎ相談／当日プレゼン
構成：B で初稿作成→必要箇所のみA（python-pptx）で置換
例：明日朝のプレゼン、今夜BでHTML初稿→必要な数値表だけA後付け

§1.5 前処理：クライアント別 .potx 確認（v1.1新設）¶

python-pptx ルート（A）が選択された瞬間、必ず本節をチェックする。

§1.5.1 なぜ必要か¶

python-pptx でゼロからスライドを生成すると、PowerPoint の「テーマカラー」「Slide Master」「Theme Font」が空のまま .pptx が出力される。これは以下のストレスを生む： - クライアントが PPTX を開いた直後、テーマカラーリボンに何もない - 配色変更やフォント差し替えが手作業 - 親スキル kudo-proposal-deck §11項目の 4-1〜4-4（Theme Colors / Slide Master / Theme Font 関連）が破綻 - 案件が増えるたび毎回同じ手作業が発生

これを構造的に解消するため、python-pptx ルート選択時には必ずクライアント／業種別の .potx を先に用意し、それを起点に生成する運用を v1.1 で標準化。

§1.5.2 4ステップ判定¶

Step 1：適用 .potx の特定¶

親 Phase 0.4 で確定済の .potx ファイル名を取得： - 既存クライアント → kudo-master-{クライアント名}-v{N}.potx - 業種テンプレ → kudo-master-{業種}-{シグネチャー色}.potx - 汎用デフォルト → kudo-master-v5FINAL.potx

Step 2：実在チェック¶

ls ~/Library/Group\ Containers/UBF8T346G9.Office/User\ Content.localized/Templates.localized/{ファイル名}

Step 3：未存在の場合¶

kudo-client-template-factory を起動して30分以内に生成： - PRE：パレット13色＋Pattern B フォント（kudo-brand-architecture から取得） - BUILD：build_kudo_template.py の PALETTE 辞書を差し替えて再実行 - POST：Templates.localized へコピー - VERIFY：PowerPoint「ホーム > その他のテーマ」で出現確認

Step 4：存在する場合¶

python-pptx で Presentation('{path}/{ファイル名}.potx') を起点に開いて生成開始する。

§1.5.3 .potx 起点で生成するメリット（実装ベネフィット）¶

テーマカラー自動継承：shape.fill.solid() で RGBColor.from_string("BC002D") と直書きする代わりに、MSO_THEME_COLOR.ACCENT_1 でテーマ参照できる（編集容易性が劇的向上）
majorFont/minorFont 自動継承：run.font.name = "..." で和文を直指定する代わりに、テーマフォントが自動適用される（フォント差し替え時にスライド全体が連動）
Slide Master 共通要素自動継承：左上タイトル・右上ページ番号・背景色がスライド追加時に自動付与
クライアント編集の継続性：クライアントが後日 PowerPoint で「テーマの色」をワンクリック変更できる（PPTX全体に波及）

§1.5.4 ハイブリッド／非python-pptxルートの場合¶

B（Claude Design）単独 / C（Claude Code SVG）単独 → §1.5 はスキップ可（テーマファイル概念がHTML/SVGには存在しない）
ハイブリッド（A+B / A+C） → A レーンの部分のみ §1.5 必須

§1.6 HTMLプレビュー先行プロトコル（v1.2新設・2026-05-08）¶

工藤さん2026-05-08発話「PPTX化前にHTML一枚物でチェックする方が作業負荷が小さい」を起点に、新規デッキ生成時のHTMLプレビュー先行を本スキルの標準フェーズとして固定化する。kudo-proposal-deck §9.13.6と完全連動。

§1.6.1 起動条件¶

必須：新規デッキ（Mode A）／レーン選択がA（python-pptx）or A+B／A+Cハイブリッドの場合
免除：
既存デッキ磨き込み（Mode B、差分作業）
レーンB（Claude Design）単独 — そもそもHTMLが本体出力
レーンC（Claude Code SVG）単独 — 1枚特化のため不要

§1.6.2 HTMLプレビュー仕様¶

アスペクト比：16:9（PPTX 13.333in × 7.5in に相当）
CSS指定：個人設定§8およびkudo-brand-tokens.jsonで規定されたフォントファミリーを参照（フォント名はSKILL本文にハードコードしない）
body／DISPLAY／READING：§8で「明朝」または「Display/Reading」として規定されたファミリーを指定
bullet／UI：§8で「ゴシック」または「UI」として規定されたファミリーを指定
フォント名の具体値は kudo-brand-tokens.json から動的に取得して埋め込み
font-size：最小 18pt 本文 / 14pt 注釈（kudo-deck-aesthetic-qa A25と同基準）
配色：kudo-brand-tokens.json参照（執筆時点では v5-FINAL 11色＋予備2色）
出力形式：単一HTMLファイル（CSS/JSインライン、外部依存ゼロ）

§1.6.3 プレビュー時のチェックリスト¶

工藤さんがHTMLを開いた時、以下を一気に判断できるよう設計：

目次は問いの形式で3-5問か（kudo-deck-aesthetic-qa A24相当）
1スライドのテキスト要素数 ≤ 12か（A26相当）
font-sizeが18pt本文 / 14pt注釈で破綻していないか（A25相当）
章ナンバリング・★答えスライドが分離されているか（FRAMEWORK整合・A21-A23相当）
配色は v5-FINAL 11色のみか

§1.6.4 プレビュー完了 → PPTX化のハンドオフ¶

工藤さんから「OK／このまま進めて」または修正指示を受領
修正指示を反映した最終HTML確定後、初めてレーンA（python-pptx）に進む
HTMLのfont-size指定をそのまま python-pptx の Pt(18) Pt(14) 等に変換
配色は theme color slot 経由で配置（直接hex禁止 = §1.5.3メリット維持）

§1.6.5 なぜHTML先行が作業負荷を下げるか¶

修正コストの差：HTMLは構造変更が秒単位、PPTXは shape再配置が分単位
density確認の精度：HTMLは実画面で「読めるか／詰まりすぎか」が即座に判断可能
font-size階段の見え方：18pt本文・32pt見出し・14pt注釈が「実際にどう見えるか」をMacの実機を待たず確認できる
Phase 1-2の遡及的修正回避：PPTX化後に「目次が6問もあった」「フォント小さすぎ」と気づくと、構成からやり直しになる

§1.6.6 既存デッキ磨き込み（Mode B）でHTML先行を使う場合¶

原則免除だが、以下のケースでは推奨： - 既存PPTXが20枚以上 + 構造大改造を伴う場合 - 旧Pattern B-Hiragino（Hiragino × Helvetica混植）から Pattern C-Yu（游書体統一）への移行 - 6問→3問への目次圧縮など、構成自体の変更を伴う場合

このような場合は、まず構成案だけ HTML 1ページで提示→承認→PPTX再生成、の順で動く。

§2 Claude Design 運用プロトコル¶

§2.1 プロンプト設計の原則（★仮説：工藤の実運用に合わせて調整）¶

Claude Design は自然言語で指示可能だが、品質を安定させるには構造化プロンプトを用いる。

必ず含める要素（6点）： 1. デッキ型の指定：「Narrative型／Consulting型／Editorial型／Lecture型／Hybrid型」のいずれか（親kudo-proposal-deck Phase 0.3 で確定したもの） 2. スライド枚数と各スライドの役割：見出しリストで明示 3. カラーコード（必須・下記§2.3） 4. フォント指定：個人設定§8およびkudo-brand-tokens.jsonで規定されたパターン（執筆時点では Pattern D-Noto 統一2書体）を参照。フォント名はSKILL本文にハードコードしない（§8 が一次ソース） 5. 視覚文法：「大見出し：本文 = 3:1 の視覚重量」「余白は上下左右10%以上」等 6. 禁則事項：絵文字禁止／グラデーション禁止（指定時除く）／独自概念語の直接露出禁止

§2.2 プロンプトテンプレート（基礎形）¶

あなたはプロのプレゼン・ウェブデザイナーです。
以下の仕様で {N枚} のスライドをHTML＋CSSで作成してください。

【用途】{投資家向けピッチ／ブランド戦略初回提案／講演資料 etc.}
【デッキ型】{Narrative / Consulting / Editorial / Lecture / Hybrid}
【モード】{Dialogue / Final}

【カラーシステム＆フォント】
- **ハードコード禁止**。一次ソース `claude/claude-reference/design-tokens/kudo-brand-tokens.json` と CLAUDE.md §6 とユーザー個人設定項目8 から、セッション開始時に現在値をロードして使用する
- 生成プロンプト内では v5-FINAL パレット（Layer 1/2/3 + 予備2色）と Pattern B フォント（DISPLAY/READING/UI 3モード）の現在値を直接埋め込む
- 納品運用(a) PDF-first に従う（凸版はPPTX埋込不可のため）

【各スライドの内容】
スライド1：{表紙｜タイトル｜サブコピー}
スライド2：{核心問い｜BEFORE→AFTER 構造}
スライド3：{3択クロージング（N択）}
...

【視覚文法】
- 余白は上下左右10%以上
- 大見出し：本文 = 視覚重量 3:1
- 1スライド 1メッセージ原則
- 図解は3要素以下
- 絵文字・グラデーション・装飾フレーム禁止

【出力形式】
1920×1080px のHTMLをスライドごとに生成。
各スライドはsection要素で区切り、印刷対応のCSSを含める。

【絶対遵守レイアウトルール（kudo-proposal-deck 11項目 参照・2026-04-24改訂）】
- 1-a 背景：表紙・目次・スケジュールのみJet／他はPaper
- 1-b/1-d 左上：**そのページ固有の章名・節名 1行**（目次対応の要約・9pt以上・Mushroom色）。ページごとに内容は違う
- 1-c 右上ページ番号：**手打ち禁止**。下記JSで自動連動させる（値はページごとに違う）
- 1-e 左上の内容は**ページ固有情報**のみ。**全ページ共通のデッキタイトル・案件名等を繰り返し配置しない**
- **1-f 全ページ共通の繰り返しメタ情報を一切配置しない**（日付・著者名・案件名クレジット・デッキ共通タイトル等）。同じ情報の反復は記号化・ノイズ化して読み手を消耗させる。例外は右上ページ番号のみ

【ページ番号自動連動（絶対・kudo-deck-generation-router §2.2 コード例）】
各スライドの右上に `<span class="page-number"></span>` を空で用意し、
HTMLの末尾 </body> の直前に以下のscriptを必ず入れる：

```html
<script>
(function() {
  const slides = document.querySelectorAll('section.slide');
  const total = String(slides.length).padStart(2, '0');
  slides.forEach((s, i) => {
    const target = s.querySelector('.page-number');
    if (target) {
      target.textContent = String(i + 1).padStart(2, '0') + ' / ' + total;
    }
  });
})();
</script>

これによりスライドの追加・並び替え・削除に自動追随する。これが技術的に採用できない理由がある場合のみ、ページ番号を完全省略し、 その旨をユーザーに毎回明示報告する。

### §2.3 カラーコード埋め込み仕様（絶対）

工藤のグローバル設定に定義されたカラーシステムは、**Claude Design／python-pptx／Claude Code SVG すべての生成レーンで同一の値を使う**。一次ソース（tokens.json / CLAUDE.md §6 / 個人設定 §8）から最新を読み込んで使用すること。

**運用比率の目安（★仮説）**：
- ニュートラル：プライム：セカンダリー = **75：15：10**
- 1スライドで使うアクセントは原則1色、最大2色まで
- アクセント5色すべてを同一デッキに登場させない（安っぽくなる）

### §2.4 フォント指定

- **フォント設定はハードコードしない**。一次ソース（tokens.json / CLAUDE.md §6 / 個人設定項目8）から現在値を読み込んで使用する
- Claude Design HTML の場合：UI和文の Noto Sans JP は Google Fonts から import、凸版シリーズは Adobe Fonts 前提のため `local()` フォールバックで記述し工藤さんのブラウザで実描画
- **CJK tofu対策【絶対】**：HTMLレーンでは `font-family` の**先頭に必ず和文フォント**（凸版文久明朝 / ヒラギノ明朝 / 游明朝系）を置く。Claude／Figma／MCP系は先頭フォントしか見ず、非CJK（Neue Haas / Inter / Arial等）が先頭にあると**日本語が完全に描画されない**事故が発生する（2025-2026 Figma Forum 等で検証済）。正：`font-family: "凸版文久明朝 Pr6N R", "Hiragino Mincho ProN", serif;` ／誤：`font-family: "Neue Haas Grotesk Text Pro", "凸版文久明朝 Pr6N R", serif;`
- **viewport-base-kudo.css の必須インクルード**：HTMLレーン出力では `claude/claude-reference/02_templates/viewport-base-kudo.css` を最初にリンクする。overflow:hidden 二重化＋clamp() 全タイポでAIスライドの頻発破綻（テキスト溢れ／横スクロール／レイアウト崩れ）を構造的に封じる。`<link rel="stylesheet" href="./viewport-base-kudo.css">` or インライン展開
- **Anti AI-Slop 回避**（Anthropic公式 Cookbook準拠）：Inter／Roboto／Arial（単体）／Open Sans／Latoは**欧文として使わない**（AI生成スライドの見分けがつく定番フォント）。Pattern B の Neue Haas Grotesk は問題なし。背景は solid 1色で装飾ゼロにせず、Oatmealやカラー帯で変化を付ける。紫→青グラデ×白背景はNG
- Variable Font 版は禁止（python-pptx と統一するため）

## §3 Claude Code SVG 運用プロトコル

### §3.1 用途の限定

Claude Code SVG は「1枚に魂を込める」用途に限る：
- カバー1枚
- ステートメント1枚（ミッション／ビジョン／核コピー）
- 核概念図解1枚（版木／記憶の箱の視覚化）
- ロゴ組込み印刷対応物1枚

### §3.2 生成フロー

1. **PRE**：kudo-design-generation-loop の PRE段階に準拠（必要ならkudo-designer-lens-library を呼んでペア選定）
2. **GEN**：Claude Code で SVG を並列生成（3〜5案）
3. **CRIT**：kudo-deck-aesthetic-qa でペア×8軸採点
4. **FIX**：微調整→ベクター出力（SVG／PDF）

### §3.3 カラー・フォント仕様

- §2.3 のカラーコードをそのまま使う
- SVGなのでフォントはアウトライン化（or Google Fonts／Adobe Fonts依存を明示）
- ロゴ組込み時は実寸（名刺サイズ・ポスターサイズ）をベクター保持

## §4 python-pptx ルート（v1.1改訂）

親 kudo-proposal-deck v2.1 §Phase 3 で引き続きメイン扱い。**v1.1 から、python-pptx ルート選択時は必ず §1.5 を経由してクライアント別 .potx を起点とすることを義務化**。

### §4.1 .potx 起点の生成パターン

```python
from pptx import Presentation

# v1.1 推奨：.potx を起点
TEMPLATE = "/Users/kudotakuma/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Templates.localized/kudo-master-{案件}.potx"
prs = Presentation(TEMPLATE)

# Blank レイアウトを取得（テーマカラー・フォント自動継承）
blank = prs.slide_layouts[6]
slide = prs.slides.add_slide(blank)

# テーマカラー参照（直書きしない）
from pptx.dml.color import RGBColor
from pptx.enum.dml import MSO_THEME_COLOR
shape = slide.shapes.add_shape(MSO_SHAPE.RECTANGLE, 0, 0, SW, SH)
shape.fill.solid()
shape.fill.fore_color.theme_color = MSO_THEME_COLOR.ACCENT_1  # ← クライアント色の Crimson が自動適用

§4.2 3レーン併用時のハンドオフ¶

B → Aハンドオフ：Claude Design の HTML出力を画像化（1920×1080 PNG）→ python-pptx で背景フル画像として貼り込み
C → Aハンドオフ：SVGをPPTX の Shape として埋め込み or PNG化して貼り込み
A → Bハンドオフ：python-pptx の該当スライドだけをクライアントが後で差し替え可能な「編集可能PPTX」として維持

§5 親 kudo-proposal-deck Phase 3 への接続仕様¶

親 Phase 3 の冒頭に本スキルを挿入する。判断フロー：

Phase 3 開始
  ↓
[kudo-deck-generation-router 起動]
  ↓
S1〜S4 採点（1〜5スコア入力）
  ↓
レーン選択（単一 or ハイブリッド）
  ↓
（python-pptx 含む場合）§1.5 .potx 確認 ← v1.1新設
  ↓
各スライドのレーン割当て決定（スプレッドシート or 表で可視化）
  ↓
各レーンで並列生成
  ↓
ハンドオフ（§4.2）で1つのPPTX or デッキに統合
  ↓
[kudo-deck-aesthetic-qa 起動]（★仮説 Phase 4）
  ↓
Phase 4 数値QA
  ↓
納品

§6 具体例：採点→レーン選択のサンプル¶

例1：投資家向けピッチ（パターン1）¶

S1 枚数：10枚 = 2点
S2 編集可能性：投資家は見るだけ = 1点
S3 審美要求：極高 = 5点
S4 即応性：来週月曜 = 3点
合計：11点、S3＞S1 → B中心、表紙＋核1枚でCを併用
A使用なし → §1.5 スキップ

例2：ブランド中期戦略（パターン2）¶

S1 枚数：25枚 = 4点
S2 編集可能性：クライアント側で継続編集 = 5点
S3 審美要求：高 = 4点
S4 即応性：2週間 = 2点
合計：15点、S1+S2高 → A中心、表紙のみBで高解像度差替
A使用あり → §1.5 必須：クライアント別 .potx を確認 or kudo-client-template-factory で生成

例3：工藤の講演資料（パターン3）¶

S1 枚数：15枚 = 3点
S2 編集可能性：自分で編集 = 2点
S3 審美要求：極高（プロ審美） = 5点
S4 即応性：3日後 = 4点
合計：14点、編集可能性低・審美極高 → B全編、ポスターのみC
A使用なし → §1.5 スキップ

例4：明日朝プレゼン（パターン4）¶

S1 枚数：8枚 = 2点
S2 編集可能性：当日のみ = 1点
S3 審美要求：中 = 3点
S4 即応性：今夜 = 5点
合計：11点、S4極大 → B即応モード、必要な表だけA後付
A使用あり（部分） → §1.5 必須：表だけなら kudo-master-v5FINAL でOK

§7 NG行動¶

python-pptx だけで進める（現状の単一ルート） — 本スキル存在理由の否定
Claude Design で30枚以上を一気に作る — 大量ページは A が適任
C（SVG）で編集可能デッキを作る — Cは1枚用途限定
カラーコードを改変する — §2.3 は絶対順守
アクセント5色全部使う — 安っぽくなる
Variable Font を使う — python-pptx との互換性崩壊
工藤独自概念語（版木・記憶の箱・Pre-POSITIONING）を対外スライドに直露出 — 親kudo-proposal-deckの禁止事項を継承
ハンドオフ時に座標・ピクセル整合を確認しない — B→A／C→A 統合時の崩れ原因
Phase 2 ワイヤーフレーム未合意でレーン選択 — 上流未完で下流を決めるな
★仮説マーカーを外して実装確定扱いする — v1.0は仮説含む
§1.5 をスキップして python-pptx ルートで生成開始する（v1.1新設） — テーマ・フォント・マスター継承の便益を全捨てすることになる

§8 kudo-writing との併走原則¶

スライドヘッドライン／タグライン／核コピー生成は、本スキルではなく kudo-writing の管轄。本スキル起動中、文字列を1行でも新規生成する瞬間には kudo-writing を併走トリガーすること。

具体例： - 表紙のタイトルを決める → kudo-writing - 章扉のキャッチを決める → kudo-writing - N択クロージングの3選択肢の言葉を決める → kudo-writing - 本スキルは「視覚文法・生成レーン」担当、「言葉」は kudo-writing

§9 kudo-deck-aesthetic-qa との連携（★仮説スキル）¶

本スキルで各レーンが出力した成果物は、Phase 4 で kudo-deck-aesthetic-qa により審美検証される。

B（Claude Design）出力：タイポ／余白／階層の8軸採点
C（Claude Code SVG）出力：ペアレンズ比較（佐藤可士和×Massimo Vignelli など）
A（python-pptx）出力：既存 scripts/qa_check.py に加え、審美レーンを併走

kudo-deck-aesthetic-qa が未稼働（★仮説未確定）の場合、暫定で kudo-designer-lens-library を直接呼び出して審美チェックを行う。

§10 起動ルール¶

§10.1 自動トリガー条件¶

親 kudo-proposal-deck の Phase 3 開始時に自動起動。

明示トリガーキーワード（親から独立して呼ばれる場合）： - 「Claude Designで」「ライド(Claude Design)で」「ライドデザイン」 - 「HPみたいなスライド」「ピッチデッキ」「高解像度で」 - 「核スライドだけ別格に」「表紙だけ」「SVGで」 - 「ハイブリッド生成」「レーン選択」「どのツールで作る？」

§10.2 起動時の最初の3ステップ¶

親 kudo-proposal-deck の Phase 0〜Phase 2 完了状態を確認（v1.1：Phase 0.4 .potx 確認も含む）
S1〜S4 の採点を工藤にヒアリング（Dialogueモード） or 既知情報から自動採点（Finalモード）
§1.3 の4パターンから1つ選定 or 新パターン（★仮説として記録）／python-pptx ルート選択時は §1.5 を必ず通す

§11 更新履歴¶

v1.1（2026-04-24）：§1.5「前処理：クライアント別 .potx 確認」を新設し、python-pptx ルート選択時の必須チェックポイントとして組込。kudo-client-template-factory との連携を明文化。§4 を「.potx 起点の生成パターン」に書き換え（テーマカラー直書きから theme_color 参照へ）。§5 接続フローに「.potx 確認」ステップを追加。§7 NG行動に「§1.5 スキップ」を追加。§10.2 起動ステップに .potx 確認を組込。
v1.0（2026-04-21）：新規作成。工藤12時間不在中の自律実行で作成。Claude Design独立スキル新設の決定を受けて、3レーン判断マトリクス＋ハイブリッド4パターン＋プロンプトテンプレートを整備。★仮説マーカー付箇所：4軸重み付け／ハイブリッド4パターン境界／カラー運用比率70:25:5／プロンプトテンプレートの文言。戻り次第レビュー前提。

§12 戻り次第レビューしてほしい★仮説一覧¶

★仮説：4軸スコアリング（S1〜S4）の閾値（S1≥4／S4≥4等）の妥当性
★仮説：ハイブリッド4パターンの分類粒度（パターン5以降が必要か）
★仮説：カラー運用比率75:15:10の具体数値
★仮説：プロンプトテンプレート §2.2 の文言が工藤の実運用に合っているか
★仮説：Claude Code SVG の「1枚限定用途」が本当に1枚限定でよいか（複数枚のキービジュアルシリーズ展開の可能性）
★仮説：B→Aハンドオフの「画像化→背景貼込」が最適か（編集可能性を損なう懸念）
★仮説：英文併記フォント3候補（Inter／Söhne／IBM Plex Sans）の優先順位
★仮説（v1.1新設）：§1.5 で「ハイブリッド時は A 部分のみ .potx 起点」とする運用が、ハンドオフ時に色のズレを起こさないか
★仮説（v1.1新設）：theme_color 参照を全スライドで徹底すると、特殊色（Wine Burgundy 等の予備色）の使用が制限される — 例外規定の必要性

本スキルは v1.1 で kudo-client-template-factory との連携を明文化。戻り次第レビュー前提。