build-proposal-deck

name	build-proposal-deck
description	案件コンテキストと評価ルーブリックを読み込み、正解の型に沿って提案デッキの骨子を作り、proposal-evaluator サブエージェントの採点が合格(PASS)するまで「採点→修正」を自動で繰り返す。提案資料・提案デッキを新規に作る／作り直す／合格ラインまで仕上げたいときに使う。

提案デッキ作成ループ（骨子 → 採点 → 修正 → 合格）

案件コンテキストと評価ルーブリックを起点に、提案デッキを「正解の型」に沿って作り、独立した評価サブエージェントが PASS を出すまで自走で仕上げるスキル。

いつ使うか

• 新しい案件の提案デッキを骨子から作りたいとき
• 既存デッキを評価ルーブリックの合格ラインまで仕上げ直したいとき
• 「提案資料を作って」「提案デッキを合格まで仕上げて」等

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

• 評価ルーブリック: sales-proposal/standard/評価ルーブリック.md
• 正解の型: sales-proposal/standard/提案書の正解の型.md
• 案件コンテキスト: sales-proposal/proposals/<案件名>_提案コンテキスト.md
• 評価サブエージェント: proposal-evaluator（.claude/agents/proposal-evaluator.md）
• 出力先デッキ: sales-proposal/proposals/<案件名>_提案デッキ.md

手順

Step 0｜入力の確認

• どの案件か（案件コンテキストのファイル）を特定する。指定がなければ sales-proposal/proposals/ を見て確認する。
• 案件コンテキストが無い場合は、先に grill-me 等でコンテキストを作るよう促す（コンテキストなしで骨子を作らない）。

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

次の3つを精読する:

1. 評価ルーブリック（10軸の0〜3定義・マスト軸・合格ライン）
2. 正解の型（推奨スライド構成・各スライドの目的/中身/NG・枚数の考え方）
3. 案件コンテキスト（顧客の本当の願い・強み・決裁者の関心・数字・価格方針など）

ルーブリックの合格ラインを頭に入れてから骨子に入る。

Step 2｜骨子の作成

正解の型に沿って、デッキ骨子を Markdown で作成（sales-proposal/proposals/<案件名>_提案デッキ.md）。

• 1スライド＝「見出し＋太字キーメッセージ（13字目安・1主張）＋本文要素／図解指示」。
• 本編15枚程度。型の「実際に何ができる／どう解くか（⑥）」を複数枚に厚く、全体像（⑤）は軽く。
• すべて案件コンテキストの固有情報（顧客名・課題・願い・数字・強み）で具体化する。一般論で薄めない。
• コンテキストの方針（例: 価格の金額は資料に出さない）を厳守する。

Step 3｜評価（サブエージェント呼び出し）

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

• 採点対象デッキのパスと、対応する案件コンテキストのパスを渡す。
• 毎ラウンド「新規の独立採点」として呼ぶ（前ラウンドの点に引きずらせない）。
• もし proposal-evaluator がまだ登録されておらず呼べない場合は、general-purpose エージェントに同等の採点指示（ルーブリック＋コンテキスト照合・忖度なし・固定フォーマット）を与えて代替する。

Step 4｜修正

評価結果の「3点未満の軸の改善指示」に基づき、メイン（あなた）がデッキを修正する。

• マスト軸（#1 結論先出し / #6 信頼担保 / #7 ROI / #8 リスク / #10 次アクション）を最優先。
• コンテキストの方針に反する指摘（例: 金額を出せ）は、方針を守れる代替（料金体系・回収の時間軸・比率など）で満たし、必要ならコンテキストにも整合を反映する。
• デッキを直したら、整合のため案件コンテキスト側の補足設定値も必要に応じ更新する。

Step 5｜合格まで反復

Step 3 → Step 4 を、評価が PASS になるまで繰り返す。

• 合格ライン: 10軸すべて2点以上 ＋ 総合24/30以上 ＋ マスト軸に1点以下なし。
• 上限は 5ラウンド。超えても PASS しなければ、残課題と理由を率直に報告して止める（無限ループにしない）。

Step 6｜完了報告

• 点数の推移（Round 1 → 最終）をビフォーアフターで示す。
• 各ラウンドで何を直したかを簡潔に。
• 提出前チェック（評価対象外）として、※仮の実績・数値など入稿前に潰すべき点を必ず明記する。

原則

• コンテキストとルーブリックを読む前に骨子を書き始めない。
• 評価は必ず独立サブエージェントに任せる（自己採点で済ませない＝客観性の担保）。
• 顧客のニーズ充足（案件内容に合っているか）と、ルーブリック充足（基準を満たすか）の両方で合格させる。
• 仮データのまま「完成」と言わない。提出前の差し替えを必ず申し送る。