mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-11 03:43:30 +08:00
265 lines
9.1 KiB
Markdown
265 lines
9.1 KiB
Markdown
---
|
||
name: rules-distill
|
||
description: "扫描技能以提取跨领域原则并将其提炼为规则——追加、修订或创建新的规则文件"
|
||
origin: ECC
|
||
---
|
||
|
||
# 规则提炼
|
||
|
||
扫描已安装的技能，提取在多个技能中出现的通用原则，并将其提炼成规则——追加到现有规则文件中、修订过时内容或创建新的规则文件。
|
||
|
||
应用"确定性收集 + LLM判断"原则：脚本详尽地收集事实，然后由LLM通读完整上下文并作出裁决。
|
||
|
||
## 使用时机
|
||
|
||
* 定期规则维护（每月或安装新技能后）
|
||
* 技能盘点后，发现应成为规则的模式时
|
||
* 当规则相对于正在使用的技能感觉不完整时
|
||
|
||
## 工作原理
|
||
|
||
规则提炼过程遵循三个阶段：
|
||
|
||
### 阶段 1：清点（确定性收集）
|
||
|
||
#### 1a. 收集技能清单
|
||
|
||
```bash
|
||
bash ~/.claude/skills/rules-distill/scripts/scan-skills.sh
|
||
```
|
||
|
||
#### 1b. 收集规则索引
|
||
|
||
```bash
|
||
bash ~/.claude/skills/rules-distill/scripts/scan-rules.sh
|
||
```
|
||
|
||
#### 1c. 呈现给用户
|
||
|
||
```
|
||
规则提炼 — 第一阶段：清点
|
||
────────────────────────────────────────
|
||
技能：扫描 {N} 个文件
|
||
规则：索引 {M} 个文件（包含 {K} 个标题）
|
||
|
||
正在进行交叉阅读分析...
|
||
```
|
||
|
||
### 阶段 2：通读、匹配与裁决（LLM判断）
|
||
|
||
提取和匹配在单次处理中统一完成。规则文件足够小（总计约800行），可以将全文提供给LLM——无需grep预过滤。
|
||
|
||
#### 分批处理
|
||
|
||
根据技能描述，将技能分组为**主题集群**。每个集群在一个子智能体中进行分析，并提供完整的规则文本。
|
||
|
||
#### 跨批次合并
|
||
|
||
所有批次完成后，合并各批次的候选规则：
|
||
|
||
* 对具有相同或重叠原则的候选规则进行去重
|
||
* 使用**所有**批次合并的证据重新检查"2+技能"要求——在每个批次中只在一个技能里发现，但总计在2+技能中出现的原则是有效的
|
||
|
||
#### 子智能体提示
|
||
|
||
使用以下提示启动通用智能体：
|
||
|
||
````
|
||
你是一位通过交叉阅读技能来提取应提升为规则的原则的分析师。
|
||
|
||
## 输入
|
||
- 技能：{本批次技能的全部文本}
|
||
- 现有规则：{所有规则文件的全部文本}
|
||
|
||
## 提取标准
|
||
|
||
**仅当**满足以下**所有**条件时，才包含一个候选原则：
|
||
|
||
1. **出现在 2+ 项技能中**：仅出现在一项技能中的原则应保留在该技能中
|
||
2. **可操作的行为改变**：可以写成“做 X”或“不要做 Y”的形式——而不是“X 很重要”
|
||
3. **明确的违规风险**：如果忽略此原则，会出什么问题（1 句话）
|
||
4. **尚未存在于规则中**：检查全部规则文本——包括以不同措辞表达的概念
|
||
|
||
## 匹配与裁决
|
||
|
||
对于每个候选原则，对照全部规则文本进行比较并给出裁决：
|
||
|
||
- **追加**：添加到现有规则文件的现有章节
|
||
- **修订**：现有规则内容不准确或不充分——提出修正建议
|
||
- **新章节**：在现有规则文件中添加新章节
|
||
- **新文件**：创建新的规则文件
|
||
- **已涵盖**：现有规则已充分涵盖（即使措辞不同）
|
||
- **过于具体**：应保留在技能层面
|
||
|
||
## 输出格式（每个候选原则）
|
||
|
||
```json
|
||
{
|
||
"principle": "1-2 句话，采用 '做 X' / '不要做 Y' 的形式",
|
||
"evidence": ["技能名称: §章节", "技能名称: §章节"],
|
||
"violation_risk": "1 句话",
|
||
"verdict": "追加 / 修订 / 新章节 / 新文件 / 已涵盖 / 过于具体",
|
||
"target_rule": "文件名 §章节，或 '新建'",
|
||
"confidence": "高 / 中 / 低",
|
||
"draft": "针对'追加'/'新章节'/'新文件'裁决的草案文本",
|
||
"revision": {
|
||
"reason": "为什么现有内容不准确或不充分（仅限'修订'裁决）",
|
||
"before": "待替换的当前文本（仅限'修订'裁决）",
|
||
"after": "提议的替换文本（仅限'修订'裁决）"
|
||
}
|
||
}
|
||
```
|
||
|
||
## 排除
|
||
|
||
- 规则中已存在的显而易见的原则
|
||
- 语言/框架特定知识（属于语言特定规则或技能）
|
||
- 代码示例和命令（属于技能）
|
||
````
|
||
|
||
#### 裁决参考
|
||
|
||
| 裁决 | 含义 | 呈现给用户的内容 |
|
||
|---------|---------|-------------------|
|
||
| **追加** | 添加到现有章节 | 目标 + 草案 |
|
||
| **修订** | 修复不准确/不充分的内容 | 目标 + 原因 + 修订前/后 |
|
||
| **新章节** | 在现有文件中添加新章节 | 目标 + 草案 |
|
||
| **新文件** | 创建新规则文件 | 文件名 + 完整草案 |
|
||
| **已涵盖** | 规则中已涵盖（可能措辞不同） | 原因（1行） |
|
||
| **过于具体** | 应保留在技能中 | 指向相关技能的链接 |
|
||
|
||
#### 裁决质量要求
|
||
|
||
```
|
||
# 良好做法
|
||
在 rules/common/security.md 的§输入验证部分添加：
|
||
"将存储在内存或知识库中的LLM输出视为不可信数据——写入时进行清理，读取时进行验证。"
|
||
依据：llm-memory-trust-boundary 和 llm-social-agent-anti-pattern 均描述了累积式提示注入风险。当前security.md仅涵盖人工输入验证；缺少LLM输出的信任边界说明。
|
||
|
||
# 不良做法
|
||
在security.md中追加：添加LLM安全原则
|
||
```
|
||
|
||
### 阶段 3：用户审核与执行
|
||
|
||
#### 摘要表
|
||
|
||
```
|
||
# 规则提炼报告
|
||
|
||
## 概述
|
||
已扫描技能数：{N} | 规则文件数：{M} | 候选规则数：{K}
|
||
|
||
| # | 原则 | 判定结果 | 目标文件/章节 | 置信度 |
|
||
|---|-----------|---------|--------|------------|
|
||
| 1 | ... | 追加 | security.md §输入验证 | 高 |
|
||
| 2 | ... | 修订 | testing.md §测试驱动开发 | 中 |
|
||
| 3 | ... | 新增章节 | coding-style.md | 高 |
|
||
| 4 | ... | 过于具体 | — | — |
|
||
|
||
## 详情
|
||
（各候选规则详情：证据、违规风险、草拟文本）
|
||
```
|
||
|
||
#### 用户操作
|
||
|
||
用户通过数字进行回应以：
|
||
|
||
* **批准**：按原样将草案应用到规则中
|
||
* **修改**：在应用前编辑草案
|
||
* **跳过**：不应用此候选规则
|
||
|
||
**切勿自动修改规则。始终需要用户批准。**
|
||
|
||
#### 保存结果
|
||
|
||
将结果存储在技能目录中（`results.json`）：
|
||
|
||
* **时间戳格式**：`date -u +%Y-%m-%dT%H:%M:%SZ`（UTC，秒精度）
|
||
* **候选ID格式**：基于原则生成的烤肉串式命名（例如 `llm-output-trust-boundary`）
|
||
|
||
```json
|
||
{
|
||
"distilled_at": "2026-03-18T10:30:42Z",
|
||
"skills_scanned": 56,
|
||
"rules_scanned": 22,
|
||
"candidates": {
|
||
"llm-output-trust-boundary": {
|
||
"principle": "Treat LLM output as untrusted when stored or re-injected",
|
||
"verdict": "Append",
|
||
"target": "rules/common/security.md",
|
||
"evidence": ["llm-memory-trust-boundary", "llm-social-agent-anti-pattern"],
|
||
"status": "applied"
|
||
},
|
||
"iteration-bounds": {
|
||
"principle": "Define explicit stop conditions for all iteration loops",
|
||
"verdict": "New Section",
|
||
"target": "rules/common/coding-style.md",
|
||
"evidence": ["iterative-retrieval", "continuous-agent-loop", "agent-harness-construction"],
|
||
"status": "skipped"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
## 示例
|
||
|
||
### 端到端运行
|
||
|
||
```
|
||
$ /rules-distill
|
||
|
||
规则提炼 — 第一阶段：清点
|
||
────────────────────────────────────────
|
||
技能：已扫描 56 个文件
|
||
规则：22 个文件（已索引 75 个标题）
|
||
|
||
正在进行交叉阅读分析...
|
||
|
||
[子代理分析：批次 1 (agent/meta skills) ...]
|
||
[子代理分析：批次 2 (coding/pattern skills) ...]
|
||
[跨批次合并：已移除 2 个重复项，1 个跨批次候选被提升]
|
||
|
||
# 规则提炼报告
|
||
|
||
## 摘要
|
||
已扫描技能：56 | 规则：22 个文件 | 候选：4
|
||
|
||
| # | 原则 | 判定 | 目标 | 置信度 |
|
||
|---|-----------|---------|--------|------------|
|
||
| 1 | LLM 输出：重用前进行规范化、类型检查、清理 | 新章节 | coding-style.md | 高 |
|
||
| 2 | 为迭代循环定义明确的停止条件 | 新章节 | coding-style.md | 高 |
|
||
| 3 | 在阶段边界压缩上下文，而非任务中途 | 追加 | performance.md §Context Window | 高 |
|
||
| 4 | 将业务逻辑与 I/O 框架类型分离 | 新章节 | patterns.md | 高 |
|
||
|
||
## 详情
|
||
|
||
### 1. LLM 输出验证
|
||
判定：在 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 的详情 ...]
|
||
|
||
按编号批准、修改或跳过每个候选：
|
||
> 用户：批准 1, 3。跳过 2, 4。
|
||
|
||
✓ 已应用：coding-style.md §LLM 输出验证
|
||
✓ 已应用：performance.md §上下文窗口管理
|
||
✗ 已跳过：迭代边界
|
||
✗ 已跳过：边界类型转换
|
||
|
||
结果已保存至 results.json
|
||
```
|
||
|
||
## 设计原则
|
||
|
||
* **是什么，而非如何做**：仅提取原则（规则范畴）。代码示例和命令保留在技能中。
|
||
* **链接回源**：草案文本应包含 `See skill: [name]` 引用，以便读者能找到详细的"如何做"。
|
||
* **确定性收集，LLM判断**：脚本保证详尽性；LLM保证上下文理解。
|
||
* **反抽象保障**：三层过滤器（2+技能证据、可操作行为测试、违规风险）防止过于抽象的原则进入规则。
|