build-slide-definition

name	build-slide-definition
description	提案内容を読み込み、マスター定義書（Youble_スライド定義書.yaml）に基づいて案件個別のスライド定義書を作成し、slide-def-reviewer サブエージェントのレビューが合格(PASS)するまで「レビュー→修正」を自動で繰り返すスキル。提案内容からスライド化の設計図（定義書）を作りたいときに使う。

案件別スライド定義書 作成ループ（生成 → レビュー → 修正 → 合格）

提案内容を起点に、マスター定義書に沿って「案件個別のスライド定義書」を作り、 独立したレビューサブエージェント（slide-def-reviewer）が PASS を出すまで自走で仕上げるスキル。 ここで作るのは HTMLデッキそのものではなく、デッキを生成するための設計図（スライド定義書） である。

いつ使うか

• 新しい案件の提案内容から、スライド化の設計図を作りたいとき
• 「この提案内容でスライド定義書を作って」「定義書を合格まで仕上げて」等
• 後工程（HTMLデッキ生成）に渡せる、構造化された定義を用意したいとき

前提ファイル（このリポジトリの資産）

• マスター定義書: デザイン/templates/Youble_スライド定義書.yaml（slot/figure/制約/デッキ構成の正）
• デザインベストプラクティス: デザイン/sources/practices/01_営業提案スライド_ベストプラクティス.md
• レビューサブエージェント: slide-def-reviewer（.claude/agents/slide-def-reviewer.md）
• 提案内容: 案件ごとの提案内容（呼び出し時に渡される。テキスト/Markdown/メモ等）
• 出力先: デザイン/proposals/<案件名>_スライド定義書.yaml

手順

Step 0｜入力の確認

• 提案内容 を特定する（ファイルパス or 貼り付けテキスト）。無ければ呼び出し元に要求する（提案内容なしで定義書を作らない）。
• 案件名を決める（出力ファイル名に使う）。
• 出力先 デザイン/proposals/ が無ければ作成する。

Step 1｜読み込み（必ず最初に）

次を精読してから着手する:

1. マスター定義書 Youble_スライド定義書.yaml
   • design_system（色/フォント/タイプスケール）
   • content_rules（13字メッセージライン・accent語1つ・配色70:25:5・禁止事項・disclaimer）
   • deck_structure（標準ストーリー順序・required/optional/repeatable）
   • slide_types（17タイプの slots と figures、文字数制約）
2. ベストプラクティス01（設計根拠の確認）
3. 提案内容（顧客名・課題・原因・解決策・効果・実績・価格方針・次アクション等を抽出）

Step 2｜採用スライドの設計

• マスター定義書の deck_structure.order を土台に、この案件で使うスライドを選定する。
  • required は原則すべて採用。optional（big_number/chart/voice/clients）は提案内容に裏付けがある場合のみ採用。
  • detail（施策詳細）は施策の数だけ複製。section（章扉）は章の頭に配置。
• 提案内容が不足してスライドを埋められない箇所は、捏造せず「要確認」「仮（※差し替え）」として明示する。

Step 3｜個別スライド定義書の作成

デザイン/proposals/<案件名>_スライド定義書.yaml を作成する。マスター定義書と同じslot構造で、各slotを案件の具体内容で埋める。

• メッセージラインは 13字以内・accent語1つ。1スライド1メッセージ。
• 各スライドに figures（どこに何の図を入れるか） を必ず明記。
• 数値・実績・料金など仮の値には disclaimer（※…差し替え可）を付ける。
• すべて提案内容の固有情報で具体化する（一般論で薄めない）。
• マスター定義書のキー名・count・制約を厳守する。

Step 4｜レビュー（サブエージェント呼び出し）

slide-def-reviewer サブエージェントを呼ぶ（Agent ツール, subagent_type: slide-def-reviewer）。

• 渡すもの: ①作成した個別定義書のパス ②マスター定義書のパス ③元の提案内容のパス/本文。
• 毎ラウンド「新規の独立レビュー」として呼ぶ（前ラウンドの判定に引きずらせない）。
• slide-def-reviewer がまだ登録されておらず呼べない場合のみ、general-purpose に同等のレビュー指示（A構造適合 / Bデザイン・コンテンツルール / C忠実性、忖度なし、固定フォーマット、合否判定）を与えて代替する。

Step 5｜修正

レビュー結果の指摘に基づき、メイン（あなた）が定義書を修正する。

• CRITICAL → HIGH → MEDIUM の順で対応する（必須slot欠落・捏造・構造逸脱を最優先）。
• 13字超過は圧縮、accent語は1語に、出典注記の欠落は追加、取りこぼした重要ポイントは反映。
• 捏造が指摘されたら、提案内容に戻して事実で埋め直す（埋まらないなら仮＋disclaimerに変える）。

Step 6｜合格まで反復

Step 4 → Step 5 を、レビューが PASS になるまで繰り返す。

• 合格ライン: CRITICAL 0件 ＋ HIGH 0件 ＋ 構造/ルール/忠実性をすべて満たす。
• 上限は 5ラウンド。超えても PASS しなければ、残課題と理由を率直に報告して止める（無限ループにしない）。

Step 7｜完了報告

• ラウンドごとの判定の推移（Round 1 FAIL → … → PASS）を示す。
• 各ラウンドで何を直したかを簡潔に。
• 提出前メモ（レビュー対象外）として、仮データなどHTMLデッキ化前に実値へ差し替える点を明記する。
• 次工程（この定義書からHTMLデッキを生成する）に渡せる状態であることを伝える。

原則

• マスター定義書と提案内容を読む前に、定義書を書き始めない。
• レビューは必ず独立サブエージェントに任せる（自己レビューで済ませない＝客観性の担保）。
• 構造適合・デザインルール・提案内容への忠実性の3つすべてで合格させる。
• 提案内容に無いことを作り込まない。仮値は必ず disclaimer を付け、提出前差し替えを申し送る。