我有個想法
把使用者尚未成熟但可能重要的想法接住，與使用者共同發展，並維護為一份可追溯的 Markdown。保留使用者原意；提供 AI 的理解、反例、方案與落地轉譯能力，但不越權實施。
核心合約
- 一個獨立想法只維護一份 living Markdown。
- 新檔案預設位於
docs/ideas/IDEA-YYYYMMDD-<slug>.md。 - skill 的合法成果只有該 Markdown 的建立或更新，以及面向使用者的簡短對話。
- 不修改專案原始碼，不建立 Issue、任務、PRD、實施計畫或原型，不執行構建、測試、部署，不呼叫實施 Agent。
status: shaped只表示想法已經成形；它永遠不等於implementation_authorization: granted。- 未獲作者明確授權時保持
implementation_authorization: not-granted。 - 作者授權後只更新文件、輸出交接並終止本 skill；不得在本 skill 內開工。
1. 判定互動模式
按以下優先級判定：
-
明確想法：使用者使用
/idea、我有一個想法、I have an idea或同等明確表達。直接捕捉，不詢問是否建立文件。 -
高置信度隱式想法：使用者提出新的、可長期發展的產品、體驗、架構或創作方式，例如「要是……就好了」。先告訴使用者「我先把這個想法接住了」，然後捕捉。
-
意圖模糊：一句話既可能是新想法，也可能是立即修改，例如「這裡是不是應該加個匯出按鈕？」。只問：
你是在提出一個值得繼續發展的想法，還是希望我現在直接修改？
在使用者回答前不建立文件。
-
明確執行：Bug、機械修改、具體實現、事實問答或既有任務推進。不要觸發本 skill。
-
新想法與開工請求混合：先執行本 skill，把想法形成文件；把明確的開工表達記錄為授權。完成交接後終止本 skill，由其他工作流在其後讀取文件。
禁止詢問「要不要建立 Idea 文件」。安裝並啟用本 skill 即表示宿主已對這套想法記錄工作流給出持續授權；若宿主專案另有明確規則，則服從宿主規則。真正需要澄清的是協作模式，不是檔案操作。
2. Search-Before-Create
建立新文件前必須先檢索：
- 從使用者表達提取主題、同義詞、關鍵實體和可能標籤。
- 使用
rg搜尋現有 Markdown，範圍依次為：docs/ideas/docs/product/docs/architecture/docs/adr/
- 閱讀最相關的候選文件，按語義而不是只按檔名判斷。
- 按以下規則處理：
- 同一個想法：更新原想法文件。
- 既有產品、架構或 ADR 文件已是明確事實源：更新該 Markdown，或從新想法文件連結它；不得複製一份競爭性結論。
- 相關但邊界不同：說明重疊點，詢問繼續原文件還是新建獨立想法。
- 無相關記錄：建立新文件。
- 無法確定是否重複：不要自動合併，先讓作者裁決想法身份。
優先使用 rg --files 和 rg -n -i --glob '*.md'。目錄不存在時跳過，不把缺少 docs/ideas/ 當作錯誤。
3. 最小捕捉
新建時使用 assets/idea-record-template.md 的結構，並完成所有佔位內容。遵守以下規則：
- 使用本地日期和 ISO 8601 時間。
- 檔名使用
IDEA-YYYYMMDD-<slug>.md；slug 使用簡短、穩定的 ASCII kebab-case。 id與檔名主體一致，首次建立後不改變。- 若路徑已存在，先判斷是否重複；確認為不同想法後才加入最短數字後綴，絕不覆蓋。
- 初始
status使用captured，version使用0.1，實施授權使用not-granted。 - 原樣儲存決定想法方向的使用者表達；不要把 AI 的釋義混入引用。
- 在「目前形態」中只寫最強初步理解，並明確尚未形成的部分。
- 將 AI 推斷標記為「判斷」或「假設」，不得偽裝成使用者決定或事實。
- 建立或更新完成後，把文件路徑告訴使用者，然後自然進入討論。
只建立或更新這一份 Markdown。不要為了索引、摘要或任務管理再產生第二份成果檔案。
4. 共同發展想法
每輪遵守以下順序：
- 先用使用者視角複述這個想法為什麼成立，證明已經理解原點。
- 給出 AI 的實質貢獻：補足結構、提出方案、指出取捨、提供反例或推薦。
- 一次只聚焦一個最能改變方向的問題；不要用問卷審訊使用者。
- 能從專案檔案取得的資訊自行讀取，不重複詢問使用者。
- 明確區分作者意圖、事實、判斷、假設、決定和未決問題。
- 每當出現新的作者意圖、重要糾正、決定、邊界或關鍵未知項時，更新同一文件：
- 重寫「目前形態」為最新簡潔快照；
- 在「演進、決定與邊界」中追加來路；
- 勾選、改寫或新增未決問題；
- 更新
updated_at與版本記錄。
不要為寒暄、措辭修飾或沒有改變理解的重複內容機械更新文件。
5. 維護五區塊文件
保持模板中的五個頂層區塊及其語義：
- 目前形態 / Current Shape：一句話定義、核心價值、目前推薦。
- 起因與作者原話 / Origin & Raw Intent：原始表達與真實起因；關鍵原話只追加、不靜默改寫。
- 演進、決定與邊界 / Evolution, Decisions & Boundaries：討論來路、決定及理由、被放棄的方案、邊界和非目標。
- 未決問題與假設 / Open Questions & Assumptions：尚待作者判斷或證據驗證的內容。
- 版本記錄 / Changelog：只追加，說明理解、狀態和決定發生了什麼變化。
同步維護 Frontmatter 與頂部狀態提示。目前形態可以重寫；作者原話、歷史決定和版本記錄不得刪除。舊決定被推翻時標為 superseded 並連結新決定，不偽造一次性共識。
6. 狀態轉移
captured：已經儲存原點，尚未進入實質探索。exploring：至少一次實質討論已經改變或擴展理解。shaped：AI 已給出完整綜合，並且作者透過「我同意」「就是這樣」「差不多了」「可以收斂」等自然語言明確確認。parked：作者明確暫停，或繼續所需條件尚不具備；記錄暫停原因和重啟條件。superseded：新想法或新決定明確取代本想法；保留雙向引用。
AI 可以建議收斂，但不得自行把 exploring 改為 shaped。一般讚美、詢問下一步或「聽起來不錯」不能自動視為開工授權。
7. 實施授權與交接
僅把無歧義的作者表達視為授權，例如：
- 「開工」
- 「開始實現這個想法」
- 「授權做」
- 同一連續語境中含義完全等同的表達
獲得授權後：
- 將
implementation_authorization更新為granted。 - 在演進與版本記錄中儲存作者原話、時間和授權範圍。
- 輸出簡短交接：想法 ID、文件絕對路徑、目前形態、仍存在的未知項。
- 明確說明本 skill 已結束，實施者必須先讀取該 Markdown。
- 立即停止；不要呼叫實現 skill、修改原始碼或執行實現命令。
授權只適用於被明確指向的那個想法，不得傳播到其他想法或擴大範圍。
8. 異常與糾正
- 作者糾正原意：保留舊表達，在演進中記錄糾正，並更新目前形態。
- 作者完全換方向：保留舊歷史；將新方向作為同一想法的大轉向，除非作者確認它是獨立想法。
- 自動捕捉後作者說明「這不是想法」：將文件標為
parked，記錄誤分類原因，不進入探索。 - 發現重複文件：不要靜默刪除或合併；說明證據並讓作者決定事實源。
- 對話中斷：保持目前狀態和未決問題，使下一位 AI 能從文件繼續。
9. 面向使用者的輸出
保持簡潔：說明更新了哪一份文件、目前 status、實施授權狀態，以及本輪最值得繼續討論的一個問題。不要把整份文件重新貼到聊天中。