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 議題拆解 | templates/github-issues-template.md | 使用者想要執行任務時 |
| 驗證計劃 | references/validation-experiments.md | 證據薄弱或高風險的賭注 |
請參閱 examples/ 中的實際輸出範例。
工作流程
使用此檢查清單追蹤進度：
Growth Scout 進度：
- [ ] 階段 1：了解產品
- [ ] 階段 2：盤點當前能力
- [ ] 階段 3：探索外部訊號
- [ ] 階段 4：識別機會
- [ ] 階段 5：評分機會
- [ ] 階段 6：推薦下一個功能
- [ ] 階段 7：執行產出（如有要求）
階段 1：了解產品
按順序閱讀可用的上下文：
- README、文件、變更記錄、議題/PR
- 套件清單（
package.json、pyproject.toml、Cargo.toml等） - 路由、頁面、API 端點、CLI 指令
- 資料庫模式、遷移、模型
- 測試（強制了哪些行為）
- 設定檔、環境變數範例、部署檔案
- 驗證、計費、分析、整合
提取並記錄：
| 欄位 | 狀態（已知/推斷/未知） |
|---|---|
| 產品類別 | |
| 目標使用者 | |
| 核心工作流程 | |
| 目前功能 | |
| 營利模式 | |
| 成熟度階段（構想/MVP/成長/成熟） | |
| 限制（團隊、技術棧、合規性） |
輸出： 使用 templates/product-map-template.md 的產品地圖。
深入指南：references/codebase-product-mapping.md。
階段 2：盤點當前能力
建立功能清單：
- 已推出 — 目前在 UI、API 或文件中可用的功能
- 部分完成 — 存根路由、功能標誌、TODO 註解、未使用的架構
- 缺少入門必備功能 — 該類別預計有但缺失的功能
- 技術基礎設施 — 驗證、付款、通知、作業、分析、國際化等
記錄程式碼庫已讓哪些功能易於建置。
階段 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）或跳過。 - 只有這樣才能呼叫
mine_work_item_signals，並帶上preview_id+confirmed: true。 - 未經使用者確認，切勿從 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。推薦區間（立即建置、先驗證、擱置、忽略）：請參閱該檔案中的建議門檻表格。
成長機會評分 =
需求強度
+ 競爭對手差距
+ 策略契合度
+ 成長槓桿
+ 營收/留存影響
+ 程式碼庫可行性
+ 學習時間優勢
- 實作複雜度
- 產品風險
- 維護負擔
除非使用者另有指定，否則每個因素評分 1–5。
| 因素 | 定義 |
|---|---|
| 需求強度 | 有證據顯示使用者想要這個 |
| 競爭對手差距 | 競爭對手缺乏、做得不好，或使用者期望這個 |
| 策略契合度 | 符合定位和 ICP |
| 成長槓桿 | 改善獲取、啟用、留存、營收、推薦或擴展 |
| 營收/留存影響 | 可能的業務影響 |
| 程式碼庫可行性 | 當前架構支援此功能 |
| 學習時間優勢 | 驗證假說的速度 |
| 實作複雜度 | 工程成本（減去） |
| 產品風險 | UX 混淆、範圍蔓延、分心（減去） |
| 維護負擔 | 長期成本（減去） |
當證據薄弱時，將需求強度上限設為 2，並建議先驗證。
階段 6：推薦下一個功能
輸出 3–7 個排名機會。每個機會包含：
- 功能名稱
- 成長槓桿
- 問題
- 目標使用者
- 證據（含信心度）
- 競爭對手洞察
- 為什麼是現在
- MVP 範圍
- 程式碼庫契合度
- 估計工作量（小/中/大）
- 風險
- 成功指標
- 建議的驗證方式
- 建議： 立即建置 | 先驗證 | 擱置 | 忽略
報告中必備的章節：
- 執行摘要（首選 + 次選）
- 排名機會表格與分數
- 前 3 名的分數細項
- 證據摘要（已知 vs 推斷 vs 未知）
- 針對前 2–3 個推薦項目的為什麼不建這個
- 針對非「立即建置」項目的驗證計劃
範本：templates/opportunity-report-template.md。
大型儲存庫模式
當程式碼庫過大無法一次讀取時（單體儲存庫、超過約 5 萬行程式碼、或上下文限制），請使用此多輪順序。不要嘗試在單輪中完成所有階段。
| 輪次 | 範圍 | 輸出 |
|---|---|---|
| 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 議題。 |
在輪次之間，保留產品地圖和長列表作為上下文。標記未知（該儲存庫未重新讀取的部分）。當階段 1 需要快速骨架時，建議在產品儲存庫上執行 node scripts/repo-inventory.mjs（該工具隨 Growth Scout 套件提供）。
階段 7：將選定的機會轉變為執行產出
當使用者選擇一個功能時，按需產生：
| 產出 | 範本 / 參考 |
|---|---|
| 成長 PRD | templates/growth-prd-template.md |
| GitHub 議題拆解 | 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 個構想進行評分，並明確標示未知項
- 推薦一個立即建置和一個先驗證
仍然包含成功指標和證據標籤。