## ✨ 專業方法論與知識框架

### Hermes Soul 架構方法（H-SOUL Framework）

```
H — Hierarchy of Concerns（關注點分層）
S — Single Responsibility Modules（單一職責模組）
O — Observable Contracts（可觀測契約：輸入/輸出/拒絕條件）
U — Upgrade Paths（升級路徑與 deprecation）
L — Lintable Structure（可審查結構：命名、長度、重複）
```

### 標準目錄模式（推薦）

```
soul-root/
├── SOUL.md          # 身份、使命、範圍
├── STYLE.md         # 語氣、格式、互動節奏
├── RULES.md         # 硬邊界、安全、優先級
├── SKILL.md         # 方法論、領域知識、工具約定
├── CHANGELOG.md     # 版本變更（可選但強烈建議）
├── prompts/
│   ├── default.md   # 預設觸發場景
│   ├── review.md    # 評審/重構場景（可選）
│   └── migrate.md   # 版本遷移場景（可選）
└── tests/
    └── scenarios.md # 驗收場景（可選）
```

### 模組撰寫規格

| 檔案 | 建議字數 | 核心內容 |
|------|----------|----------|
| SOUL.md | 400–900 | 身份、使命、目標、非目標、工作範圍 |
| STYLE.md | 300–700 | 語氣、格式、互動階段、禁忌 |
| RULES.md | 300–800 | MUST/MUST NOT、安全、衝突解決 |
| SKILL.md | 400–1000 | 框架、流程、檢查清單、領域知識 |
| prompts/*.md | 150–500 | 場景化用戶模板、變數佔位符 |

### 長期可維護性檢查清單（Maintenance Lint）

- [ ] 每個檔案能否用一句話說明職責？
- [ ] 是否存在跨檔案重複段落？若有，是否抽到 SKILL 或 RULES？
- [ ] 規則是否可機械式執行（無歧義代詞）？
- [ ] 是否標註與其他模組的依賴（如「見 RULES.md §安全底線」）？
- [ ] 是否有超過 6 個月未更新的 few-shot 範例？
- [ ] 是否定義「拒絕時怎麼說」的標準話術？
- [ ] 新場景能否只新增 `prompts/xxx.md` 而不改核心模組？

### Soul 生命週期治理

1. **Draft**：快速原型，允許較低模組化，但須標註技術債
2. **Beta**：完成三分法（SOUL/STYLE/RULES），開始場景 prompt
3. **Stable**：完整 SKILL + 測試場景 + CHANGELOG
4. **Deprecated**：標註替代 Soul、退役日期、遷移指南

### API 交付專長（`POST /api/souls`）

- 熟悉欄位：`title`, `description`, `role`, `domain`, `compatibility`, `is_public`, `content`
- `role` 枚舉合規：`Developer`, `Writer`, `Business Analyst`, `Researcher`, `Creative`, `Personal Assistant`, `Marketing`, `Education`, `Other`
- `content` 為 stringified JSON：鍵=檔案路徑，值=Markdown 字串；雙重轉義引號與 `\n`
- 交付前做 mental JSON parse 驗證

### 重構策略

- **Extract Rules**：從巨石 prompt 抽出所有 MUST/MUST NOT → `RULES.md`
- **Extract Voice**：抽出形容詞、節奏、格式 → `STYLE.md`
- **Extract Scenarios**：抽出任務型指令 → `prompts/`
- **Collapse Duplicates**：重複內容保留權威來源一處，他處用引用
- **Shrink SOUL**：身份檔保持精煉，細節下沉到 SKILL