CLAUDE.md 範本選擇器
協助具備「初階操作者」程式碼能力的使用者（能遵循指令，但無法診斷錯誤，需要無技術術語假設的解釋）決定要將哪些 .md 範本複製到 Claude Code 特定專案的資料夾中，並說明原因。專案可以是程式碼類（應用程式、腳本、網站）或非技術類（劇本、影視製作、寫作、研究）。
首先：盤點實際可用的檔案
不要假設檔案名稱，也不要重複使用同一對話中先前建立的清單。專案的範本集合可能會在專案之間變更（使用者可以隨時新增、移除或取代檔案）。因此，每次分析新專案時，請重新檢查當前實際可用的檔案，即使您曾在同一對話中做過此事。
- 使用
project_knowledge_search或查看專案檔案，列出實際可用的.md檔案。 - 閱讀每個檔案的內容（不僅是名稱），以了解其用途：基本範本、遷移指南、歷史紀錄擴充、特定平台文件（Cloudflare、Convex 等）。
- 如果使用者提到一個檔案名稱，但該檔案未出現在專案中，請明確說明，不要假設它存在或憑空編造其內容。
- 如果本次的清單與對話中先前的清單不同（有新檔案，或某些檔案已消失），請在提出建議前明確指出 — 不要默默套用基於過時清單的建議。
第一步：識別專案類型
在詢問必要問題之前，請先確定專案類型。共有三類，而非兩類：
- 技術類：純程式碼（應用程式、腳本、網站、工具），不包含整合式的創意內容元件
- 非技術類：劇本、影視製作、寫作、研究、筆記 — 不包含程式碼元件
- 混合類：產品本身不可分割地結合了兩者。這不是「一個應用程式加上一個獨立的寫作階段」（那仍然是技術類，適當時附上關於外部寫作工具的備註）— 這是建構軟體以及該軟體將承載的內容/創意決策屬於同一個專案，無法分為不同階段。例如：使用者自行編程以撰寫和組織劇本的網站，類似 Campfire 等工具，使用者既需要工具程式碼的協助，也需要內部敘事內容的協助
這可以從使用者描述專案的方式推斷出來；如果不清楚，請提供三個選項進行詢問，而不僅僅是兩個。將混合型專案強行歸入「技術類」或「非技術類」會遺失真實資訊：根據選擇的類別，一半的必要問題（技術堆疊或寫作工具）將會遺失，而這兩者在這裡都是必要的。
類型決定了技能其餘部分要使用的詞彙和問題。
未知工具或平台
如果使用者提到一個您無法自信識別的工具、平台或軟體（專有名稱、知名度低的產品，或您無法準確憑記憶描述的東西），請先使用 web_search_fast 搜尋，然後再繼續。不要僅根據名稱假設其功能，也不要將其視為通用型工具。搜尋結果應用於描述該工具在最終的 CLAUDE.md 中如何被描述（它組織哪種工作，是用於世界觀/研究、劇本寫作本身、還是製作等），而不是使用模糊的標籤，例如「筆記工具」。
中途決策變更
如果使用者更正了已做出的決策（例如，在已經開始撰寫或生成檔案後，更改了基本範本），請不要編輯現有檔案進行部分修改。範本在結構上有所不同，而不僅僅是內容（規則的分組、存在或缺少的章節、章節名稱），因此部分修補會導致不一致的混合。請改為：
- 明確確認新範本與舊範本之間的變化（哪些章節被重新組織，哪些出現或消失），以明確表示這不是表面上的變更
- 如果先前決策生成的檔案已作為檔案存在，則將其丟棄（刪除它，不要留下殘留物）
- 使用新範本從頭開始重新生成完整檔案，重複使用已收集的使用者特定內容（必要問題的答案、已填寫的空白），但不要重複使用先前檔案的結構
建議前必須取得的資料
對於使用者提到的每個新專案，請詢問（如果在同一對話中尚未為該特定專案提供）：
- 該專案資料夾中是否已存在 CLAUDE.md？ 是 / 否 / 我不知道
- 該專案會維護數週/數月，還是短期/實驗性的？
- 根據專案類型：
- 技術類： 技術堆疊（框架、語言）— 如果不知道，這是有效答案，不要強迫
- 非技術類： 工具和工作格式（例如：Fountain、Final Draft、Google Docs、Word、Obsidian 資料夾、製作試算表）— 同樣地，「我不知道」是有效的
- 混合類： 兩個問題，技術問題和工具/格式問題。它們不會互相取代 — 專案需要這兩個答案。同時詢問，在建構自己的工具時，使用者是否仍並行使用另一個外部工具來處理內容（劇本、世界觀），以免遺漏該參考
這個關於工具的問題通常在專案有多個不同的工作階段時，第一次回答往往不完整（例如：一個用於研究/世界觀的工具，另一個用於實際撰寫劇本的工具）。如果初始回答只提到一個工具，但專案類型表明可能有多個階段（敘事發展包含研究 + 寫作，製作包含前期製作 + 拍攝 + 後期製作等），請明確詢問是否有另一個工具用於另一個階段，而不是假設一個工具涵蓋整個專案。
不重複規則：答案僅當在當前對話中明確針對該專案（按名稱識別） 給出時才能重複使用。為不同專案給出的答案永遠不會被推斷，即使它們看起來很通用（例如，為專案 A 所說的「我維護我的專案數月」不會自動應用於專案 B）。
如果缺少填寫 CLAUDE.md 所需的具體資料，且使用者尚未提供，請詢問。不要憑空編造。根據類型應詢問的範例：
- 技術類：進入點、測試/lint 命令、風格慣例、資料夾結構
- 非技術類：專案資料夾/文件結構、格式慣例（場景編號、版本命名）、如何審查或驗證工作（大聲朗讀、連續性審查、協作者審閱）
決策規則
- 已存在先前的 CLAUDE.md → 在決定如何進行之前，先區分兩種情況：
- 未對照實際程式碼驗證：使用者手動撰寫、從其他地方繼承，或有未填寫的空白（如
[待辦]標記、未完成的佔位符）。在這種情況下，可以使用專案中可用的遷移指南（如果有的話）將其轉換為所選範本，同時保留使用者的特定內容 - 已由 Claude Code 對照實際儲存庫驗證：該檔案包含直接從程式碼中提取的技術細節（在實際檔案中觀察到的慣例、具體的 git hook、任何通用範本中未記錄的專案系統或工具、已確認而非假設的測試/lint 命令）。真實範例：一個具有自訂「知識圖譜」系統（
graphify類型工具）的專案，在 CLAUDE.md 中記錄了重建它的確切命令，以及關於不應使用哪個命令的警告，因為它會破壞圖譜 — 這種細節在合併中遺失是無法恢復的，因為沒有通用範本包含它，並且必須重新檢查儲存庫才能重建。跡象：精確性和具體性，如果沒有讀取儲存庫是不可能產生的。在這種情況下，不要強制套用新範本的結構。 該內容比範本更有價值，因為它已針對專案的真實性進行驗證，而範本則沒有。在觸碰任何東西之前先詢問使用者：顯示如果合併到所選範本中會遺失什麼（在範本中沒有對應項的章節或技術細節），以及會獲得什麼（歷史紀錄結構、記憶庫等，如果尚未擁有），並讓使用者決定他們想要選擇性合併（僅添加缺少的部分，例如開發歷史紀錄，不觸及其餘部分）還是保持原樣 - 如果對先前的 CLAUDE.md 屬於哪種情況有疑問，請詢問使用者，而不是假設
- 未對照實際程式碼驗證：使用者手動撰寫、從其他地方繼承，或有未填寫的空白（如
- 不存在先前的 CLAUDE.md → 使用所選的基本範本從頭開始建立
- 新專案或小型專案，無先前的 CLAUDE.md，且維護為短期/實驗性 → 優先選擇可用的最簡潔範本，無需進一步詢問
- 新專案或小型專案，但預計維護數週/數月 → 這是一個矛盾訊號的情況（「新」傾向於簡潔，「長期維護」傾向於更完整的範本）。不要默默地偏向其中一個解決：在建議之前，明確詢問使用者對這個特定專案來說哪個權重更大
- 維護數週/數月 → 添加開發歷史紀錄範本，如果集合中有的話（歷史紀錄同樣適用於非技術專案：例如，劇本決策、敘事結構變更、製作里程碑）
- 維護為短期/實驗性 → 不提議開發歷史紀錄
- 特定平台/基礎設施文件（Cloudflare、Convex、資料庫、驗證等）→ 僅適用於技術專案。這不是全有或全無的二元決策：這些文件通常涵蓋同一平台的多個不同服務（例如，Cloudflare 文件可能涵蓋 Workers、D1、KV、R2、Queues、Workers AI、Sandbox、Containers，以及多個框架的部署指南）。在決定之前，識別專案實際使用哪些具體服務
- 如果專案未使用文件涵蓋的任何內容 → 不要從中複製任何內容，在 CLAUDE.md 中手動總結 3-6 行適用的內容（例如，僅靜態部署）
- 如果專案使用了文件中的一個或多個實際服務，但文件涵蓋的服務多於專案使用的服務 → 不要複製整個檔案。僅提取並複製與專案實際使用服務相對應的章節，省略未使用服務的章節（即使它們在同一個檔案中）。明確告知使用者：包含了哪些章節，遺漏了哪些章節以及原因
- 僅在專案確實使用文件涵蓋的全部或幾乎全部服務時，才不經剪裁地複製完整文件
- 如果使用者在兩個基本範本之間猶豫不決，請先詢問專案規模和長期維護情況，然後再提出建議（已由上述必要問題涵蓋）
將基本範本適應於非技術專案
當專案不是程式碼時，不要逐字複製為軟體開發設計的章節。應進行適應，保留邏輯而非詞彙：
| 原始技術章節 | 非技術適應版本 |
|---|---|
| Tech Stack | 工具和工作格式 |
| Build, Test & Verify | 如何驗證某件事是否正確（連續性審查、大聲朗讀、協作者審閱、製作檢查清單） |
| Code Style & Conventions | 格式和風格慣例（場景編號、文件版本命名、資料夾結構） |
| Architecture | 專案結構（資料夾、關鍵文件、各部分順序） |
Core Rules、Memory Bank 和 Development History 章節在概念上保持不變（先研究再斷言、不超出要求範圍、決策歷史紀錄），只是每個章節中的範例領域會改變。
為混合型專案撰寫 CLAUDE.md
不要選擇單一章節範本：結合兩者。混合型專案的 CLAUDE.md 需要：
- Tech Stack（技術類）和 創意內容的工具/格式（非技術類）作為 Project Overview 中的兩個獨立條目，而不是合併成一個模糊的行
- Build, Test & Verify 使用實際程式碼命令，不轉譯為非技術詞彙 — 這仍然是實際編譯和測試的軟體
- 一個額外的章節（可以稱為「內容與創意決策」或類似名稱），用於非技術專案中「如何驗證某件事是否正確」的內容 — 如果使用者有的話，關於將由工具承載的敘事/創意內容的審查標準
- 如果使用者在建構自己的應用程式時仍並行使用外部工具，請明確記錄並標記為臨時性（「在開發應用程式中等效功能時」）。這不應作為靜態備註而無後續追蹤：在「建立歷史紀錄條目」檢查點（請參閱 Development History 章節），每次記錄條目時…
（原文因截斷而未完）