Domain Knowledge Builder — 領域知識ベース生成器
N 個の論文 + ドメイン名 → クエリ可能な A 級ドメイン知識ベーススキルを生成します。 知識ベース構造：DAG（5 タイプのノード + 10 種類の関係）+ メンタルモデル + クエリプロトコル + 正直な限界。 品質ゲート：darwin 2.0 の 9 次元スコアリング、B+ (80) 以上で生成成功。
コアメンタルモデル
1. 知識 ≠ 定義の羅列
使えるドメイン知識ベースとは、定義や定理を単に並べたものではなく、そのドメインが世界を見るためのレンズ（メンタルモデル）を抽出し、知識ノードでそれを支えるものです。「私のデータフローは非可換ですが、CPはどのように助けてくれますか？」という質問に対して、純粋な定義の羅列では答えられませんが、メンタルモデル駆動の知識ベースは立場を推論できます。したがって、インジェストプロセスにはメンタルモデル抽出ステップ（S5）が必須であり、ノードの抽出だけでは不十分です。
2. Karpathy ライフサイクル × DAG 構造
- Karpathy LLM Wiki が提供する「ライフサイクル」：raw（不変のソース）→ wiki（LLM が維持）→ SCHEMA（標準仕様）の3層＋Ingest/Query/Lint の3つのワークフロー。知識ベースは成長する有機体であり、一度きりのスナップショットではありません。
- DAG が提供する「構造」：ノード間の関係は単なる分類ではなく、
guarantees（保証する）/generalizes（一般化する）/contradicts（矛盾する）/depends_on（依存する）といった関係です。定理 A が定理 B を導き、方法 C が方法 D と矛盾する、こうした関係こそがドメイン知識の核心であり、フラットなディレクトリ構造では表現できません。 - 融合：Karpathy は「知識がどう成長するか」（ライフサイクル）を、DAG は「知識がどう繋がるか」（構造）を管理します。
3. 生成器は制御可能でなければならない（D7）
メタスキル ≠ 通常スキル の本質は他のスキルを生成することであり、大規模なファイル書き込み、サブエージェントの spawn、ネットワーク通信が発生します。これらは制御可能でなければなりません：各インジェストはチェックポイントから復元可能、darwin のゲートを通過できなければ git revert 可能、各ノードは追跡可能（provenance）、同一の論文を再実行すれば同一のノード ID を生成（決定論）。そうでなければ、6 ヶ月後にメンテナンス不可能になります。これら 4 つの柱（ロールバック可能/監査可能/決定論的/事前チェック済み）は、generator-skill のコンプライアンス基準です（darwin 第 9 次元 generator サブクラス）。
使用する場合 / 使用しない場合
使用する場合：
- 「ある専門家のために、『専門家は X をどう見ているか』＋『なぜか（根拠）』を答えられるアドバイザースキルを作成する」
- 「専門家の論文/インタビュー/ブログを、メンタルモデルと知識の両エンジンを持つものに変換する」
- 「これらの論文をクエリ可能な知識ベースに変換する」
- 「X ドメイン用の DAG 知識ベースを作成する」
- 「N 個の PDF があり、立場を推論できるドメインアシスタントが欲しい」
ルーティングの区別：
- 純粋なドメイン知識ベース（専門家の視点不要）→ DKB 基本モード（
examples/conformal-prediction） - 専門家の視点（専門家の判断＋根拠が必要）→ 本拡張（expert-advisor モード）
使用しない場合（他のスキルにルーティング）：
- 「Split CP とは何ですか？」 → 既存の CP 知識ベースをクエリ（
examples/conformal-prediction） - 「この本を要約して」 → book-to-skill を使用して単一の本からスキルを直接生成
- 「ある人の考え方を蒸留する（ドメイン知識不要）」 → nuwa-skill を使用
アーキテクチャ（5 層）
domain-knowledge-skill/
├── SKILL.md # 本ファイル（メタスキルエントリポイント）
├── schema/schema.md # 知識仕様（5 タイプ + 10 関係 + D7 制御可能性）
├── pipeline/ # Ingest/Query/Lint ワークフロー
│ ├── ingest.md # 7 ステップパイプライン契約（S1-S7）
│ ├── query.md # 5 ステップ DAG トラバーサルクエリ
│ ├── lint.md # 構造 + Generator コンプライアンスチェック
│ ├── run-dag-pipeline.js # ワークフローオーケストレーションスクリプト
│ └── state/ # D7 ランタイム
│ ├── init_run.py # UUID + git + run-manifest + preflight
│ └── lint_d7.py # 4 本柱 Lint
├── engines/ # 再利用可能なエンジン
│ ├── book_to_skill/ # virgiliojr94 抽出エンジン（technical モード）
│ ├── darwin-rubric.md # 9 次元品質スコアリング（第 9 次元双子クラス）
│ └── nuwa-validation.md # ドメイン特化三重検証
├── references/ # テンプレート（計画中）
└── examples/
└── conformal-prediction/ # ゴールデンリファレンス（88 点 A-、レイジーロード）
7 ステップ Ingest パイプライン（D3 段階別分割）
決定論的（workflow fan-out） 対話的/判断的（subagent chain）
───────────────────── ─────────────────────
S1 抽出 ──┬─▶ S2×N 並列 ──┐
└─▶ ... ├─▶ S3 マージ ──▶ S4 ナビゲーション ──▶ S5 メンタルモデル ──▶ S6 検証 ──▶ S7 組み立て ──▶ darwin ゲート
│ (contradicts (並列 3) (三重検証) (フレッシュ) (<4K) (≥B+)
│ 人間確認)
詳細な契約は pipeline/ingest.md を参照。重要な制約：
- S1 は docling preflight を必須とする（schema §12.4、technical モードのハード依存関係）
- S2 のノード ID は
<type>-<source>-<canonical-term>に従う（schema §10 決定論） - S3 で
contradicts/does_not_guaranteeエッジに遭遇した場合は、contact_supervisorによる人間の確認が必須 - S5 は
engines/nuwa-validation.mdをロードして三重検証を実施 - S6/S7 は fresh-context サブエージェント（独立した検証/スコアリング）を使用し、自己評価を禁止
- 全ステップで各ノードに provenance（生成元ステップ/run_id/ソーススパン）を記録
品質ゲート（darwin 2.0、9 次元）
engines/darwin-rubric.md をロードし、fresh-context サブエージェントがスコアリング：
| 次元 | 重み | 注目点 |
|---|---|---|
| ① 構造的完全性 ② 明確性 ③ 内容の完全性 ④ 操作性 | 15%×4 | frontmatter/ワークフロー/カバレッジ/実行可能性 |
| ⑤ 正確性 ⑥ 一貫性 | 10%×2 | 定理の原文精度/途切れた引用がない |
| ⑦ 実行効率 ⑧ ロバスト性 | 8%/7% | トークン予算/正直な限界 |
| ⑨ メタスキルコンプライアンス | 5% | generator-skill サブクラス：4 本柱 |
第 9 次元双子クラス（oracle インサイト）：query-skill（CP タイプ、読み取り専用）vs generator-skill（本スキルタイプ、制御された書き込みを許可するが、4 本柱（ロールバック可能/監査可能/決定論的/事前チェック）を満たす必要あり）。これにより生成器も公平に品質ゲートを通過できます。
ラチェットメカニズム：darwin < B+ → 最後のステージを git revert → 低スコア次元を診断 → 修正して再評価。3 ラウンド連続で改善がない場合 → 探索的な書き換えを提案。
5 つの参照元の行き先
| ソース | 行き先 | 再利用方法 |
|---|---|---|
| Karpathy LLM Wiki | schema/ + pipeline/ | クリーンな継承：3 層アーキテクチャ + Ingest/Query/Lint ライフサイクル |
| book-to-skill | engines/book_to_skill/ | クリーンなベンダリング：抽出エンジン（technical モードは数式を保持） |
| nuwa-skill | engines/nuwa-validation.md | 方法論の抽出：三重検証（expression DNA を除去） |
| darwin-skill | engines/darwin-rubric.md | デュアルソースの再構築：validation-report の 9 次元 + 旧版 8 次元の対照 |
| dag-executor | 哲学的な参照のみ | wave-based 並列処理 + ファイルロック（実装には pi workflow/subagent を使用） |
examples/conformal-prediction（ゴールデンリファレンス）
レイジーロード — デフォルトのスキルルーティングには参加せず、明示的なリクエストでアクティブ化：
- v1.1.0 / 50 ノード / 138 エッジ / 0 断裂 / darwin 88 点（A-）
- 3 つのソース（Angelopoulos 2022 / Teneggi 2025 / Min 2026）
- 用途：(1) 新しいドメインのインジェスト時の品質ベンチマークとして；(2) ユーザーが明示的に「共形予測」をクエリしたときにロード
制約と正直な限界
ハード制約：
- docling は technical モードのハード依存関係（学術論文に数式がなければ価値がないため、犠牲にできない）
- SKILL.md の本文は <4K トークン（圧縮は末尾から切り捨て）
- すべてのノードに provenance を必須とする（新しいインジェスト時）
- 生成されたスキルのパスは、skill-root-relative パスのみを使用する（リンク切れ防止）
できないこと：
- 直感を蒸留することはできない — フレームワークは抽出できても、インスピレーションは抽出できない
- ドメインの全論文をカバーすることはできない — ユーザーが提供したソースのみをカバー
- ソースの品質を自動判断することはできない — ガベージイン、ガベージアウト（低品質の論文 → 低品質の知識ベース）
- 専門家の判断を代替することはできない —
contradictsエッジは人間の確認が必須
既知の限界：
- docling のバージョン違いにより、抽出品質が静かに低下する可能性がある（テストでキャッチされない）
- canonical-term の LLM による抽出は完全に決定論的ではない（同じ論文を 2 回抽出するとハッシュが異なる可能性があり、Lint が報告する）
- 大きな論文（>50K トークン）の抽出コストが高い（バッチインジェストを推奨）
クイックスタート
ユーザー: diffusion-models ドメインの知識ベースを作成して。論文は ~/papers/ddpm.pdf、~/papers/score-sde.pdf にあります。
→ 本スキルの動作:
1. ドメイン + ソースを確認し、docling preflight を実行
2. 7 ステップパイプラインを実行（pipeline/ingest.md）
3. darwin でスコアリング、B+ 以上なら生成されたスキルを ~/.pi/agent/skills/diffusion-models/ に配置
4. ユーザーは後でその生成されたスキルをクエリ可能
詳細な契約は pipeline/ingest.md を参照。
本メタスキルバージョン：v0.1 | 5 つのソースを再利用 + D7 制御可能性 + darwin 2.0 品質ゲート | ゴールデンリファレンス：examples/conformal-prediction (88/A-)