| 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｜読み込み（必ず最初に）
次を精読してから着手する:
- マスター定義書
Youble_スライド定義書.yaml
design_system（色/フォント/タイプスケール）content_rules（13字メッセージライン・accent語1つ・配色70:25:5・禁止事項・disclaimer）deck_structure（標準ストーリー順序・required/optional/repeatable）slide_types（17タイプの slots と figures、文字数制約）
- ベストプラクティス01（設計根拠の確認）
- 提案内容（顧客名・課題・原因・解決策・効果・実績・価格方針・次アクション等を抽出）
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 を付け、提出前差し替えを申し送る。
