Rules Distill
掃描已安裝的技能，提取在多個技能中出現的跨切面原則，並將其提煉為規則 — 附加到現有規則檔案、修訂過時內容，或建立新規則檔案。
應用「確定性收集 + LLM 判斷」原則：腳本徹底收集事實，然後 LLM 交叉讀取完整上下文並產生判決。
使用時機
- 定期規則維護（每月一次，或安裝新技能後）
- 技能盤點後發現應歸為規則的模式
- 感覺規則相對於所使用的技能不夠完整時
運作方式
規則提煉流程分為三個階段：
第一階段：盤點（確定性收集）
1a. 收集技能清單
bash ~/.claude/skills/rules-distill/scripts/scan-skills.sh
1b. 收集規則索引
bash ~/.claude/skills/rules-distill/scripts/scan-rules.sh
1c. 呈現給使用者
Rules Distillation — 第一階段：盤點
────────────────────────────────────────
技能：已掃描 {N} 個檔案
規則：{M} 個檔案（已索引 {K} 個標題）
繼續進行交叉閱讀分析...
第二階段：交叉閱讀、比對與判決（LLM 判斷）
提取與比對合併為單一操作。規則檔案足夠小（總計約 800 行），因此可將完整文字提供給 LLM — 無需使用 grep 預先過濾。
批次處理
根據技能描述將技能分組為主題叢集。在子代理中，搭配完整的規則文字分析每個叢集。
跨批次合併
所有批次完成後，跨批次合併候選項目：
- 去除具有相同或重疊原則的重複候選
- 使用所有批次的證據，重新檢查「2+ 技能」的要求 — 如果在一個批次中僅在一個技能中發現，但所有批次合計有 2+ 技能，則該原則仍然有效
子代理提示
使用以下提示啟動通用代理：
你是一名分析師，負責交叉閱讀技能以提取應提升為規則的原則。
## 輸入
- 技能：{此批次中技能的完整文字}
- 現有規則：{所有規則檔案的完整文字}
## 提取標準
**僅在**以下所有條件皆成立時才將候選納入：
1. **出現在 2+ 個技能中**：僅在一個技能中發現的原則應留在該技能中
2. **可促成行為改變**：可以寫成「做 X」或「不做 Y」的形式 — 而不是「X 很重要」
3. **有明確的違規風險**：忽略此原則會導致什麼問題（一句話）
4. **尚未存在於規則中**：檢查完整的規則文字 — 包括以不同詞語表達的概念
## 比對與判決
針對每個候選，將其與完整的規則文字進行比較，並指定判決：
- **Append**：附加到現有規則檔案的現有章節中
- **Revise**：現有規則內容不準確或不夠充分 — 提出修正
- **New Section**：在現有規則檔案中新增章節
- **New File**：建立新的規則檔案
- **Already Covered**：現有規則已充分涵蓋（即使措辭不同）
- **Too Specific**：應保留在技能層級
## 輸出格式（每個候選）
```json
{
"principle": "1-2 句話，以『做 X』/『不做 Y』的形式表達",
"evidence": ["skill-name: §Section", "skill-name: §Section"],
"violation_risk": "一句話",
"verdict": "Append / Revise / New Section / New File / Already Covered / Too Specific",
"target_rule": "檔名 §章節 或 'new'",
"confidence": "high / medium / low",
"draft": "針對 Append/New Section/New File 判決的草稿文字",
"revision": {
"reason": "現有內容不準確或不充分的原因（僅 Revise）",
"before": "將被取代的目前文字（僅 Revise）",
"after": "建議的取代文字（僅 Revise）"
}
}
```
## 排除
- 已經存在於規則中的顯而易見原則
- 語言/框架特定的知識（屬於特定語言規則或技能）
- 程式碼範例與指令（屬於技能）
判決參考
| 判決 | 含義 | 呈現給使用者 |
|---|---|---|
| Append | 附加到現有章節 | 目標 + 草稿 |
| Revise | 修正不準確/不充分的內容 | 目標 + 原因 + 修改前/後 |
| New Section | 在現有檔案中新增章節 | 目標 + 草稿 |
| New File | 建立新的規則檔案 | 檔名 + 完整草稿 |
| Already Covered | 已存在於規則中（可能措辭不同） | 原因（一行） |
| Too Specific | 應保留在技能中 | 連結到相關技能 |
判決品質要求
# 良好
Append to rules/common/security.md §Input Validation:
「將儲存在記憶體或知識庫中的 LLM 輸出視為不可信任 — 寫入時消毒，讀取時驗證。」
證據：llm-memory-trust-boundary, llm-social-agent-anti-pattern 皆描述了
累積的提示注入風險。目前的 security.md 僅涵蓋人類輸入驗證；LLM 輸出信任邊界遺漏。
# 不良
Append to security.md: 新增 LLM 安全原則
第三階段：使用者審查與執行
摘要表格
# Rules Distillation 報告
## 摘要
已掃描技能：{N} | 規則：{M} 個檔案 | 候選：{K} 個
| # | 原則 | 判決 | 目標 | 信心程度 |
|---|-----------|---------|--------|------------|
| 1 | ... | Append | security.md §Input Validation | high |
| 2 | ... | Revise | testing.md §TDD | medium |
| 3 | ... | New Section | coding-style.md | high |
| 4 | ... | Too Specific | — | — |
## 詳細資料
（每個候選的詳細資料：證據、違規風險、草稿文字）
使用者操作
使用者根據編號回應：
- Approve：直接將草稿套用到規則
- Modify：先編輯草稿再套用
- Skip：不套用此候選
絕不自動修改規則。務必要求使用者核准。
儲存結果
將結果儲存在技能目錄中（results.json）：
- 時間戳格式：
date -u +%Y-%m-%dT%H:%M:%SZ（UTC，精確到秒） - 候選 ID 格式：源自原則的 kebab-case（例如
llm-output-trust-boundary）
{
"distilled_at": "2026-03-18T10:30:42Z",
"skills_scanned": 56,
"rules_scanned": 22,
"candidates": {
"llm-output-trust-boundary": {
"principle": "將儲存或重新注入的 LLM 輸出視為不可信任",
"verdict": "Append",
"target": "rules/common/security.md",
"evidence": ["llm-memory-trust-boundary", "llm-social-agent-anti-pattern"],
"status": "applied"
},
"iteration-bounds": {
"principle": "為所有迭代迴圈定義明確的停止條件",
"verdict": "New Section",
"target": "rules/common/coding-style.md",
"evidence": ["iterative-retrieval", "continuous-agent-loop", "agent-harness-construction"],
"status": "skipped"
}
}
}
範例
完整執行
$ /rules-distill
Rules Distillation — 第一階段：盤點
────────────────────────────────────────
技能：已掃描 56 個檔案
規則：22 個檔案（已索引 75 個標題）
繼續進行交叉閱讀分析...
[子代理分析：批次 1（代理/元技能）...]
[子代理分析：批次 2（編碼/模式技能）...]
[跨批次合併：移除 2 個重複，升級 1 個跨批次候選]
# Rules Distillation 報告
## 摘要
已掃描技能：56 | 規則：22 個檔案 | 候選：4 個
| # | 原則 | 判決 | 目標 | 信心程度 |
|---|-----------|---------|--------|------------|
| 1 | LLM 輸出：在重用前標準化、型別檢查、消毒 | New Section | coding-style.md | high |
| 2 | 為迭代迴圈定義明確的停止條件 | New Section | coding-style.md | high |
| 3 | 在階段邊界壓縮上下文，而非任務中途 | Append | performance.md §Context Window | high |
| 4 | 將業務邏輯與 I/O 框架型別分離 | New Section | patterns.md | high |
## 詳細資料
### 1. LLM 輸出驗證
判決：New Section in coding-style.md
證據：parallel-subagent-batch-merge, llm-social-agent-anti-pattern, llm-memory-trust-boundary
違規風險：LLM 輸出的格式漂移、型別不匹配或語法錯誤會導致下游處理崩潰
草稿：
## LLM 輸出驗證
在重用 LLM 輸出之前，進行標準化、型別檢查和消毒...
請參閱技能：parallel-subagent-batch-merge, llm-memory-trust-boundary
[... 候選 2-4 的詳細資料 ...]
請根據編號核准、修改或跳過各候選：
> 使用者：Approve 1, 3. Skip 2, 4.
✓ 已套用：coding-style.md §LLM 輸出驗證
✓ 已套用：performance.md §Context Window 管理
✗ 已跳過：迭代界限
✗ 已跳過：邊界型別轉換
結果已儲存至 results.json
設計原則
- 做什麼，而非怎麼做：僅提取原則（規則領域）。程式碼範例和指令保留在技能中。
- 反向連結：草稿文字應包含
請參閱技能：[名稱]的參考，以便讀者找到詳細的「怎麼做」。 - 確定性收集，LLM 判斷：腳本保證徹底性；LLM 保證上下文理解。
- 防止過度抽象化：三層過濾（2+ 技能的證據、可操作行為測試、違規風險）可防止過於抽象的原則進入規則。