pitch-deck-reviewer

ピッチデックレビュアー

VCレベルの厳密さでピッチデックをレビューし、採点済みで実行可能な pitch-review.md を作成します。

目次

• references/evaluation-framework.md -- 採点対象となる8つの評価軸、配点、危険信号、採点ガイド、デザイン上の注意点、総合スコアの算出方法。
• references/objections-and-benchmarks.md -- 投資家からの質問のカテゴリと、成功したデックの代表的なベンチマーク。
• references/output-template.md -- 生成する pitch-review.md の正確な構成。

ワークフロー

1. デックを取り込みます。ファイルの種類と場所を確認し、すべてのスライドを読みます。対応する入力形式：PDF（直接読み取ります。10ページ以上の場合は pages パラメーターを使って分割して読み取ります）、PowerPoint .pptx（pptx スキルを呼び出すか、Read を使います）、Google Slides のリンク（公開されている場合は WebFetch）、画像 PNG/JPG（Read で目視確認）、Markdown／テキスト形式の説明、スライド画像のディレクトリ（Glob で列挙してから、それぞれを Read で読み取ります）。.pen ファイルは直接読み取れないことを明記します。
2. スライドの一覧を作成します。分析を始める前に、スライドごとに番号と主な内容を記録します。会社名、ステージ、業界を特定します。20枚を超えるデックは、それ自体を懸念点として指摘します。成功しているデックの多くは10～15枚です。
3. 8つの評価軸を採点します。references/evaluation-framework.md を適用します。それぞれの評価軸を、デックの具体的な根拠を示して1～10点で採点し、加重総合スコアを算出してグレードを割り当てます。
4. スライドごとのフィードバックを記載します。各スライドについて、内容の概要、目的、効果、強み、弱み、改善案を説明します。
5. 投資家からの質問を予測します。references/objections-and-benchmarks.md のカテゴリを使い、深刻度、きっかけとなる内容、推奨する口頭での回答、デックの修正案をそれぞれ含め、少なくとも5つ作成します。
6. ベンチマークとなるデックと比較します。references/objections-and-benchmarks.md にある関連デックを少なくとも2つ取り上げ、このデックが優れている点、劣っている点、参考にすべき点を示します。
7. 効果の大きい改善案を上位5つまで順位付けし、このステージと業界に必要な未掲載のスライドやセクションを列挙します。
8. references/output-template.md に従って pitch-review.md を作成します。最後にエグゼクティブサマリーを書きます。元のデックと同じ場所（または作業ディレクトリ）に保存します。総合スコアの計算式を示します。

採点基準

• 市場規模、売上、成長に関する主張は、受け入れる前に WebSearch で検証します。指標、比較、統計を決して捏造しません。
• ある評価軸で9～10点を付けるのは、新たな基準を打ち立てるレベルの成果に限ります。デックに利用可能な内容がほとんどない場合を除き、総合スコアを3.0未満にしません。
• ステージに応じて調整します。プロダクト前のデックでは、課題／ソリューションの明確さ、チーム、市場を重視し、トラクションや財務面への期待値を下げ、その調整内容を記載します。
• 財務情報やチーム情報など、重要なセクションが欠けている場合は1～2点を付け、エグゼクティブサマリーと不足セクションの一覧で指摘します。作成途中のデックもレビューし、レビューを拒否しません。
• メモ形式、デモ先行、1ページ形式など、意図的に慣例にとらわれないデックは、その形式に即して評価しつつ、一般的な形式との違いを記載します。
• 複数のバージョンがある場合は最新のものをレビューし、どの変更が改善につながり、どの変更が後退につながったかを記載します。

文体

• 率直かつ具体的に書きます。曖昧な称賛は、具体的な観察内容に置き換えます。
• 批判には必ず具体的な改善策を添えます。
• 断定的な評価（「これは悪い」）ではなく、投資家の視点（「この点から、次の疑問が生じます……」）で表現します。
• 改善点を挙げる前に、機能している点を認めます。使用する専門用語は定義します。
• 創業者がデックを改善できるように書きます。