您正在擴展現有的知識系統，新增一個領域。這是組合（composition），而非取代。新領域必須與現有領域共存，同時維護自己的詞彙、資料結構（schema）和處理模式。共享的圖譜（Wiki 連結、樞紐 MOC、描述欄位）將所有領域串聯在一起。
您的任務
新增一個知識領域：$ARGUMENTS
參考檔案
請在推導階段閱讀這些檔案：
組合規則：
${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md-- 測試 4（多領域組合）驗證此模式${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md-- 三空間架構（跨領域共享）${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md-- 領域設定的一致性驗證
領域設定：
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md-- 領域原生詞彙映射${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md-- 預先驗證的領域設定${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md-- 3 個預設情境及其設定${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md-- 維度定位的研究依據${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md-- 領域弱點矩陣
驗證：
${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml-- 12 個不可協商的原則${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh-- 核心驗證腳本
階段 1：掃描現有系統
自動化。在新增之前先了解現有系統。
1a. 讀取系統設定
閱讀 ops/derivation.md 以取得：
- 當前的維度定位
- 詞彙映射
- 平台與自動化層級
- 活躍的功能區塊
閱讀 ops/config.yaml 以取得即時設定值。
1b. 盤點現有領域
識別所有當前的知識領域：
- 主要筆記資料夾及其領域詞彙
- 任何現有的次要領域（資料夾、範本、MOC）
- 各領域使用的資料結構欄位
1c. 識別維度類型
將 8 個維度分類為系統層級或領域可調整：
| 維度 | 類型 | 理由 |
|---|---|---|
| 組織 | 系統層級 | 扁平/階層適用於整個工作區 |
| 自動化 | 系統層級 | 掛鉤和技能是整個工作區的基礎設施 |
| 導覽深度 | 系統層級 | 樞紐 MOC 結構是共享的 |
| 粒度 | 領域可調整 | 不同領域可能需要不同的粒度 |
| 處理 | 領域可調整 | 研究需要重度處理，關係需要輕度處理 |
| 維護 | 領域可調整 | 不同領域成長率有不同的條件門檻 |
| 資料結構 | 領域可調整 | 領域專屬的欄位會有所不同 |
| 連結 | 領域可調整 | 某些領域需要語意搜尋，其他則不需要 |
系統層級維度由現有系統固定。領域可調整維度可以為新領域進行調整。
階段 2：對話
1-3 輪對話以了解新領域。每輪使用 AskUserQuestion。
開啟問題
針對新領域提出一個具體問題：
「請告訴我關於 [從 $ARGUMENTS 取得的領域提示]——您會追蹤哪些種類的事項，這與您現有的 [當前領域詞彙] 工作有何關聯？」
第二部分至關重要：了解領域之間的關係能驅動組合決策。
訊號提取
當使用者回應時，為領域可調整維度提取訊號：
| 訊號 | 維度 | 定位 |
|---|---|---|
| 「關於人物的快速筆記」 | 粒度 | 適中 |
| 「會議的深入分析」 | 處理 | 重度 |
| 「只記住關鍵時刻」 | 處理 | 輕度 |
| 「我經常回顧並更新」 | 維護 | 嚴格門檻 |
| 「大多記錄下來就靜止了」 | 維護 | 寬鬆門檻 |
| 「需要跨條目找模式」 | 連結 | 明確+隱含 |
同時提取：
- 數量估計——每個處理批次有多少筆記
- 時間動態——內容變化的速度
- 詞彙——使用者自己用來描述筆記、流程、組織的詞語
- 跨領域關係——這如何與現有領域連結
後續問題策略
在收到首次回應後，提出 1-2 個針對性問題：
- 詞彙確認——「當您說 [使用者的詞語] 時，您是指個別的洞見還是較長的條目？」
- 跨領域連結模式——「[新領域] 的筆記會連結到您 [現有領域] 的筆記嗎？如何連結？」
請勿直接詢問維度。從自然的對話中傾聽這些線索。
階段 3：推導領域設定
3a. 將訊號映射至領域可調整維度
對於每個可調整維度，決定新領域的定位：
- 使用者訊號（最高優先順序）
- 最接近的用例預設，來自
${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md - 從系統層級維度的串聯
3b. 建構詞彙映射
閱讀 ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md 以取得轉換表。
優先順序：
- 對話中使用者自己的詞語
- 用例預設詞彙
- 最接近的參考領域混合
為新領域建構完整的映射：
| 通用詞彙 | 新領域詞彙 | 來源 |
|---|---|---|
| 筆記 | [詞彙] | [使用者 / 預設 / 混合] |
| 萃取 / 濃縮 | [詞彙] | [使用者 / 預設 / 混合] |
| 連結 / 反思 | [詞彙] | [使用者 / 預設 / 混合] |
| MOC | [詞彙] | [使用者 / 預設 / 混合] |
| 描述 | [詞彙] | [使用者 / 預設 / 混合] |
| 主題 | [詞彙] | [使用者 / 預設 / 混合] |
| 收件匣 | [詞彙] | [使用者 / 預設 / 混合] |
3c. 設計領域專屬資料結構
從基礎筆記資料結構（描述、主題）開始，並新增領域專屬欄位：
_schema:
entity_type: "[領域]-note"
applies_to: "[領域資料夾]/*.md"
required:
- description
- topics
optional:
- [根據對話訊號的領域專屬欄位]
enums:
[欄位]:
- [領域相關的值]
3d. 衝突檢查
這對於多領域組合至關重要。 驗證：
-
檔案名稱唯一性——新領域的筆記標題不會與現有筆記衝突。Wiki 連結是根據檔案名稱在整個工作區解析的，因此每個檔案名稱都必須是唯一的。
-
資料結構欄位名稱——新領域欄位不與現有領域欄位衝突。如果兩個領域使用相同的欄位名稱（例如
type），則列舉值必須互斥，或者該欄位必須具有相容的語意。 -
範本名稱——新領域範本與現有範本的名稱不同。
-
資料夾名稱——新領域資料夾不與現有資料夾衝突。
如果偵測到任何衝突，請在繼續之前解決。
階段 4：檢查組合規則
閱讀 ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md（測試 4：多領域組合）以取得經驗證的組合模式。
驗證每個組合規則：
規則 1：Wiki 連結在共享命名空間中無歧義地解析
所有筆記檔案名稱在整個領域中必須是唯一的。新領域的命名慣例必須與現有慣例相容。
規則 2：樞紐 MOC 連結至所有領域 MOC
必須更新現有的樞紐 MOC（index.md 或等效檔案），以包含新領域的入口 MOC。階層結構變為：
hub -> 現有領域 MOC
-> 新領域 MOC
規則 3：跨領域反思搜尋所有筆記資料夾
如果連線查找（反思）功能已啟用，它必須搜尋所有領域——新領域中的筆記可能連結到現有領域中的筆記。語意搜尋集合必須包含新領域資料夾。
規則 4：領域專屬處理可以共存
如果新領域需要與現有領域不同的處理強度，則管線必須根據筆記類型進行路由。研究筆記使用重度處理，關係筆記使用輕度處理，依此類推。
規則 5：上下文檔案載入是漸進的
新領域的方法論指南應僅在處理該領域時載入，而不是在每次工作階段開始時載入。這可以防止隨著領域累積而導致的上下文膨脹。
一致性檢查
透過 ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md 執行新領域的設定：
- 新領域設定與系統層級維度之間的硬性限制違反
- 特定於新領域的軟性限制警告
- 對現有領域的串聯效應
階段 5：提出方案
向使用者精確展示將要建立的內容以及它如何與現有系統連結。
輸出格式：
=== 新增領域方案 ===
新領域：[領域名稱]
詞彙：[關鍵詞彙映射]
--- 將建立的內容 ---
資料夾結構：
[領域資料夾]/ <- [描述]
index.md <- 領域樞紐 MOC
[領域收件匣]/ <- 捕捉區（如果處理強度 >= 適中）
templates/[領域]-note.md <- 包含領域資料結構的筆記範本
--- 與現有系統的連結 ---
- 樞紐 MOC（index.md）：新增 [新領域] 區塊，包含指向 [[領域-index]] 的連結
- 跨領域連結：[新領域] 筆記可以連結到 [現有領域] 筆記，反之亦然
- 共享基礎設施：self/、ops/、templates/ 保持共享
- 語意搜尋：[新增集合 / 目前數量下不需要]
--- 不變的部分 ---
- 現有 [領域] 資料夾：不受影響
- 現有範本：不受影響
- 現有 MOC 階層：不受影響（樞紐新增一個連結）
- self/ 空間：共享（methodology.md 更新為包含多領域模式）
- ops/ 空間：共享（derivation.md 更新為包含領域新增）
--- 領域設定 ---
| 維度 | 定位 | 理由 |
|-----------|----------|-----------|
| 粒度 | [值] | [原因] |
| 處理 | [值] | [原因] |
| 維護 | [值] | [原因] |
| 資料結構 | [值] | [原因] |
| 連結 | [值] | [原因] |
| （系統層級維度繼承自現有系統） |
--- 資料結構預覽 ---
[顯示新領域範本的 _schema 區塊]
--- 詞彙映射 ---
| 通用 | 新領域 | 現有領域 |
|-----------|-----------|-----------------|
| 筆記 | [詞彙] | [現有詞彙] |
| ... | ... | ... |
您希望我建立這個嗎？在生成之前，我可以調整任何內容。
=== 方案結束 ===
等待使用者批准後再繼續。
階段 6：生成
建立新領域的基礎設施。順序很重要——後續的產物會參考先前的產物。
步驟 1：領域資料夾結構
建立領域的筆記資料夾和可選的收件匣資料夾：
mkdir -p [領域資料夾]
mkdir -p [領域收件匣] # 如果處理強度 >= 適中
步驟 2：領域筆記範本
建立 templates/[領域]-note.md，包含推導出的 _schema 區塊、必要和選用欄位，並在註解和範例中使用領域詞彙。
步驟 3：領域樞紐 MOC
建立 [領域資料夾]/index.md：
---
description: [以領域詞彙描述的入口點]
type: moc
---
# index
[以領域詞彙撰寫的導覽段落]
## [領域：主題]
（主題會隨著筆記累積而浮現）
## 開始使用
1. 捕捉您的第一則 [領域：筆記]
2. 將其連結至此樞紐
步驟 4：領域指南
建立一個領域專屬的方法論文件，在處理此領域時載入。對於 Claude Code：.claude/skills/[領域]-guide/SKILL.md 或上下文檔案中的一個章節。對於其他平台：一個獨立的指南檔案。
指南涵蓋：
- 如何在此領域中捕捉
- 如何處理（以推導出的強度）
- 何時進行跨領域連結
- 領域專屬的品質標準
- 領域詞彙參考
步驟 5：更新樞紐 MOC
將新領域新增至現有的樞紐 MOC（index.md）：
## [新領域名稱]
- [[領域-index]] -- [描述此領域追蹤的內容]
步驟 6：更新上下文檔案
新增至上下文檔案：
- 領域路由：當在 [領域] 中工作時，載入 [領域指南]
- 詞彙：新領域詞彙已新增至詞彙參考
- 處理：如果處理強度不同，請記錄路由方式
- 跨領域連結：何時以及如何進行跨領域連結
步驟 7：更新 self/methodology.md
新增多領域工作模式：
- 如何在領域之間切換
- 何時建立跨領域連結
- 各領域的處理觸發條件
步驟 8：更新 ops/derivation.md
記錄領域新增：
- 新領域名稱和詞彙
- 領域可調整維度定位及其理由
- 已驗證的組合規則
- 跨領域連結模式
- 新增的日期和背景
步驟 9：更新語意搜尋（如果已設定）
如果已設定 qmd 或等效工具：
# 為領域資料夾新增集合
qmd update
qmd embed
更新 .mcp.json 或等效設定以包含新集合。
步驟 10：領域處理技能（如果處理強度 >= 適中）
如果新領域需要自己的處理技能（因為處理強度或詞彙與現有領域不同），請生成適用於該領域的濃縮/反思/驗證技能版本。
如果現有技能可以透過筆記類型處理多領域路由，則更新它們而不是建立副本。
階段 7：驗證
新領域檔案的核心檢查
對新領域的檔案執行核心驗證：
- 所有新檔案上的 YAML frontmatter 都有效
- 新檔案中的 Wiki 連結能夠解析（包括跨領域連結）
- 從樞紐可以到達新領域 MOC
- 描述欄位存在
- 主題頁尾參考了領域 MOC
組合驗證
- 無欄位衝突——在所有範本中 grep 欄位名稱，驗證無語意衝突
- 樞紐可達性——樞紐 MOC 連結至所有領域 MOC，所有領域 MOC 連結至其筆記
- 跨領域連結測試——從新領域建立一個測試連結到現有領域，驗證其可解析
- 檔案名稱唯一性——驗證跨領域無重複檔案名稱：
find . -name "*.md" | xargs -I {} basename {} | sort | uniq -d - 資料結構一致性——驗證新領域的資料結構與其詞彙一致（例如，如果使用者使用「日誌條目」這個詞，則
entity_type應為log-entry）
最終一致性檢查
- 從使用者對話到維度定位的逆向鏈結是否一致？
- 新領域的詞彙是否與其用例語意一致？
- 跨領域連結模式是否與使用者的工作流程相符？
- 隨著新領域的新增，系統是否仍然保持可組合性（即，第 5 個領域能否乾淨地新增）？
如有任何檢查失敗，請修正後再繼續。