あなたは既存の知識システムを新しいドメインで拡張しています。これは置き換えではなく、構成（composition）です。新しいドメインは、独自の語彙、スキーマ、処理パターンを維持しながら、既存のドメインと共存する必要があります。共有グラフ（ウィキリンク、ハブMOC、説明フィールド）がすべてを接続します。
あなたのタスク
新しい知識ドメインを追加する: $ARGUMENTS
参照ファイル
導出フェーズ中にこれらを参照してください:
構成ルール:
${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md-- テスト4（マルチドメイン構成）がパターンを検証します${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md-- 3スペースアーキテクチャ（全ドメインで共有）${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md-- ドメイン設定のコヒーレンス検証
ドメイン設定:
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md-- ドメインネイティブ用語マッピング${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md-- 事前検証済みのドメイン設定${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md-- 設定付き3つのプリセット${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md-- 次元位置の研究背景${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md-- ドメイン脆弱性マトリックス
検証:
${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml-- 12の譲れないプリミティブ${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh-- カーネル検証スクリプト
フェーズ1: 既存システムのスキャン
自動化。追加する前に何が存在するかを理解します。
1a. システム設定を読み取る
ops/derivation.md を読み取り、以下を確認:
- 現在の次元位置
- 語彙マッピング
- プラットフォームと自動化レベル
- アクティブな機能ブロック
ops/config.yaml を読み取り、実際の設定値を確認。
1b. 既存ドメインの棚卸し
現在のすべての知識ドメインを特定:
- プライマリノートフォルダとそのドメイン語彙
- 既存のセカンダリドメイン（フォルダ、テンプレート、MOC）
- ドメインごとに使用されているスキーマフィールド
1c. 次元タイプを特定
8つの次元それぞれをシステムレベルまたはドメイン調整可能に分類:
| 次元 | タイプ | 根拠 |
|---|---|---|
| 組織 (Organization) | システムレベル | フラット/階層はワークスペース全体に適用 |
| 自動化 (Automation) | システムレベル | フックとスキルはワークスペース全体のインフラ |
| ナビゲーション深度 | システムレベル | ハブMOC構造は共有 |
| 細粒度 (Granularity) | ドメイン調整可能 | ドメインごとに異なる細粒度が必要な場合がある |
| 処理 (Processing) | ドメイン調整可能 | 研究は重く、関係は軽く |
| メンテナンス (Maintenance) | ドメイン調整可能 | ドメインの成長率に応じて異なる条件しきい値 |
| スキーマ (Schema) | ドメイン調整可能 | ドメイン固有フィールドは異なる |
| リンキング (Linking) | ドメイン調整可能 | セマンティック検索が必要なドメインと不要なドメインがある |
システムレベルの次元は既存システムによって固定されます。ドメイン調整可能な次元は、新しいドメイン用に変更できます。
フェーズ2: 会話
新しいドメインを理解するための1〜3ターンの会話。各ターンで AskUserQuestion を使用します。
最初の質問
新しいドメインについて焦点を絞った質問を1つします:
「[ドメインヒント from $ARGUMENTS] について教えてください -- どのようなものを追跡しますか？また、それは既存の [現在のドメイン語彙] の作業とどのように関連しますか？」
後半が重要です。ドメイン間の関係を理解することで、構成の決定が導かれます。
シグナルの抽出
ユーザーが応答する際、ドメイン調整可能な次元のシグナルを抽出します:
| シグナル | 次元 | 位置 |
|---|---|---|
| 「人についてのクイックノート」 | 細粒度 | moderate |
| 「セッションの詳細な分析」 | 処理 | heavy |
| 「重要な瞬間を覚えておくだけ」 | 処理 | light |
| 「よく再訪して更新する」 | メンテナンス | 厳しいしきい値 |
| 「一度キャプチャしたらほぼ静的」 | メンテナンス | 緩いしきい値 |
| 「エントリ間のパターンを見つける必要がある」 | リンキング | 明示的+暗黙的 |
また以下も抽出:
- ボリューム見積もり -- 処理バッチあたりのノート数
- 時間的ダイナミクス -- コンテンツの変化速度
- 語彙 -- ノート、プロセス、組織化に関するユーザー自身の言葉
- クロスドメイン関係 -- 既存のドメインとの関連性
フォローアップ戦略
最初の応答後、以下の点をターゲットにした1〜2のフォローアップを質問:
- 語彙の確認 -- "「[ユーザーの言葉]」と言うとき、個々の洞察のことですか、それとも長めのエントリーのことですか？"
- クロスドメイン接続パターン -- "[新しいドメイン]のノートは、[既存ドメイン]のノートと接続しますか？どのように？"
次元について直接質問しないでください。自然な会話の中でそれらを聞き出してください。
フェーズ3: ドメイン設定の導出
3a. シグナルをドメイン調整可能な次元にマッピング
調整可能な次元ごとに、新しいドメインの位置を決定:
- ユーザーシグナル（最優先）
${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.mdから最も近いユースケースプリセット- システムレベルの次元からのカスケード
3b. 語彙マッピングの構築
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md を読み、変換テーブルを確認。
優先順位:
- 会話からのユーザー自身の言葉
- ユースケースプリセットの語彙
- 最も近い参照ドメインのブレンド
新しいドメインの完全なマッピングを構築:
| 普遍用語 | 新しいドメイン用語 | 出典 |
|---|---|---|
| ノート (note) | [用語] | [ユーザー / プリセット / ブレンド] |
| 抽出 / 削減 (extract / reduce) | [用語] | [ユーザー / プリセット / ブレンド] |
| 接続 / 反映 (connect / reflect) | [用語] | [ユーザー / プリセット / ブレンド] |
| MOC | [用語] | [ユーザー / プリセット / ブレンド] |
| 説明 (description) | [用語] | [ユーザー / プリセット / ブレンド] |
| トピック (topics) | [用語] | [ユーザー / プリセット / ブレンド] |
| 受信ボックス (inbox) | [用語] | [ユーザー / プリセット / ブレンド] |
3c. ドメイン固有スキーマの設計
基本ノートスキーマ（説明、トピック）から始め、ドメイン固有フィールドを追加:
_schema:
entity_type: "[ドメイン]-ノート"
applies_to: "[ドメインフォルダ]/*.md"
required:
- description
- topics
optional:
- [会話シグナルに基づくドメイン固有フィールド]
enums:
[field]:
- [ドメイン関連の値]
3d. 衝突チェック
これはマルチドメイン構成にとって重要です。 以下を確認:
-
ファイル名の一意性 -- 新しいドメインのノートタイトルが既存ノートと衝突しない。ウィキリンクはワークスペース全体でファイル名によって解決されるため、すべてのファイル名は一意である必要があります。
-
スキーマフィールド名 -- 新しいドメインフィールドが既存ドメインフィールドと競合しない。両方のドメインが同じフィールド名（例：
type）を使用する場合、enum値は相互に排他的であるか、フィールドに互換性のあるセマンティクスが必要です。 -
テンプレート名 -- 新しいドメインテンプレートに既存テンプレートと異なる名前が付けられていること。
-
フォルダ名 -- 新しいドメインフォルダが既存フォルダと衝突しないこと。
衝突が検出された場合は、先に進む前に解決してください。
フェーズ4: 構成ルールのチェック
${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md（テスト4: マルチドメイン構成）を読み、検証済みの構成パターンを確認。
各構成ルールを検証:
ルール1: ウィキリンクが共有名前空間で曖昧さなく解決される
すべてのノートファイル名は、すべてのドメインで一意である必要があります。新しいドメインの命名規則は既存のものと互換性がある必要があります。
ルール2: ハブMOCがすべてのドメインMOCにリンクする
既存のハブMOC（index.md または同等のもの）は、新しいドメインのエントリポイントMOCを含むように更新される必要があります。階層は次のようになります:
hub -> 既存のドメインMOC
-> 新しいドメインMOC
ルール3: クロスドメインの反映（リフレクト）がすべてのノートフォルダを検索する
接続検出（リフレクト）がアクティブな場合、すべてのドメインを検索する必要があります。新しいドメインのノートが既存ドメインのノートに接続する可能性があります。セマンティック検索コレクションには新しいドメインフォルダを含める必要があります。
ルール4: ドメイン固有の処理が共存できる
新しいドメインに既存ドメインとは異なる処理強度が必要な場合、パイプラインはノートタイプでルーティングする必要があります。研究ノートには重い処理、関係ノートには軽い処理など。
ルール5: コンテキストファイルの読み込みは段階的である
新しいドメインの方法論ガイドは、そのドメインで作業しているときのみ読み込まれ、セッション開始ごとには読み込まれないようにする必要があります。これにより、ドメインが蓄積されるにつれてコンテキストが肥大化するのを防ぎます。
コヒーレンスチェック
${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md を通じて新しいドメインの設定を実行:
- 新しいドメイン設定とシステムレベルの次元間のハード制約違反
- 新しいドメイン固有のソフト制約警告
- 既存ドメインへのカスケード効果
フェーズ5: 提案の提示
作成されるものと、それが既存のものにどのように接続されるかをユーザーに正確に示します。
出力形式:
=== ドメイン追加提案 ===
新しいドメイン: [ドメイン名]
語彙: [主要な用語マッピング]
--- 作成されるもの ---
フォルダ構造:
[ドメインフォルダ]/ <- [説明]
index.md <- ドメインハブMOC
[ドメイン受信ボックス]/ <- キャプチャゾーン（処理 >= moderate の場合）
テンプレート/[ドメイン]-ノート.md <- ドメインスキーマ付きノートテンプレート
--- 既存システムへの接続 ---
- ハブMOC (index.md): [[ドメイン-インデックス]]へのリンクを含む[新しいドメイン]セクションを追加
- クロスドメインリンク: 新しいドメインのノートは既存ドメインのノートにリンク可能、その逆も可
- 共有インフラ: self/、ops/、templates/ は共有のまま
- セマンティック検索: [現在のボリュームでは新しいコレクション追加 / 不要]
--- 変更されないもの ---
- 既存の [ドメイン] フォルダ: 変更なし
- 既存のテンプレート: 変更なし
- 既存のMOC階層: 変更なし（ハブは1つの新しいリンクを獲得）
- self/ スペース: 共有（methodology.md がマルチドメインパターンで更新される）
- ops/ スペース: 共有（derivation.md がドメイン追加で更新される）
--- ドメイン設定 ---
| 次元 | 位置 | 根拠 |
|---|---|---|
| 細粒度 | [値] | [理由] |
| 処理 | [値] | [理由] |
| メンテナンス | [値] | [理由] |
| スキーマ | [値] | [理由] |
| リンキング | [値] | [理由] |
| （システムレベルの次元は既存システムから継承） |
--- スキーマプレビュー ---
[新しいドメインテンプレートの_schemaブロックを表示]
--- 語彙マッピング ---
| 普遍用語 | 新しいドメイン | 既存ドメイン |
|---|---|---|
| ノート | [用語] | [既存の用語] |
| ... | ... | ... |
これを作成しますか？ 作成前に調整できます。
=== 提案終了 ===
先に進む前にユーザーの承認を待ちます。
フェーズ6: 生成
新しいドメインのインフラストラクチャを作成します。順序が重要です -- 後続のアーティファクトは以前のものを参照します。
ステップ1: ドメインフォルダ構造
ドメインのノートフォルダとオプションの受信ボックスフォルダを作成:
mkdir -p [ドメインフォルダ]
mkdir -p [ドメイン受信ボックス] # 処理 >= moderate の場合
ステップ2: ドメインノートテンプレート
導出された _schema ブロック、必須およびオプションフィールド、コメントと例にドメイン語彙が含まれた templates/[ドメイン]-ノート.md を作成。
ステップ3: ドメインハブMOC
[ドメインフォルダ]/index.md を作成:
---
description: [ドメイン語彙でのエントリポイント説明]
type: moc
---
# インデックス
[ドメイン語彙でのオリエンテーション段落]
## [ドメイン:トピック]
（トピックはノートが蓄積されるにつれて出現します）
## はじめに
1. 最初の[ドメイン:ノート]をキャプチャする
2. このハブに接続する
ステップ4: ドメインガイド
このドメインで作業するときに読み込まれる、ドメイン固有の方法論文書を作成。Claude Codeの場合: .claude/skills/[ドメイン]-ガイド/SKILL.md またはコンテキストファイル内のセクション。他のプラットフォームの場合: スタンドアロンガイドファイル。
ガイドの内容:
- このドメインでのキャプチャ方法
- 処理方法（導出された強度で）
- クロスドメイン接続を行うタイミング
- ドメイン固有の品質基準
- ドメイン語彙リファレンス
ステップ5: ハブMOCの更新
新しいドメインを既存のハブMOC（index.md）に追加:
## [新しいドメイン名]
- [[ドメイン-インデックス]] -- [このドメインが追跡するものの説明]
ステップ6: コンテキストファイルの更新
コンテキストファイルに以下を追加:
- ドメインルーティング: [ドメイン]で作業する場合、[ドメインガイド]を読み込む
- 語彙: 新しいドメイン用語を語彙リファレンスに追加
- 処理: 異なる処理強度がある場合、ルーティングを文書化
- クロスドメインリンキング: クロスドメイン接続を行うタイミングと方法
ステップ7: self/methodology.md の更新
マルチドメイン作業パターンを追加:
- ドメイン間の切り替え方法
- クロスドメイン接続を作成するタイミング
- ドメインごとの処理トリガー
ステップ8: ops/derivation.md の更新
ドメイン追加を文書化:
- 新しいドメイン名と語彙
- 根拠付きドメイン調整可能次元の位置
- 検証済みの構成ルール
- クロスドメイン接続パターン
- 追加の日付とコンテキスト
ステップ9: セマンティック検索の更新（設定されている場合）
qmd または同等のものが設定されている場合:
# ドメインフォルダ用の新しいコレクションを追加
qmd update
qmd embed
新しいコレクションを含むように .mcp.json または同等の設定を更新。
ステップ10: ドメイン処理スキル（処理 >= moderate の場合）
新しいドメインに独自の処理スキルが必要な場合（処理強度または語彙が既存ドメインと異なるため）、ドメイン適応版の削減/反映/検証スキルを生成。
既存のスキルがノートタイプによるマルチドメインルーティングを処理できる場合は、複製を作成せずに既存のスキルを更新。
フェーズ7: 検証
新しいドメインファイルのカーネルチェック
新しいドメインファイルに対してカーネル検証を実行:
- すべての新しいファイルでYAMLフロントマターが有効であること
- 新しいファイルからのウィキリンクが解決されること（クロスドメインリンクを含む）
- 新しいドメインMOCがハブから到達可能であること
- 説明フィールドが存在すること
- トピックフッターがドメインMOCを参照していること
構成検証
- フィールド競合なし -- すべてのテンプレートのフィールド名をgrepし、セマンティック競合がないことを確認
- ハブ到達可能性 -- ハブMOCがすべてのドメインMOCにリンクし、すべてのドメインMOCが自身のノートにリンクしていること
- クロスドメインリンクテスト -- 新しいドメインから既存ドメインへのテストリンクを作成し、解決されることを確認
- ファイル名の一意性 -- ドメイン全体で重複ファイル名がないことを確認:
find . -name "*.md" | grep -E '^\[ドメインフォルダ\]/' | sort > /tmp/new_domain_files.txt find . -name "*.md" | grep -v -E '^\[ドメインフォルダ\]/' | sort > /tmp/existing_files.txt comm -12 /tmp/new_domain_files.txt /tmp/existing_files.txt | head -20 # 出力が空でなければ重複がある