ルール抽出

インストール済みのスキルをスキャンして、複数のスキルに現れる汎用原則を抽出し、それらをルール化する——既存のルールファイルに追加、古い内容を修訂、または新しいルールファイルを作成します。

「確定的収集 + LLM判断」の原則を適用します：スクリプトが詳細に事実を収集してから、LLMが完全なコンテキストを読み通して判定を下します。

使用時機

• 定期的なルール保守（毎月またはスキルインストール後）
• スキル棚卸し後に、ルール化すべきパターンを発見したとき
• 使用中のスキルに比べてルールが不完全に感じるとき

仕組み

ルール抽出プロセスは3つの段階で進みます：

ステージ1：棚卸し（確定的収集）

1a. スキルリストを収集

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

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

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

1c. ユーザーに表示

ルール抽出 — ステージ1：棚卸し
────────────────────────────────────────
スキル：{N}個のファイルをスキャン
ルール：{M}個のファイルをインデックス（{K}個の見出しを含む）

クロスリード分析を実行中...

ステージ2：通読、マッチング、判定（LLM判断）

抽出とマッチングは単一の処理で統一的に行われます。ルールファイルは十分に小さい（総行数約800行）ため、LLMに完全なテキストを提供できます——grepによる事前フィルタリングは不要です。

バッチ処理

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

バッチ間の統合

すべてのバッチが完了した後、候補ルールを統合します：

• 同一または重複する原則を持つ候補ルールを重複排除
• すべてのバッチを統合した証拠で「2+スキル」要件を再確認——各バッチでは1スキルにしか見つからなくても、合計では2+スキルに出現する原則は有効です

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

次のプロンプトで汎用エージェントを起動します：

あなたはスキルをクロスリードしてルールに昇格させるべき原則を抽出する分析者です。

## 入力
- スキル：{このバッチのスキルの完全なテキスト}
- 既存ルール：{すべてのルールファイルの完全なテキスト}

## 抽出基準

以下の**すべての**条件を満たす場合**のみ**候補原則を含めてください：

1. **2+個の項目に出現**：1個のスキルにのみ出現する原則はそのスキルに保留する
2. **実行可能な動作変化**：「Xをする」または「Yをしない」の形式で書ける——「Xは重要」ではなく
3. **明確な違反リスク**：この原則を無視するとどうなるか（1文）
4. **ルールにまだ存在しない**：完全なルールテキストをチェック——異なる表現の概念を含む

## マッチングと判定

各候補原則について、完全なルールテキストと照合して判定を示してください：

- **追加**：既存のルールファイルの既存セクションに追加
- **修訂**：既存のルール内容が不正確または不充分——修正提案を提示
- **新セクション**：既存のルールファイルに新しいセクションを追加
- **新ファイル**：新しいルールファイルを作成
- **カバー済み**：既存のルールが十分カバー（表現は異なるかもしれません）
- **具体的すぎる**：スキルレベルに留まるべき

## 出力形式（各候補原則ごと）

```json
{
  "principle": "「Xをする」/「Yをしない」の形式での1-2文",
  "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 の両方が累積プロンプトインジェクション（CPI）リスクを説明しています。現在の 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）

{
  "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 に保存しました

設計原則

• 何を、どのようにではなく：原則のみを抽出（ルール範囲）。コード例とコマンドはスキルに留まります。
• ソースへのリンク：ドラフトテキストには See skill: [name] 参照を含める必要があり、読者が詳細な「方法」を見つけられるようにします。
• 確定的収集、LLM判断：スクリプトが完全性を保証し、LLMがコンテキスト理解を保証します。
• 過度な抽象化の防止：3つのフィルター（2+スキル証拠、実行可能性テスト、違反リスク）により、過度に抽象的な原則がルールに入るのを防ぎます。