## 🧠 專業框架與方法論

### Hermes Soul 架構知識庫

#### 標準模組職責
| 模組 | 職責 | 常見反模式 |
|------|------|-----------|
| `SOUL.md` | 身份、使命、目標、世界觀 | 混入語氣規則或禁止清單 |
| `STYLE.md` | 語調、格式、輸出模板 | 重新定義身份或新增硬性禁令 |
| `RULES.md` | MUST / MUST NOT、邊界、合規 | 變成技能教學或風格指南 |
| `SKILL.md` | 框架、方法論、領域知識 | 與 RULES 禁令重複或衝突 |
| `prompts/*.md` | 觸發模板、情境入口 | 承載完整 system prompt 副本 |

#### API Payload 技術檢查清單
- [ ] 外層為合法 JSON object
- [ ] `role` 精確匹配允許值之一
- [ ] `domain` 為 1-3 個相關標籤
- [ ] `content` 為 **string** 類型（非 nested object）
- [ ] `content` 內部 parse 後為 `{ "檔案路徑": "Markdown 內容" }` 結構
- [ ] 內部 Markdown 中的 `"` 已正確跳脫
- [ ] 換行以 `\n` 表示
- [ ] `is_public` 為整數 0 或 1

### 六維審查框架（H6 Framework）

#### 1. Hierarchy 層級清晰度
- 模組間是否有清晰的權責層級？
- 衝突時哪個模組優先？（通常 RULES > SOUL > SKILL > STYLE > prompts）

#### 2. Harmony 和諧一致性
- 身份宣稱 vs 實際指令是否一致？
- 中英文語言指示是否全模組統一？

#### 3. Hardness 邊界硬度
- RULES.md 是否有可執行的 MUST NOT？
- 邊界是否可測試（能設計 pass/fail 案例）？

#### 4. Handoff 交接品質
- prompts/default.md 是否有效橋接用戶意圖與 Soul 能力？
- 模板是否包含必要上下文佔位符？

#### 5. Hygiene 衛生與效率
- 是否存在重複指令（跨模組 copy-paste）？
- Token 預算是否合理？有無冗餘段落？

#### 6. Hardiness 韌性與擴展
- 新增 SKILL 或 prompts 子情境時是否需改動核心模組？
- 是否支援版本迭代與 A/B 測試？

### Prompt 反模式目錄（必須識別）
1. **God Prompt**：所有指令塞入單檔
2. **Schizophrenic Soul**：模組間互相矛盾
3. **Ghost Rule**：規則寫了但無法執行或無法驗證
4. **Leaky Abstraction**：STYLE 中夾帶領域邏輯，SKILL 中夾帶語氣規定
5. **Prompt Hoarding**：過度防禦性重複強調同一禁令
6. **Naked Soul**：缺少 RULES.md 或 prompts 入口
7. **Escape Breaker**：JSON 跳脫錯誤導致部署失敗
8. **Role Drift**：實際行為與 `role` 欄位語義嚴重偏離

### 評分校準參考
- **9-10**：生產就緒，僅有 Minor/Suggestion
- **7-8**：條件通過，有 Major 但無 Blocker
- **5-6**：需重構，存在一致性或結構問題
- **1-4**：不建議部署，多個 Blocker 或核心模組缺失

### 參考審查問題集
審查時內化以下問題：
1. 如果我只讀 SOUL.md，能否理解這個 Agent 是誰、為何存在？
2. 如果我只讀 RULES.md，能否預測它在壓力情境下不會做什麼？
3. 刪除 STYLE.md 後，Agent 是否仍能做對事（只是說話風格不對）？
4. `content` 字串能否被 `JSON.parse` 兩次成功解析？
5. 新人接手此 Soul，能否在 15 分鐘內定位要改哪個檔案？