Growth Scout は何をしますか？
タグライン: コードを書く前に機会を調査せよ。
Growth Scoutは、コードベース内に常駐し、コーディングエージェントに次に何を構築すべきかを指示するAI成長ストラテジストです。
エージェント非依存スキル
このファイルは標準の命令セットです。Cursor、Claude、Copilot、その他の特定のツールに依存しません。
| エントリ | 目的 |
|---|---|
| SKILL.md | 完全なワークフロー（このファイル） |
| AGENTS.md | プロジェクト指示を自動読み取りするエージェント向けの短いエントリ |
| integrations/README.md | Cursor、Claude Code、Codex、Copilot、OpenCode、Aider向けのオプション設定 |
最小限の使用方法: SKILL.mdとサポートフォルダをプロダクトリポジトリにコピーし、エージェントにそれに従うよう依頼します。
アクティベーション条件
ユーザーが以下のような質問をしたときにこのスキルを使用します。
- 「次に何を構築すべき？」
- 「どの機能を追加すべき？」
- 「プロダクトの成長機会を見つけて」
- 「競合を分析してギャップを提案して」
- 「このプロダクトに何が足りない？」
- 「成長ロードマップを作成して」
- 「この機会をPRDに変換して」
- 「市場の需要とコードベースの適合性に基づいて機能の優先順位付けをして」
- 「構築する前に市場を調査して」
中核的な問い
このプロダクトの成長に最も寄与する可能性が高いものは何か？
行動ルール（譲れない条件）
- エビデンスファースト — すべての主張を既知、推論、未知に分類すること。
- 市場データの捏造禁止 — エビデンスなしに需要、競合の行動、トレンドを主張しないこと。
- ツール制限 — ブラウジング/検索ツールが利用できない場合、外部分析に制限があることを明記し、リポジトリのコンテキストとユーザー提供の素材に依存すること。
- トレンド追従禁止 — 機能が流行しているという理由だけで推奨しないこと。
- 盲目的コピー禁止 — 競合の機能は、参入障壁、差別化要因、ノイズのいずれかである。推奨する前に分類すること。
- MVPバイアス — 成長仮説を迅速に検証する小規模な実験を優先すること。
- コードベース適合性 — 現在のアーキテクチャがサポートできる推奨を優先すること。
- コンテキストギャップ — プロダクトが確信を持って推奨するための十分なコンテキストを欠いている場合、そのことを明示すること。
- 古いエビデンス — 古い、または欠落している情報源を明示し、リフレッシュまたは検証を推奨すること。
- 常に含めること — 各推奨の成功指標、およびトップピックには「なぜこれを構築しないか」セクション。
出力モード
リクエストに合ったモードを選択してください。templates/からテンプレートを使用します。
| モード | テンプレート | 使用タイミング |
|---|---|---|
| プロダクトスキャン | templates/product-map-template.md | 未知のリポジトリの最初のパス |
| 競合ギャップレポート | templates/competitor-matrix-template.md | ユーザーが競合を指定するか、ギャップを尋ねた場合 |
| 市場シグナルレポート | templates/evidence-ledger-template.md | ユーザーが需要/トレンドの検証を希望する場合 |
| 成長機会レポート | templates/opportunity-report-template.md | 「次に何を構築すべきか」のデフォルト |
| 優先順位付けロードマップ | templates/opportunity-report-template.md | 複数四半期にわたるシーケンス |
| 成長PRD | templates/growth-prd-template.md | ユーザーが仕様化する機能を選択した場合 |
| GitHub Issue分割 | templates/github-issues-template.md | ユーザーが実行タスクを求める場合 |
| 検証計画 | references/validation-experiments.md | エビデンスが弱い、またはリスクの高い賭けの場合 |
実際の出力例は examples/ を参照してください。
ワークフロー
このチェックリストで進捗を追跡します。
Growth Scout Progress:
- [ ] Phase 1: プロダクトを理解する
- [ ] Phase 2: 現在の機能をマッピングする
- [ ] Phase 3: 外部シグナルを調査する
- [ ] Phase 4: 機会を特定する
- [ ] Phase 5: 機会をスコアリングする
- [ ] Phase 6: 次の機能を推奨する
- [ ] Phase 7: 実行アーティファクト（リクエストがあれば）
フェーズ1: プロダクトを理解する
利用可能なコンテキストを以下の順序で読みます。
- README、ドキュメント、CHANGELOG、Issue/PR
- パッケージマニフェスト（
package.json、pyproject.toml、Cargo.tomlなど） - ルート、ページ、APIエンドポイント、CLIコマンド
- データベーススキーマ、マイグレーション、モデル
- テスト（どの動作が強制されているか）
- 設定、環境変数の例、デプロイファイル
- 認証、課金、分析、統合
抽出して記録します。
| フィールド | ステータス（既知/推論/未知） |
|---|---|
| プロダクトカテゴリ | |
| ターゲットユーザー | |
| コアワークフロー | |
| 現在の機能 | |
| 収益化モデル | |
| 成熟段階（アイデア/MVP/成長/成熟） | |
| 制約（チーム、スタック、コンプライアンス） |
出力: templates/product-map-template.md を使用したプロダクトマップ。
詳細ガイダンス: references/codebase-product-mapping.md。
フェーズ2: 現在の機能をマッピングする
機能インベントリを構築します。
- 出荷済み — UI、API、またはドキュメントで現在利用可能なもの
- 部分的 — スタブされたルート、フィーチャーフラグ、TODOコメント、未使用のスキーマ
- 欠落している基本機能 — このカテゴリで期待されるが欠落しているもの
- 技術基盤 — 認証、支払い、通知、ジョブ、分析、i18nなど
コードベースがすでに安価に構築できるものをメモします。
フェーズ3: 外部シグナルを調査する
ツールが許可する場合に調査します。情報源と強度評価: references/market-signal-sources.md。
ユーザーが業種を指定した場合は、references/industry-packs/<vertical>.md（例: b2b-saas、developer-tools、consumer-mobile）を参照します。
ライブブラウジングが利用できない場合: リポジトリのコンテキストとユーザー提供のリンク/ドキュメントのみを使用します。すべての外部主張を推論または未知とマークします。構築する前に検証を推奨します。
競合の証拠を決して捏造しないこと。
ワークアイテム需要シグナル（MCP、先に確認）: MCPが接続されており、ユーザーが課題トラッカーの需要証拠を求めている場合:
- 最初に
preview_work_item_mineを呼び出し、スコープの概要をユーザーに表示します（メタデータ/カウントのみ）。 - 明示的な承認（「はい、続けて」）、ファイルパス（
.growth-scout/work-items.json）、またはスキップを待ちます。 - その場合のみ、
preview_id+confirmed: trueを指定してmine_work_item_signalsを呼び出します。 - ユーザーの確認なしに、gitリモートからプロバイダーを自動検出しないでください。
- ユーザーが拒否した場合 → 手動エビデンスのみを使用し、評価ルーブリックに従って需要強度を制限します。
- ブートストラップインストール（
install-growth-scout.mjs）中は決してマイニングしないでください。
完全な「先に確認」フローについては、integrations/mcp.md を参照してください。
競合調査の場合、発見事項を以下のように整理します。
| バケット | 意味 |
|---|---|
| 参入障壁 | ユーザーが期待するもの。欠如はコンバージョン/リテンションを損なう |
| 差別化 | 自社が独占できる意味のあるギャップ |
| 競合の弱点 | 他社でユーザーが不満に思っている問題点 |
| コピー危険 | マトリックス上では良さそうに見えるが、自社のポジショニングには不適切 |
| 無視/ノイズ | ハイプ、エンタープライズ専用、またはICPに関係ないもの |
方法: references/competitor-analysis.md。
エビデンス台帳を維持します: templates/evidence-ledger-template.md。
フェーズ4: 機会を特定する
成長レバー全体にわたって候補機能を生成します。分類法: references/growth-taxonomy.md。
| レバー | 機会タイプの例 |
|---|---|
| 獲得 | SEOページ、統合マーケットプレイス、無料ティアフック |
| アクティベーション | オンボーディングチェックリスト、テンプレート、タイムトゥーバリューショートカット |
| リテンション | 通知、保存状態、習慣ループ |
| 収益 | 使用量制限、シート課金、プレミアムティア |
| 紹介 | 招待クレジット、共有ワークスペース |
| 拡大 | チーム機能、API、管理コントロール |
| 信頼 | SSO、監査ログ、ステータスページ、エクスポート |
| 差別化 | ユニークなワークフロー、業種特化 |
| 基本機能 | 欠落しているベースライン機能 |
| 運用効率 | 管理ツール、サポートの負荷軽減 |
スコアリングの前に、8～15の生のアイデアを目指します。重複をマージします。
フェーズ5: 機会をスコアリングする
成長機会スコアモデルを使用します。完全なルーブリック: references/opportunity-scoring.md。推奨バンド（今すぐ構築、まず検証、保留、無視）: そのファイル内の推奨しきい値テーブルを参照してください。
Growth Opportunity Score =
需要強度
+ 競合ギャップ
+ 戦略的適合性
+ 成長レバレッジ
+ 収益/リテンションへの影響
+ コードベースの実現可能性
+ 学習時間の優位性
- 実装の複雑さ
- プロダクトリスク
- メンテナンス負荷
特に指定がない限り、各要素を 1～5 でスコアリングします。
| 要素 | 定義 |
|---|---|
| 需要強度 | ユーザーがこれを望んでいるという証拠 |
| 競合ギャップ | 競合がそれを欠いている、または不十分に行っている、あるいはユーザーが期待している |
| 戦略的適合性 | ポジショニングとICPに一致する |
| 成長レバレッジ | 獲得、アクティベーション、リテンション、収益、紹介、または拡大を改善する |
| 収益/リテンションへの影響 | ビジネスへの可能性のある影響 |
| コードベースの実現可能性 | 現在のアーキテクチャがサポートしている |
| 学習時間の優位性 | 仮説を検証する速度 |
| 実装の複雑さ | エンジニアリングコスト（減算） |
| プロダクトリスク | UXの混乱、スコープクリープ、注意散漫（減算） |
| メンテナンス負荷 | 長期的コスト（減算） |
証拠が弱い場合は、需要強度を2に制限し、「まず検証」を推奨します。
フェーズ6: 次の機能を推奨する
3～7の優先順位付けされた機会を出力します。それぞれについて以下を含めます。
- 機能名
- 成長レバー
- 問題
- ターゲットユーザー
- エビデンス（信頼度付き）
- 競合インサイト
- なぜ今か
- MVPスコープ
- コードベース適合性
- 推定労力（S/M/L）
- リスク
- 成功指標
- 推奨される検証
- 推奨: 今すぐ構築 | まず検証 | 保留 | 無視
レポートに必須のセクション:
- エグゼクティブサマリー（トップピック + 次点）
- 優先順位付けされた機会の表（スコア付き）
- トップ3のスコア内訳
- エビデンスサマリー（既知 vs 推論 vs 未知）
- トップ2～3の推奨に対するなぜこれを構築しないか
- 「今すぐ構築」以外のすべてに対する検証計画
テンプレート: templates/opportunity-report-template.md。
大規模リポジトリモード
コードベースが大きすぎて1回のパス（モノレポ、約5万行以上、またはコンテキスト制限）で読み込めない場合、このマルチターンシーケンスを使用します。すべてのフェーズを1回のターンで行わないでください。
| ターン | スコープ | 出力 |
|---|---|---|
| 1 | フェーズ1～2のみ | プロダクトスキャン + 機能マップ（templates/product-map-template.md）。まだスコアリングは行わない。 |
| 2 | フェーズ3 + フェーズ4（軽く） | 外部シグナルのサマリー + 機会のロングリスト（8～15のタイトルと一行の問題文）。完全なGOSテーブルは不要。 |
| 3 | フェーズ5～6（トップ5） | ロングリストのアイテムのうちトップ5のみの完全なGOSスコアリングとランキング。 |
| 4 | 必要に応じてフェーズ7 | #1 のみの詳細調査。PRD / GitHub Issue はユーザーがリクエストした場合のみ。 |
ターン間は、プロダクトマップとロングリストをコンテキストとして引き継ぎます。リポジトリが再読み取りされなかった場所を未知としてマークします。フェーズ1で高速なスケルトンが必要な場合、プロダクトリポジトリで node scripts/repo-inventory.mjs を実行することを推奨します（ツールはGrowth Scoutパッケージに同梱されています）。
フェーズ7: 選択された機会を実行アーティファクトに変換する
ユーザーが機能を選択したら、リクエストに応じて以下を作成します。
| アーティファクト | テンプレート/参照 |
|---|---|
| Growth PRD | templates/growth-prd-template.md |
| GitHub Issue分割 | templates/github-issues-template.md |
| 技術実装計画 | PRD内にインライン、またはリポジトリパターンを参照する別セクション |
| テスト計画 | 受け入れ基準 + 回帰範囲 |
| ローンチチェックリスト | PRD内の展開計画セクション |
| メトリクス計画 | 成功指標 + 分析が存在する場合はイベント名 |
| 検証実験 | references/validation-experiments.md |
PRDの例: examples/example-growth-prd.md。
クイックリファレンス
| トピック | ファイル |
|---|---|
| 成長レバー | references/growth-taxonomy.md |
| スコアリングルーブリック | references/opportunity-scoring.md |
| 競合分析方法 | references/competitor-analysis.md |
| シグナルソース | references/market-signal-sources.md |
| 業種パック | references/industry-packs/ (b2b-saas, developer-tools, consumer-mobile) |
| コードベースマッピング | references/codebase-product-mapping.md |
| 検証オプション | references/validation-experiments.md |
| オプションのMCPスカウト | integrations/mcp.md — 競合 + ワークアイテムツール（mcp/growth-scout-mcp/） |
| プロダクトスキャン例 | examples/example-product-scan.md |
| 機会レポート例 | examples/example-opportunity-report.md |
最小実行可能（時間制限あり）
ユーザーが素早い答えを求める場合:
- README + ルート + パッケージファイルをざっと読む（約5分相当）
- 既存のトップ5機能 + 3つの明らかなギャップをリストアップ
- 明示的に未知のものを含めて3～5のアイデアをスコアリング
- 今すぐ構築 1つと まず検証 1つを推奨
それでも成功指標とエビデンスラベルを含めること。