everything-claude-code/docs/ja-JP/skills/rules-distill/SKILL.md

---
name: rules-distill
description: "スキルをスキャンしてドメイン横断的な原則を抽出し、ルールに蒸留する——既存のルールファイルへの追記、修正、または新規作成"
origin: ECC
---

# ルール蒸留

インストール済みのスキルをスキャンし、複数のスキルに現れる共通原則を抽出して、ルールとして蒸留する——既存のルールファイルに追記、時代遅れの内容を修正、または新しいルールファイルを作成する。

「決定論的収集 + LLM判断」原則を適用する：スクリプトが事実を網羅的に収集し、その後LLMが完全なコンテキストを通読して裁決を下す。

## 使用場面

* 定期的なルールメンテナンス（月次または新しいスキルのインストール後）
* スキル棚卸し後、ルールにすべきパターンが見つかった場合
* 使用中のスキルと比較してルールが不完全に感じられる場合

## 動作原理

ルール蒸留プロセスは3つのフェーズに従う：

### フェーズ 1：棚卸し（決定論的収集）

#### 1a. スキルインベントリの収集

```bash
bash ~/.claude/skills/rules-distill/scripts/scan-skills.sh
```

#### 1b. ルールインデックスの収集

```bash
bash ~/.claude/skills/rules-distill/scripts/scan-rules.sh
```

#### 1c. ユーザーへの提示

```
ルール蒸留 — フェーズ 1：棚卸し
────────────────────────────────────────
スキル：{N} 個のファイルをスキャン
ルール：{M} 個のファイルをインデックス化（{K} 個の見出しを含む）

クロスリーディング分析を実行中...
```

### フェーズ 2：通読、マッチング、裁決（LLM判断）

抽出とマッチングは単一の処理で統合的に行われる。ルールファイルは十分に小さく（合計約800行）、LLMに全文を提供できる——grepによる事前フィルタリングは不要。

#### バッチ処理

スキルの説明に基づいてスキルを**トピッククラスター**にグループ化する。各クラスターは、完全なルールテキストを提供されたサブエージェントで分析される。

#### バッチ間のマージ

全バッチ完了後、バッチ候補をマージする：

* 同一または重複する原則を持つ候補を重複排除する
* 「2+スキル」要件を**全**バッチの統合証拠で再確認——各バッチでは1つのスキルにのみ現れるが、合計で2+スキルに現れる原則は有効

#### サブエージェントプロンプト

汎用エージェントを起動するために以下のプロンプトを使用する：

````
あなたはスキルをクロスリーディングして、ルールに昇格すべき原則を抽出するアナリストです。

## 入力
- スキル：{このバッチのスキルの全文}
- 既存のルール：{全ルールファイルの全文}

## 抽出基準

**以下の条件を全て**満たす場合のみ候補原則を含める：

1. **2+スキルに現れる**：1つのスキルにのみ現れる原則はそのスキルに留める
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

ルール蒸留 — フェーズ 1：棚卸し
────────────────────────────────────────
スキル：56個のファイルをスキャン済み
ルール：22個のファイル（75個の見出しをインデックス化）

クロスリーディング分析を実行中...

[サブエージェント分析：バッチ 1 (agent/meta スキル) ...]
[サブエージェント分析：バッチ 2 (coding/pattern スキル) ...]
[バッチ間マージ：2件の重複を削除、1件のクロスバッチ候補が昇格]

# ルール蒸留レポート

## サマリー
スキャン済みスキル：56 | ルール：22個のファイル | 候補：4

| # | 原則 | 判定 | ターゲット | 信頼度 |
|---|-----------|---------|--------|------------|
| 1 | LLM出力：再利用前に正規化、型チェック、サニタイズ | 新セクション | coding-style.md | 高 |
| 2 | 反復ループに明示的な停止条件を定義する | 新セクション | coding-style.md | 高 |
| 3 | タスクの途中ではなくフェーズ境界でコンテキストを圧縮する | 追記 | performance.md §コンテキストウィンドウ | 高 |
| 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 に結果を保存済み
```

## 設計原則

* **何をするかではなく、何か**：原則のみを抽出する（ルールの範囲）。コード例とコマンドはスキルに留める。
* **ソースへのリンクを維持**：草案テキストには `参照スキル：[名前]` への参照を含め、読者が詳細な「どうするか」を見つけられるようにする。
* **決定論的収集、LLM判断**：スクリプトが網羅性を保証し、LLMがコンテキスト理解を保証する。
* **抽象化防止策**：3層フィルター（2+スキルの証拠、実行可能行動テスト、違反リスク）により、過度に抽象的な原則がルールに入ることを防ぐ。