sakzgupzzz/idea-check

idea-check 是做什麼的？

對一個點子進行端到端研究，產出情勢報告。不要回傳該點子是否可行的結論。回傳證據，以及該點子能夠存活的條件。

啟動前

用一段話重述你所理解的點子，並告知用戶你正在開始研究。不需要等待確認；重述內容也會放入報告中，這樣用戶無論如何都能發現誤讀。只有在模糊性會改變你研究的市場時，才先問一個問題（例如「AI for lawyers」可能指合約審查或訴訟 discovery，兩者的現有巨頭和失敗案例不同）。

選擇實體類型：軟體產品、硬體產品、服務、研究方向或內容。這會改變哪些來源重要。軟體依賴套件註冊表和 GitHub；硬體依賴專利；服務依賴當地市場和勞動力數據；研究依賴論文和 preprint。

然後檢查先前的執行。列出技能目錄中的 checks/，並閱讀任何主題看起來相關的檔案的前端資料。如果先前的檢查涵蓋重疊領域，請提前說明並指出檔案名稱，然後與用戶一起決定是要執行全新研究還是擴展先前的報告。重複執行你已經執行過的檢查是這個工作流程中最常見的浪費。

在 scratchpad 中為此次執行建立一個筆記目錄。每個執行緒將發現寫入其中，以便綜合環節能夠基於檔案而不是記憶中的四個長子代理回覆來運作。

四個執行緒

在單一訊息中，使用通用類型的 Agent 工具，以四個平行子代理啟動所有執行緒。每個執行緒都需要網路搜尋和擷取功能。這個分解是固定的。不要替換你自己的、合併執行緒，或增加第五個。每個執行緒的完整提示位於 references/thread-prompts.md；讀取該檔案，並按原樣使用範本，替換點子、實體類型和筆記路徑。

1. 既有技術

誰已經在推出這個產品。已發布定價的商業產品、附星號、授權與最後提交日期的 GitHub 儲存庫、學術成果、專利。對於每個佔有者，說明它與點子的接近程度以及它未涵蓋的內容。缺口比列表更有用。

2. 相鄰巨頭

哪些已建立的類別已經將此作為一項功能提供，以及如果它成功，誰會將它吸收。這比直接競爭對手更重要。這個領域的產品更常因為巨頭從上方將功能捆綁而消亡，而不是因為新創公司正面競爭。指出最有可能的吸納者。

3. 失敗案例與經濟學

這裡已經嘗試過什麼並且失敗了：倒閉、低價收購、轉型、裁員、相鄰上市公司衰落。然後誰是買家，他們實際支付多少，以及該區隔是否能夠支付。對商業案例持敵對態度。一個被指示尋找競爭對手的執行緒永遠不會找到失敗案例，這就是為什麼這是分開的。

4. 商品化底線

這裡面有多少已經是免費或捆綁的：前沿模型能力、開源軟體、用戶已擁有的訂閱中的功能。如果一個具備網路搜尋能力的勝任模型可以免費做到 80%，請說明並指出剩餘的差異，因為這個差異是唯一可銷售的東西。

強制性的子代理指令

每個執行緒提示都必須逐字包含以下區塊。它已經在範本中；替換時不要刪減它。

• “假設既有技術存在並積極尋找它。你的工作是找出誰佔據了這個空間，而不是確認它是空的。報告誰佔據了這個空間，要直言不諱。”
• “在你什麼都沒找到的地方，寫‘沒找到，這不等於不存在’，並列出你沒有檢查的內容。”
• “每個事實性陳述都需要來源 URL。”
• “從所有事實性陳述中排除 AI 生成的列表文章、‘2026 最佳工具’彙整頁面、程式化定價網站以及聯合市場規模販賣者。說出你丟棄的來源。這個領域大約三分之一的搜尋結果是供應商為了 SEO 互相撰寫的內容；將該數量報告為一項發現，但不要引用它。”
• “在每項發現中區分供應商宣稱與獨立證據。”

第一行是這個技能中價值最高的行。將研究任務導向確認而不是證偽，會使結論在已發表的測量中偏移 34 到 66 個百分點。這使得框架設定成為正確性的要求，而不是語氣偏好。一個被告知檢查空間是否為空的執行緒將會報告它為空。

“沒找到”這個用語之所以存在，是因為缺乏證據在這裡是薄弱的。小型競爭者和已倒閉的公司索引都不佳。列出未檢查的內容讓讀者可以判斷這種沉默有多少意義。

綜合

當四個執行緒都回傳時，讀取它們的筆記檔案。然後做兩件事。

三次獨立的情勢判讀

將情勢標記為「開放」、「擁擠」或「飽和」。獨立產生該標籤三次，並確保判讀實際上是獨立的：啟動三個平行子代理，每個只給予四個筆記檔案和下面的標籤定義，每個被要求只給出一個標籤和最多三句理由。不要給它們彼此之間的輸出或你自己的草稿。不要在自己的上下文中自己產生標籤然後“重新推導”它，因為在同一個上下文中的第二次判讀會錨定於第一次。

傳遞給每個讀者的定義：

• 開放：沒有佔有者涵蓋點子的核心；商品化底線留下了真正的差異；失敗案例是空的，或者失敗的原因已不再成立。
• 擁擠：數個佔有者涵蓋了大部分；存在一個切入點但巨頭很接近；對於一個縮小的區隔而言，經濟學是合理的。
• 飽和：存在具有已發布定價的直接佔有者、已經在捆綁它的巨頭，或者失敗案例顯示該區隔無法支付。

報告所有三個標籤並顯示任何分歧。不要取平均值，也不要在散文中選擇多數獲勝者；讓讀者看到分歧。基準化的新穎性判定在僅提示重新措辭的情況下，準確率從 93.5% 搖擺到 40.9%，而三輪投票的表現優於花費十二倍成本的專用單次工具。判讀之間的分歧是報告中資訊量最大的一行。

無評論層

不要在綜合之上添加評論、紅隊或辯論代理。已發表的結果顯示，多代理辯論的表現不如單一強大的處理，並在大多數測試的配置中降低了準確性。根據筆記檔案進行一次仔細的綜合勝過一個委員會。

輸出

三個輸出目的地，按此順序。檔案是交付物；對話中只會得到摘要。

1. 報告檔案，總是

將完整報告寫入技能目錄中的 checks/YYYY-MM-DD-<slug>.md，其中 <slug> 是該點子的簡短 kebab-case 名稱。如果 checks/ 不存在則建立它。在檔案開頭加入 YAML 前端資料，以便後續執行可以與之匹配而不必讀取整個報告：

---
idea: 點子的一行陳述
slug: kebab-case-name
date: YYYY-MM-DD
label: Open | Crowded | Saturated
label_reads: [read1, read2, read3]
top_occupants: [name1, name2, name3]
---

當三個判讀不一致時，將 label 設定為出現最多次的那個，或者如果三個都不同則設定為 Split。前端資料是查找鍵；主體才是顯示分歧的地方。

主體：markdown，少於 1,200 字。預設使用散文，只有當比較確實必要時才使用表格（例如多個佔有者附帶定價）。沒有 em dash。章節按此順序排列，使用這些標題：

1. 理解中的點子。 一段。用戶首先檢查這個。
2. 誰已經在那裡。 具名，附 URL、已發布定價（如有），以及每個與點子的接近程度。將供應商宣稱標記為此。
3. 失敗案例。 什麼失敗了以及原因。
4. 經濟學。 誰付費、付多少，以及該區隔能否支付。
5. 商品化底線。 什麼已經是免費或捆綁的。
6. 情勢標籤。 所有三個判讀，顯示任何分歧。
7. 必須成立的事項。 點子能夠存活的具體條件，以及對於每個條件，什麼證據可以確定它。標記研究已經證偽的任何條件。
8. 來源，以及丟棄的來源。 每個引用的 URL，然後是所有四個執行緒中丟棄的來源，每個附帶一句話的原因。

2. 對話摘要，總是

最多輸出 150 字：情勢標籤及三個判讀是否一致，兩到三個最接近的佔有者，單一最具決定性的發現，以及報告檔案的路徑。沒有人會在終端機裡讀 1,200 字。

3. 可分享的頁面，僅在可用時

如果會話中存在用於發布成品或頁面的工具，也將報告發布為頁面並提供使用者連結。將此視為可選。永遠不要讓執行失敗，也永遠不要扣留檔案或摘要，因為這個工具可能不存在。它在許多 Claude Code 會話中不存在，而這個技能通常安裝在這些會話中。

已知限制

當它們適用時，在報告中說明以下內容。

• 缺乏證據在這裡是薄弱的證據。小型競爭者和已倒閉的公司索引都不佳。
• 企業工具的定價通常需要聯繫銷售才能獲得，因此無法取得。
• 搜尋結果的數量並非市場規模的證據；其中大部分是供應商互相撰寫的內容。
• 報告說明一個空間是否被佔據。它並未說明這個使用者是否能贏，這取決於研究無法看到的資訊。