LaunchPad — idea → validated plan → buildable context
此技能重現了 LaunchPadAI 的代理管線，但無需其後端。您將依序扮演各個專業代理，將每個輸出寫入磁碟，並將先前的輸出提供給後續步驟使用。此管線的價值來自三個要素——即使縮減規模，也必須全部保留：
-
專業角色框架。 每個步驟都有一個獨特的角色和獨特的偏見（假設挑戰者是懷疑論者；機會映射者會橫向觀察替代品）。分步驟、以各自角色進行撰寫，會比一次混合的「分析這個點子」產生更銳利的成果。
-
證據為基礎。 研究步驟使用網路搜尋並引用網址。捏造的競爭對手、市場數字或融資輪次會破壞整個計畫的價值，因為後續所有階段都會繼承這些錯誤數據。如果無法進行搜尋或搜尋無果，請明確說明，並將數字標示為估計值。
-
脈絡連續性。 每個階段都會讀取先前階段的最終文件。PRD 必須反映驗證階段找到的人物誌和風險；架構必須實現 PRD 的 MVP 範圍，而不是一個通用的應用程式。
階段
| # | 階段 | 步驟 (→ = 依賴) | 最終文件 | 參考文件 |
|---|---|---|---|---|
| 0 | 探索 | 問題 → 假設 → 機會 → 簡報 | BRIEF.md | references/discovery.md |
| 1 | 驗證 | 市場、競爭者、可行性、人物誌（獨立） → 綜合 → 基準評分 | VALIDATION_REPORT.md、BENCHMARK.md、benchmark.json | references/validation.md |
| 2 | PRD | 需求、用戶故事（獨立） → 優先級排序、UX 流程 → PRD | PRD.md | references/prd.md |
| 3 | 編碼脈絡 | 架構、資料庫綱要（獨立） → 任務、規則檔案 → 封裝 | CODING_CONTEXT.md + 規則檔案 | references/coding-context.md |
僅讀取您正在執行階段的參考文件——每個文件都包含該階段每一步驟的角色和交付物規格。
開始使用
- 收集專案輸入。 您需要：專案名稱、原始點子（幾句話即可），以及選擇性的領域、目標受眾和創辦人背景（基準評分會評估創辦人-市場契合度——如果沒有背景資料，請保守評分並說明原因）。對任何遺漏但重要的部分請求一次，無需反覆盤問。
- 決定範圍。 預設：執行階段 0 → 1，然後暫停。如果使用者要求特定階段（例如「寫一個 PRD」），從那裡開始——但先檢查是否有先前階段的文件。如果沒有，要麼運行先前缺失階段的壓縮版本（請說明），要麼僅依據點子繼續進行，並在輸出中標記哪些輸入是假設而非研究得出的。
- 在目前目錄建立工作區（除非使用者指定其他位置）：
launchpad/<project-slug>/
00-discovery/ problem.md assumptions.md opportunity.md BRIEF.md
01-validation/ market-size.md competitors.md feasibility.md personas.md
VALIDATION_REPORT.md benchmark.json BENCHMARK.md
02-prd/ requirements.md user-stories.md prioritization.md ux-flows.md PRD.md
03-coding-context/ architecture.md schema.md tasks.md CLAUDE.md|.cursorrules CODING_CONTEXT.md
project.md name, idea, domain, audience, founder background, feedback log
首先撰寫 project.md。如果該專案的工作區已存在，則重複使用它——讀取現有內容並繼續，而不是重新開始。
執行步驟
每個步驟的提示概念上為：
專案：<名稱> 點子：<原始點子> 領域 / 受眾（若已知）
--- 先前階段脈絡 --- 先前階段的最終文件（見下文）
--- 先前步驟輸出 --- 此步驟依賴的先前步驟輸出
--- 用戶回饋 --- 在收到回饋後重新執行時
--- 您的任務 --- 來自參考文件的角色 + 交付物規格
先前階段脈絡（取代平台的 pgvector 檢索）：
- 驗證讀取
BRIEF.md。 - PRD 讀取
BRIEF.md、VALIDATION_REPORT.md、BENCHMARK.md和personas.md。 - 編碼脈絡讀取
PRD.md和feasibility.md，加上BRIEF.md以確定範圍。
每個輸出檔案開頭都有一個中繼資料標頭，接著是完整分析：
> **標題：** <唯一最重要的發現，以一個完整的特定句子表達——「所以呢」，而非主題>
>
> **關鍵要點**
> - <最重要的發現>
> - <第二重要>
> - <第三重要>（最多 5 個）
最終/綜合文件（BRIEF.md、VALIDATION_REPORT.md、PRD.md、CODING_CONTEXT.md）還需要在該標頭內加入 3-5 個指標的評分卡：
> | 指標 | 數值 | |
> |---|---|---|
> | 問題嚴重性 | 8/10 | 🟢 |
> | 競爭密度 | 高 | 🔴 |
（🟢 強/正面，🟡 中等/不確定，🔴 弱/令人擔憂。）此標頭的存在是為了讓瀏覽 20 份文件的讀者能在五秒內掌握每份文件的結論。
研究步驟（在參考文件中標記為 🔎）：執行幾個有針對性的網路搜尋——而非一個通用查詢——例如競爭對手名稱 + 定價、"<問題> reddit"、帶年份的市場報告。在行內引用為 [1]，並在結尾提供 ## 來源 的 URL 清單。
並行性。 標記為獨立的步驟，如果代理工具可用，可以作為並行子代理執行——為每個子代理提供專案輸入、先前階段脈絡檔案路徑、參考文件中的對應部分以及輸出路徑。否則，自行依序執行。無論採用哪種方式，綜合步驟只在其輸入準備就緒後執行，並且它們會讀取完整的檔案，而非摘要。
基準評分
在 VALIDATION_REPORT.md 之後，撰寫 benchmark.json（綱要見 references/validation.md），然後執行：
python3 <skill-dir>/scripts/benchmark_score.py launchpad/<slug>/01-validation/benchmark.json "<Project Name>"
它會使用固定的權重重新計算 overall_score（這樣分數在不同專案間具有可比性，而非隨意給分），重寫 JSON，並在旁邊寫入 BENCHMARK.md。評分時請保持校準：大多數點子落在 4-6 分以及第 40-65 百分位。一個所有項目都 8 分以上的基準評分，是過度樂觀而非分析的表現。
階段之間
每個階段結束後，暫停並在對話中給使用者一個簡短摘要：最終文件的標題、評分卡、裁定結果（驗證階段），以及最可能改變他們想法的 2-3 件事。然後詢問是要繼續、修改還是停止。未經要求，請不要自行完成全部四個階段——一個「需要重新思考」的裁定結果應該是一個真正的決策點，使用者可能希望在圍繞它撰寫 PRD 之前先調整點子。
如果使用者對某個階段給予回饋，將其附加到 project.md 的回饋日誌中，僅重新執行受影響的步驟以及該階段的綜合步驟（將回饋納入上下文），並覆寫那些檔案。
完成
當編碼脈絡完成時，告訴使用者要將哪些檔案複製到他們的新儲存庫中：CODING_CONTEXT.md 和規則檔案（CLAUDE.md 用於 Claude Code，.cursorrules 用於 Cursor，AGENTS.md 用於其他代理——如果不確定，請詢問他們使用哪個工具；預設為 CLAUDE.md），加上 tasks.md 作為建構待辦事項清單。