add-domain

既存のナレッジシステムに新しいドメインを追加します。これは置き換えではなく、組み合わせです。新しいドメインは、独自の語彙、スキーマ、処理パターンを維持しながら、既存のドメインと共存する必要があります。共有グラフ（Wiki リンク、ハブ 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 つの次元それぞれを、システムレベルまたはドメイン調整可能に分類します。

次元	種類	根拠
組織化	システムレベル	フラット型／階層型はワークスペース全体に適用されます
自動化	システムレベル	フックとスキルはワークスペース全体のインフラです
ナビゲーションの深さ	システムレベル	ハブ MOC 構造は共有されます
粒度	ドメイン調整可能	ドメインによって必要な粒度は異なります
処理	ドメイン調整可能	研究には重い処理、人間関係には軽い処理が必要です
メンテナンス	ドメイン調整可能	ドメインの成長速度によって条件のしきい値が異なります
スキーマ	ドメイン調整可能	ドメイン固有のフィールドはさまざまです
リンク	ドメイン調整可能	意味検索が必要なドメインもあれば、不要なドメインもあります

システムレベルの次元は既存システムによって固定されます。ドメイン調整可能な次元は、新しいドメインに合わせて変更できます。

---

フェーズ 2：会話

新しいドメインについて理解するため、1～3 回の会話を行います。各回で AskUserQuestion を使用してください。

最初の質問

新しいドメインについて、焦点を絞った質問を 1 つだけしてください。

「[domain hint from $ARGUMENTS] について教えてください。どのようなことを記録しますか？また、既存の [current domain vocabulary] の作業とどのように関係しますか？」

後半の質問が重要です。ドメイン同士の関係を理解することが、組み合わせ方の判断につながります。

シグナルの抽出

ユーザーの回答から、ドメインごとに調整可能な次元についてシグナルを抽出します。

シグナル	次元	位置
「人についての簡単なメモ」	粒度	中程度
「セッションの詳細な分析」	処理	重い
「重要な瞬間だけを記憶する」	処理	軽い
「頻繁に見返して更新する」	メンテナンス	しきい値を厳しく
「記録後はほぼ変化しない」	メンテナンス	しきい値を緩く
「記録をまたいでパターンを見つけたい」	リンク	明示的＋暗黙的

さらに、以下も抽出します。

• ボリュームの見積もり -- 1 回の処理バッチで何件のメモを扱うか
• 時間的な変化 -- コンテンツがどれほど速く変化するか
• 語彙 -- メモ、プロセス、整理についてユーザー自身が使う言葉
• ドメイン間の関係 -- 既存のドメインとどのようにつながるか

フォローアップの方針

最初の回答の後、以下を対象に 1～2 件のフォローアップを行います。

1. 語彙の確認 -- 「[ユーザーの言葉]と言うとき、個々の知見を指していますか、それとも長めの記録を指していますか？」
2. ドメイン間のつながり方 -- 「[新しいドメイン]のメモは、[既存のドメイン]のメモとつながりますか？ どのようにつながりますか？」

次元について直接質問してはいけません。自然な会話の中でシグナルを拾ってください。

---

フェーズ 3：ドメイン設定の導出

3a. シグナルをドメインごとに調整可能な次元に対応付ける

調整可能な各次元について、新しいドメインでの位置を決定します。

• ユーザーのシグナル（最優先）
• ${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md にある最も近いユースケースプリセット
• システムレベルの次元からのカスケード

3b. 語彙の対応付けを作成する

変換表については、${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md を読みます。

優先順位：

1. 会話でのユーザー自身の言葉
2. ユースケースプリセットの語彙
3. 最も近い参照ドメインの組み合わせ

新しいドメイン向けに、完全な対応表を作成します。

共通用語	新しいドメインの用語	出典
メモ	[用語]	[ユーザー／プリセット／組み合わせ]
抽出／要約	[用語]	[ユーザー／プリセット／組み合わせ]
つなげる／振り返る	[用語]	[ユーザー／プリセット／組み合わせ]
MOC	[用語]	[ユーザー／プリセット／組み合わせ]
説明	[用語]	[ユーザー／プリセット／組み合わせ]
トピック	[用語]	[ユーザー／プリセット／組み合わせ]
受信トレイ	[用語]	[ユーザー／プリセット／組み合わせ]

3c. ドメイン固有のスキーマを設計する

ベースのメモスキーマ（説明、トピック）から始め、ドメイン固有のフィールドを追加します。

_schema:
  entity_type: "[domain]-note"
  applies_to: "[domain-folder]/*.md"
  required:
    - description
    - topics
  optional:
    - [domain-specific fields based on conversation signals]
  enums:
    [field]:
      - [domain-relevant values]

3d. 衝突の確認

複数ドメインを組み合わせる際に、これは非常に重要です。 以下を確認します。

1. ファイル名の一意性 -- 新しいドメインのメモのタイトルが既存のメモと衝突しないこと。Wiki リンクはワークスペース全体でファイル名を基に解決されるため、すべてのファイル名を一意にする必要があります。

2. スキーマのフィールド名 -- 新しいドメインのフィールドが既存ドメインのフィールドと衝突しないこと。両方のドメインで同じフィールド名（例：type）を使う場合、列挙値を相互に排他的にするか、フィールドの意味を互換性のあるものにする必要があります。

3. テンプレート名 -- 新しいドメインのテンプレート名が既存のテンプレート名と異なること。

4. フォルダー名 -- 新しいドメインのフォルダー名が既存のフォルダー名と衝突しないこと。

衝突が見つかった場合は、先に解決してから進めてください。

---

フェーズ 4：組み合わせルールの確認

${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md を読み、検証済みの組み合わせパターンを確認します（テスト 4：複数ドメインの組み合わせ）。

各組み合わせルールを確認します。

ルール 1：共有名前空間で Wiki リンクが曖昧さなく解決される

すべてのドメインで、メモのファイル名を一意にする必要があります。新しいドメインの命名規則は既存の命名規則と互換性がなければなりません。

ルール 2：ハブ MOC がすべてのドメイン MOC にリンクする

既存のハブ MOC（index.md など）を更新し、新しいドメインのエントリーポイントとなる MOC を含める必要があります。階層は次のようになります。

hub -> existing domain MOCs
    -> new domain MOC

ルール 3：reflect で全ノートフォルダーを横断検索する

接続の発見（reflect）が有効な場合、すべてのドメインを横断して検索する必要があります。新しいドメインのノートが既存のドメインのノートとつながる可能性があるためです。セマンティック検索コレクションには、新しいドメインのフォルダーを含める必要があります。

ルール 4：ドメイン固有の処理は共存できる

新しいドメインで既存のドメインとは異なる処理強度が必要な場合、パイプラインはノートの種類に応じてルーティングする必要があります。調査ノートには重い処理を、関係性に関するノートには軽い処理を適用する、といった形です。

ルール 5：コンテキストファイルは段階的に読み込む

新しいドメインの方法論ガイドは、そのドメインで作業するときにのみ読み込み、各セッションの開始時には読み込まないようにします。これにより、ドメインが増えるにつれてコンテキストが肥大化するのを防げます。

整合性チェック

新しいドメインの設定を ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md で確認します。

• 新しいドメインの設定とシステムレベルの次元との間にあるハード制約違反
• 新しいドメイン固有のソフト制約に関する警告
• 既存のドメインへの波及効果

---

フェーズ 5：提案を提示する

作成する内容と既存の構成とのつながりを、ユーザーに正確に提示します。

出力形式：

=== ADD DOMAIN PROPOSAL ===
New domain: [domain name]
Vocabulary: [key term mappings]

--- What will be created ---

Folder structure:
  [domain-folder]/           <- [description]
    index.md                 <- domain hub MOC
  [domain-inbox]/            <- capture zone (if processing >= moderate)
  templates/[domain]-note.md <- note template with domain schema

--- Connections to existing system ---

- Hub MOC (index.md): add [new domain] section with link to [[domain-index]]
- Cross-domain links: [new domain] notes can link to [existing domain] notes and vice versa
- Shared infrastructure: self/, ops/, templates/ remain shared
- Semantic search: [new collection added / not needed at current volume]

--- What does NOT change ---

- Existing [domain] folder: untouched
- Existing templates: untouched
- Existing MOC hierarchy: untouched (hub gains one new link)
- self/ space: shared (methodology.md updated with multi-domain patterns)
- ops/ space: shared (derivation.md updated with domain addition)

--- Domain Configuration ---

| Dimension | Position | Rationale |
|-----------|----------|-----------|
| Granularity | [val] | [reason] |
| Processing | [val] | [reason] |
| Maintenance | [val] | [reason] |
| Schema | [val] | [reason] |
| Linking | [val] | [reason] |
| (system-level dimensions inherited from existing system) |

--- Schema Preview ---

[Show the _schema block for the new domain template]

--- Vocabulary Mapping ---

| Universal | New Domain | Existing Domain |
|-----------|-----------|-----------------|
| note | [term] | [existing term] |
| ... | ... | ... |

Would you like me to create this? I can adjust anything before generating.
=== END PROPOSAL ===

続行する前に、ユーザーの承認を待ちます。

---

フェーズ 6：生成する

新しいドメインのインフラストラクチャを作成します。後の成果物が前の成果物を参照するため、順序が重要です。

ステップ 1：ドメインのフォルダー構成

ドメインのノートフォルダーと、必要に応じて受信箱フォルダーを作成します。

mkdir -p [domain-folder]
mkdir -p [domain-inbox]  # if processing >= moderate

ステップ 2：ドメインノートのテンプレート

導出した _schema ブロック、必須および任意のフィールド、コメントと例に含めるドメインの語彙を使って、templates/[domain]-note.md を作成します。

ステップ 3：ドメインのハブ MOC

[domain-folder]/index.md を作成します。

---
description: [entry point description in domain vocabulary]
type: moc
---

# index

[Orientation paragraph in domain vocabulary]

## [domain:Topics]
(topics will emerge as notes accumulate)

## Getting Started
1. Capture your first [domain:note]
2. Connect it to this hub

ステップ 4：ドメインガイド

そのドメインで作業するときに読み込む、ドメイン固有の方法論ドキュメントを作成します。Claude Code の場合は、.claude/skills/[domain]-guide/SKILL.md またはコンテキストファイル内のセクションにします。他のプラットフォームの場合は、独立したガイドファイルにします。

ガイドでは、以下を扱います。

• このドメインでの記録方法
• 処理方法（導出された処理強度で）
• ドメインを横断して接続するタイミング
• ドメイン固有の品質基準
• ドメインの語彙リファレンス

ステップ 5：ハブ MOC を更新する

既存のハブ MOC（index.md）に新しいドメインを追加します。

## [New Domain Name]
- [[domain-index]] -- [description of what this domain tracks]

ステップ 6：コンテキストファイルを更新する

コンテキストファイルに以下を追加します。

• ドメインのルーティング：[domain] で作業するときに [domain guide] を読み込む
• 語彙：新しいドメインの用語を語彙リファレンスに追加する
• 処理：処理強度が異なる場合、そのルーティングを記載する
• ドメイン横断リンク：ドメインを横断して接続するタイミングと方法

ステップ 7：self/methodology.md を更新する

複数ドメインでの作業パターンを追加します。

• ドメインを切り替える方法
• ドメイン横断の接続を作成するタイミング
• ドメインごとの処理トリガー

ステップ 8：ops/derivation.md を更新する

ドメインの追加を記録します。

• 新しいドメイン名と語彙
• ドメインごとに調整可能な次元の位置と、その根拠
• 検証済みの構成ルール
• ドメイン横断の接続パターン
• 追加日と追加時のコンテキスト

ステップ 9：セマンティック検索を更新する（設定済みの場合）

qmd または同等のものが設定されている場合：

# Add new collection for domain folder
qmd update
qmd embed

新しいコレクションを含めるように、.mcp.json または同等の設定を更新します。

ステップ 10：ドメイン処理スキル（処理強度が中程度以上の場合）

新しいドメインで独自の処理スキルが必要な場合（処理強度または語彙が既存のドメインと異なるため）、reduce／reflect／verify スキルをドメインに合わせて生成します。

既存のスキルでノートの種類に応じた複数ドメインへのルーティングに対応できる場合は、重複を作成せずに既存のスキルを更新します。

---

フェーズ 7：検証する

新しいドメインのファイルに対するカーネルチェック

新しいドメインのファイルに対してカーネル検証を実行します。

1. すべての新しいファイルで YAML フロントマターが有効である
2. 新しいファイルの Wiki リンクが解決できる（ドメイン横断リンクを含む）
3. 新しいドメインの MOC にハブからアクセスできる
4. description フィールドが存在する
5. Topics フッターがドメインの MOC を参照している

構成の検証

1. フィールドの競合がないこと -- すべてのテンプレートでフィールド名を grep し、意味的な競合がないことを確認する
2. ハブの到達可能性 -- ハブ MOC がすべてのドメイン MOC にリンクし、すべてのドメイン MOC がそれぞれのノートにリンクしていること
3. クロスドメインリンクのテスト -- 新しいドメインから既存のドメインへのテストリンクを作成し、解決されることを確認する
4. ファイル名の一意性 -- ドメイン間でファイル名の重複がないことを確認する：

   find . -name "*.md" -not -path "./.git/*" -not -name "README.md" -not -name "SKILL.md" \
     -exec basename {} \; | sort | uniq -d
   

5. ボキャブラリの分離 -- 新しいドメインのファイルで既存ドメインのボキャブラリ用語を grep する（出現しないはず）

結果を報告する

=== DOMAIN ADDITION VALIDATED ===
Domain: [name]
Files created: [N]
Hub updated: yes
Cross-domain links: functional
Filename uniqueness: verified
Schema conflicts: none

Your system now has [N] domains:
- [existing domain] ([N] notes)
- [new domain] (0 notes -- ready to start)

Next steps:
1. Capture your first [domain:note] in [domain-folder]/
2. Cross-domain connections will emerge naturally as you work
3. Run /health when /next flags maintenance issues in either domain
=== END VALIDATION ===

---

品質基準

• 明示されない限り、既存のコンテンツは決して変更されません（既存ファイルへの変更は、ハブ MOC の更新、コンテキストファイルの更新、派生の更新のみです）
• 各ドメインは独自のボキャブラリを維持します -- セラピーのユーザーが自身のリフレクションフォルダで「claim」を目にすることはありません
• クロスドメインの接続は推奨されますが、強制されることはありません
• ハブ MOC は単一の統合エントリポイントです -- すべてのドメインにリンクする必要があります
• テンプレートは各ドメインのスキーマの信頼できる唯一の情報源です -- スキーマを 2 か所で定義しないでください
• 新しいドメインの処理要件が大きく異なる場合は、万能な単一の方式よりも個別の処理パスを優先してください
• 追加後もシステムがカーネルチェックに合格することを検証してください
• すべてを ops/derivation.md に文書化してください -- 将来の再シードがマルチドメイン構成を理解できるようにする必要があります