review-proposal

name	review-proposal
description	business-proposal / it-proposal / generic-proposal skill で作成された提案書・企画書を、構成・論理性/市場分析・競合克服戦略/ペルソナ適合性/根拠の明確性/エンゲージメント・リテンション設計/説得力・表現品質の6軸・100点満点で客観的に採点する。別エージェントを起動してレビューする（自己レビューしない）。「この提案書をレビューして」「企画書を採点して」等で使用。

/review-proposal — 提案書 品質レビュー（エージェント分離実行）

このスキルは別エージェントを起動してレビューを行う。現在のセッションでは直接レビューしない。 作成時の思考過程・設計判断・会話履歴をレビューエージェントに渡さないことで客観性を確保する。

対象: business-proposal / it-proposal / generic-proposal skill をもとに作成された提案書・企画書 目的: 「構成・論理性」「市場分析・競合克服戦略」「ペルソナ適合性」「根拠の明確性」「エンゲージメント・リテンション設計」「説得力・表現品質」の6軸で提案書品質を100点満点で評価する。

---

実行手順

ステップ1: 情報収集（この実装セッションで行う）

以下の事実情報のみを収集する。作成の意図・設計判断の説明は含めない。

収集対象:
1. レビュー対象の提案書・企画書の全文
2. 以下の「レビュー前の必須確認事項」が文書内または作成者からの回答で判明しているか
   - この提案書で最も伝えたいことは何か（主張・結論を1〜2文で言語化できるか）
   - 提案先（読者・意思決定者）は誰か（経営層・担当者・投資家など）
   - 読者がこの提案書を読んだ後に何を「決断する」か（求める行動が明示されているか）
   - どの skill で作成したか（business-proposal / it-proposal / generic-proposal）

上記が不明瞭な場合は、レビュー開始前に作成者へ確認すること。

ステップ2: レビューエージェント起動

Agent ツールを使い、以下の設定で別エージェントを起動する:

Agent ツールの設定:
- subagent_type: "general-purpose"
- description: "Review proposal document objectively"
- prompt: 以下のテンプレートに収集した情報を埋め込む

プロンプトテンプレート（レビューエージェントに渡す内容）:

あなたは作成者とは別の客観的な事業提案の専門家です。
以下の提案書・企画書を、6項目・合計100点で評価してください。

## 行動原則
`.claude/skills/_shared/review-rubrics.yaml` の `common_principles`（evidence_based / citation_required / non_destructive）を Read して適用すること。

## レビュー対象文書
[ここに対象提案書・企画書の全文を埋め込む]

## レビュー観点（6項目・合計100点）

### 1. 構成・論理性 【配点：15点】

> 目的：提案書全体の流れが論理的であり、読者が内容を追いやすい構成になっているかを確認する。

- [ ] エグゼクティブサマリー（要約・結論）が冒頭にある
- [ ] 課題の明示 → 解決策の提示 → 根拠・実績 → 実装計画 → 期待効果 の順序で展開されている
- [ ] 各セクションに明確な見出しがあり、読者がどこを読んでいるか把握できる
- [ ] 結論が冒頭と末尾の両方に記載されている（BLOT原則：Bottom Line On Top）
- [ ] セクション間の文脈的なつながりが明確（前後関係が分かる）
- [ ] 提案の規模・リスク・期待値が定量的に示されている

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | 論理的な構成で、結論が冒頭から明確、各セクションが有機的につながっている |
| 11〜13 | おおむね良好だが、一部セクションの順序または文脈的つながりに問題がある |
| 7〜10 | 構成が不明確で、読者が結論や主張を把握しにくい |
| 0〜6  | 論理的な流れがなく、提案書として機能しない |

### 2. 市場分析・競合克服戦略 【配点：20点】

> 目的：TAM/SAM/SOM分析が含まれ、事業・提案の実現可能性が客観的根拠とともに示されているかを確認する。加えて、競合に対する克服戦略の質を評価する。

市場規模分析チェック:
- [ ] TAM（全体市場規模）が数値で示されている
- [ ] SAM（実際にアプローチできる市場）が定義されている
- [ ] SOM（現実的に獲得できる市場）が示されている
- [ ] 市場規模の根拠（データソース・調査結果）が明記されている

実現可能性チェック:
- [ ] 実装に必要なリソース（人員・予算・期間）が具体的に示されている
- [ ] 主要なリスクと対策が記載されている
- [ ] 競合・代替手段との比較が含まれている
- [ ] 段階的な実装計画（フェーズ分け）がある
- [ ] 競合の強みに対するカウンター戦略が具体的に示されているか
- [ ] 競合の弱みを突く攻めのポジショニングが定義されているか
- [ ] 競争優位の持続性（モート：ネットワーク効果・スイッチングコスト・データ蓄積・ブランド等）が分析されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | TAM/SAM/SOM分析が揃い、リソース・リスク・競合比較がすべて含まれている |
| 14〜17 | 市場分析は含まれるが、TAM/SAM/SOMの一部が欠けるか根拠が不十分 |
| 10〜13 | 市場分析が表面的で、実現可能性の根拠が乏しい |
| 0〜9  | 市場分析・実現可能性の記述がほぼなく、信頼性に問題がある |

### 3. ペルソナ・読者適合性 【配点：15点】

> 目的：提案書の内容・語彙・説明レベルが、想定する意思決定者・読者に最適化されているかを確認する。

- [ ] ペルソナ分析（意思決定者の課題・ニーズ・懸念点）が含まれているか
- [ ] 提案の内容が、ペルソナの業務上の痛みに直接応えているか
- [ ] 専門用語に対して適切な解説が付いているか（読者リテラシーに合わせた説明）
- [ ] 読者が「自分事」として捉えられるような具体例・事例があるか
- [ ] 意思決定者が懸念しそうな反論への先回り（Q&A・FAQ等）があるか
- [ ] 提案の緊急性・重要性が読者の視点で語られているか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | ペルソナ分析に基づき、読者の課題・懸念点に的確に応えている |
| 11〜13 | おおむね適切だが、一部でペルソナとのズレまたは反論への対応が不足 |
| 7〜10 | 読者への配慮が不足しており、誰向けか不明確な部分がある |
| 0〜6  | ペルソナへの適合がほぼなく、一方的な情報提供になっている |

### 4. 根拠の明確性 【配点：15点】

> 目的：主張・数値・結論が客観的な根拠に基づいており、読者が独立して評価・検証できる記述になっているかを確認する。

- [ ] 主張・推奨・結論に明確な根拠（データ・実績・文献・調査）が示されているか
- [ ] 数値・統計・効果予測に出典または測定方法が明記されているか
- [ ] 「〜と考えられる」「〜を見込む」など、確証のない推測に適切な言及があるか
- [ ] 事実として断定している記述と、著者の見解・推測が区別されているか
- [ ] 反論・リスク・制約条件が公平に取り上げられているか
- [ ] 読者が「自分の環境でも試せる」または「独自に検証できる」情報があるか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | 根拠・反論・限界が明示され、読者が独立して判断できる |
| 11〜13 | おおむね合理的だが、一部で根拠不足または誘導的な記述がある |
| 7〜10 | 根拠が薄く、主観的な主張が目立つ |
| 0〜6  | 根拠がほぼなく、客観的評価が困難 |

### 5. エンゲージメント・リテンション設計 【配点：20点】

> 目的：提案されたサービス・プロダクトに、ユーザーが継続的に利用し離脱しにくくなる仕組みが設計されているかを確認する。行動科学に基づいたエンゲージメント戦略の有無と質を評価する。

習慣形成・行動設計チェック:
- [ ] 習慣ループ（トリガー→アクション→報酬→投資）が設計されているか
- [ ] 報酬設計（達成感・社会的承認・自己実現・金銭的リターン等の変動報酬）が具体的か
- [ ] 投資設計（ユーザーがサービスに蓄積する価値）により離脱障壁が構築されているか
- [ ] 行動経済学の原理（損失回避・社会的証明・進捗効果・ピーク・エンドの法則等）が活用されているか

リテンション戦略チェック:
- [ ] ネットワーク効果の仕組み（ユーザー増加に伴う価値向上）が示されているか
- [ ] スイッチングコスト（データロックイン・コミュニティ・エコシステム統合）が設計されているか
- [ ] ゲーミフィケーション要素（ストリーク・バッジ・レベル・進捗バー等）が検討されているか
- [ ] リテンション指標（DAU/MAU・継続率・チャーン率等）と改善サイクルが計画されているか
- [ ] ユーザーライフサイクル別のエンゲージメント施策が設計されているか
- [ ] 提案書の読者（意思決定者）に対して、リテンション設計のROIが説明されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | 習慣ループ・報酬設計・ネットワーク効果・リテンション指標がすべて含まれ、行動科学の根拠と共に説明されている |
| 14〜17 | おおむね設計されているが、一部（報酬設計やリテンション指標等）が不十分 |
| 10〜13 | エンゲージメント設計が表面的で、具体的な行動科学の根拠や指標が欠けている |
| 0〜9  | エンゲージメント・リテンション設計がほぼなく、ユーザー継続利用の仕組みが不明 |

### 6. 説得力・表現品質 【配点：15点】

> 目的：提案書が読者を動かす説得力を持ち、文章・構成・ビジュアル要素が高品質かを確認する。

- [ ] タイトル・見出しが提案の本質を一言で表現しているか
- [ ] CTA（行動促進）が明確に記載されている（「〜を承認してください」「〜を採用してください」等）
- [ ] 数字・データが視覚的に強調されている（表・グラフ・太字等）
- [ ] 文章が簡潔で、冗長な記述や不要な修飾語がないか
- [ ] 提案全体を通じて一貫したトーン・スタイルが維持されているか
- [ ] 読者が読了後に「次のアクション」を明確にイメージできるか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | 説得力が高く、CTAが明確、全体を通じて品質が一貫している |
| 11〜13 | おおむね説得力があるが、一部でCTAが弱いまたは表現の冗長さがある |
| 7〜10 | 説得力が弱く、読者が次のアクションをイメージしにくい |
| 0〜6  | 説得力が不足しており、提案書として機能しない |

## 採点方法（総合点：100点満点）

`.claude/skills/_shared/review-rubrics.yaml` を Read し、`verdict_scales.rank5_100` の bands/meaning に従って S/A/B/C/D を判定すること（点数帯・各段階の対応方針は同ファイルが SoT）。

## 出力（レビュー結果出力フォーマット）

```markdown
# 提案書 レビュー結果

## 基本情報
- 提案書タイトル：
- レビュー日：
- 提案先（意思決定者・読者）：
- 提案書の目的・求める行動：
- 使用skill（business-proposal / it-proposal / generic-proposal）：

## 総合評価
- **総合点：XX点 / 100点**
- **判定：X（S/A/B/C/D）**

## 観点別採点

| # | 観点 | 配点 | 得点 | 主なコメント |
|---|------|------|------|-------------|
| 1 | 構成・論理性 | 15 | | |
| 2 | 市場分析・競合克服戦略 | 20 | | |
| 3 | ペルソナ・読者適合性 | 15 | | |
| 4 | 根拠の明確性 | 15 | | |
| 5 | エンゲージメント・リテンション設計 | 20 | | |
| 6 | 説得力・表現品質 | 15 | | |

## 良かった点（Keep）

## 改善提案（Problem / Try）

## 具体的な修正が必要な箇所

| セクション | 現在の記述 | 問題点 | 修正案 |
|-----------|------------|--------|--------|
| | | | |

## 市場分析チェック

| 項目 | 記載 | コメント |
|------|------|----------|
| TAM（全体市場規模） | ✅ / ❌ | |
| SAM（アプローチ可能市場） | ✅ / ❌ | |
| SOM（獲得可能市場） | ✅ / ❌ | |
| リスクと対策 | ✅ / ❌ | |
| 競合比較 | ✅ / ❌ | |
| エンゲージメント・リテンション設計 | ✅ / ❌ | |
| 習慣ループ設計 | ✅ / ❌ | |
| ネットワーク効果 | ✅ / ❌ | |
| CTA（行動促進） | ✅ / ❌ | |

## 補足コメント

### ステップ3: 結果の報告

レビューエージェントから返却された結果を、そのままユーザーに表示する。
要約や解釈を加えない（レビューの客観性を維持するため）。

---

## 注意事項

- **絶対に実装セッション内で直接レビューしない**。必ず Agent ツールで別エージェントを起動すること
- レビュワーは元ファイルを絶対に編集してはならない。改善点は具体的に指摘し、修正案は「提案」として記載する
- 上記「レビュー前の必須確認事項」が文書から読み取れない場合は、作成者へ確認する

## 参照ドキュメント

- 元プロンプト（詳細確認用）: `workflows/business-planning/review-proposal.md`
- 前ステップ（提案書作成）: `business-proposal` / `it-proposal` / `generic-proposal` skill
- 次ステップ（技術仕様書化）: `specification` skill