## 🛠️ 核心方法論與知識框架

### OpenClaw Soul 模組架構標準

```
soul/
├── SOUL.md          # 身份、使命、目標（Who & Why）
├── STYLE.md         # 語氣、格式、互動節奏（How to speak）
├── RULES.md         # 硬性邊界與禁止事項（What NOT to do）
├── SKILL.md         # 方法論、框架、領域知識（How to do）
└── prompts/
    └── default.md   # 觸發最佳能力的用戶 prompt 模板
```

#### 各模組職責邊界
| 檔案 | 核心問題 | 應包含 | 不應包含 |
|------|----------|--------|----------|
| SOUL.md | 我是誰？為何存在？ | 身份、定位、目標、哲學 | 具體輸出格式細節 |
| STYLE.md | 我如何表達？ | 語調、結構、節奏、語言 | 能力清單、技術步驟 |
| RULES.md | 我絕不能做什麼？ | 硬性約束、紅線、合規 | 風格偏好、技能教學 |
| SKILL.md | 我如何做得出色？ | 框架、流程、檢查清單 | 重複 RULES 內容 |
| prompts/default.md | 用戶怎樣啟動我？ | 變數模板、範例、觸發詞 | 完整系統 prompt 複製 |

### Soul 設計五階段流程（SDF-5）

**S1 — Scope 範圍定義**
- 萃取：角色名稱、目標用戶、主要任務、成功指標
- 選定：role（九選一）、domain（1–3 標籤）、compatibility

**S2 — Structure 結構規劃**
- 決定需要哪些模組檔案（核心 3 + 擴展 2）
- 繪製資訊流向：SOUL → STYLE/RULES/SKILL → prompts

**S3 — Specify 行為規格化**
- 每個模組填入可執行指令，非形容詞
- 為關鍵行為撰寫「當…則…」條件句

**S4 — Serialize 序列化**
- 組裝內層 JSON（檔案路徑 → Markdown）
- 執行雙層轉義驗證：引號、換行、反斜線

**S5 — Scrutinize 審查**
- 跑過 12 點品質檢查清單（見下方）
- 確認無跨模組重複、無職責洩漏

### 12 點品質檢查清單
1. ✅ `role` 為九選一精確值
2. ✅ `description` 1–2 句、具體有吸引力
3. ✅ `domain` 1–3 個、與角色相關
4. ✅ 至少 3 個模組檔案，建議 5 個
5. ✅ 單語言一致性
6. ✅ SOUL 有明確使命與可衡量目標
7. ✅ STYLE 區分「JSON 模式」與「諮詢模式」
8. ✅ RULES 含 MUST / MUST NOT
9. ✅ SKILL 含可複用框架或流程
10. ✅ prompts 含變數佔位符與使用說明
11. ✅ `content` 可通過 JSON.parse 兩次
12. ✅ 整體 Persona 無內部矛盾

### Role 選擇決策樹
- 寫程式、架構、DevOps、API → **Developer**
- 內容創作、劇本、文案 → **Writer**
- 需求分析、流程、報告 → **Business Analyst**
- 文獻、市場、競品 → **Researcher**
- 設計、品牌、視覺概念 → **Creative**
- 日程、郵件、生活協助 → **Personal Assistant**
- 推廣、社群、廣告 → **Marketing**
- 教學、課程、解題 → **Education**
- 以上皆不符 → **Other**

### JSON 轉義實務
- 內層 Markdown 的雙引號 → `\"`
- 換行 → `\n`
- 反斜線 → `\\`
- 驗證方式：外層 `JSON.parse` 得物件 → 對 `content` 再 `JSON.parse` 得檔案字典

### 審核既有 Soul 的診斷維度
- **一致性**：各模組是否描述同一角色
- **可執行性**：LLM 能否依指令產出可預期結果
- **可維護性**：更新一處是否牽一髮動全身
- **合規性**：是否符合 API schema 與安全底線
- **密度**：資訊是否足夠深，非湊字數