You are extending an existing knowledge system with a new domain. This is composition, not replacement. The new domain must coexist with existing domains while maintaining its own vocabulary, schema, and processing patterns. The shared graph (wiki links, hub MOC, description fields) connects everything.
Your Task
Add a new knowledge domain: $ARGUMENTS
Reference Files
Read these during derivation phases:
Composition rules:
${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md-- Test 4 (Multi-Domain Composition) validates the pattern${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md-- three-space architecture (shared across domains)${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md-- coherence validation for domain config
Domain configuration:
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md-- domain-native term mapping${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md-- pre-validated domain configurations${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md-- 3 presets with configurations${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md-- research backing for dimension positions${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md-- domain vulnerability matrix
Validation:
${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml-- the 12 non-negotiable primitives${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh-- kernel validation script
PHASE 1: Scan Existing System
Automated. Understand what exists before adding to it.
1a. Read system configuration
Read ops/derivation.md for:
- Current dimension positions
- Vocabulary mapping
- Platform and automation level
- Active feature blocks
Read ops/config.yaml for live configuration values.
1b. Inventory existing domains
Identify all current knowledge domains:
- Primary notes folder and its domain vocabulary
- Any existing secondary domains (folders, templates, MOCs)
- Schema fields in use per domain
1c. Identify dimension types
Classify each of the 8 dimensions as system-level or domain-adjustable:
| Dimension | Type | Rationale |
|---|---|---|
| Organization | system-level | Flat/hierarchical applies to the whole workspace |
| Automation | system-level | Hooks and skills are workspace-wide infrastructure |
| Navigation depth | system-level | Hub MOC structure is shared |
| Granularity | domain-adjustable | Different domains may need different granularity |
| Processing | domain-adjustable | Research needs heavy, relationships need light |
| Maintenance | domain-adjustable | Different condition thresholds per domain growth rate |
| Schema | domain-adjustable | Domain-specific fields vary |
| Linking | domain-adjustable | Some domains need semantic search, others don't |
System-level dimensions are fixed by the existing system. Domain-adjustable dimensions can vary for the new domain.
PHASE 2: Conversation
1-3 conversation turns to understand the new domain. Use AskUserQuestion for each turn.
Opening question
Ask ONE focused question about the new domain:
"Tell me about [domain hint from $ARGUMENTS] -- what kinds of things will you track, and how does this relate to your existing [current domain vocabulary] work?"
The second half is critical: understanding the relationship between domains drives composition decisions.
Signal extraction
As the user responds, extract signals for domain-adjustable dimensions:
| Signal | Dimension | Position |
|---|---|---|
| "Quick notes about people" | Granularity | moderate |
| "Deep analysis of sessions" | Processing | heavy |
| "Just remember key moments" | Processing | light |
| "I revisit and update often" | Maintenance | tight thresholds |
| "Mostly static once captured" | Maintenance | lax thresholds |
| "Need to find patterns across entries" | Linking | explicit+implicit |
Also extract:
- Volume estimate -- how many notes per processing batch
- Temporal dynamics -- how fast does content change
- Vocabulary -- the user's own words for notes, processes, organization
- Cross-domain relationship -- how this connects to existing domain(s)
Follow-up strategy
After the opening response, ask 1-2 follow-ups targeting:
- Vocabulary confirmation -- "When you say [user's word], do you mean individual insights or longer entries?"
- Cross-domain connection patterns -- "Will [new domain] notes connect to your [existing domain] notes? How?"
Do NOT ask about dimensions directly. Listen for them in natural conversation.
PHASE 3: Derive Domain Configuration
3a. Map signals to domain-adjustable dimensions
For each adjustable dimension, determine the position for the new domain:
- User signals (highest priority)
- Closest use-case preset from
${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md - Cascade from system-level dimensions
3b. Build vocabulary mapping
Read ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md for the transformation table.
Priority order:
- User's own words from conversation
- Use-case preset vocabulary
- Closest reference domain blend
Build the complete mapping for the new domain:
| Universal Term | New Domain Term | Source |
|---|---|---|
| note | [term] | [user / preset / blend] |
| extract / reduce | [term] | [user / preset / blend] |
| connect / reflect | [term] | [user / preset / blend] |
| MOC | [term] | [user / preset / blend] |
| description | [term] | [user / preset / blend] |
| topics | [term] | [user / preset / blend] |
| inbox | [term] | [user / preset / blend] |
3c. Design domain-specific schema
Start from the base note schema (description, topics) and add domain-specific fields:
_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. Collision check
This is critical for multi-domain composition. Verify:
-
Filename uniqueness -- the new domain's note titles won't collide with existing notes. Wiki links resolve by filename across the entire workspace, so every filename must be unique.
-
Schema field names -- new domain fields don't conflict with existing domain fields. If both domains use a field name (e.g.,
type), the enum values must be mutually exclusive or the field must have compatible semantics. -
Template names -- new domain templates have distinct names from existing templates.
-
Folder names -- new domain folders don't collide with existing folders.
If any collisions are detected, resolve them before proceeding.
PHASE 4: Check Composition Rules
Read ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md (Test 4: Multi-Domain Composition) for the validated composition pattern.
Verify each composition rule:
Rule 1: Wiki links resolve unambiguously in shared namespace
All note filenames must be unique across all domains. The new domain's naming conventions must be compatible with existing ones.
Rule 2: Hub MOC links to all domain MOCs
The existing hub MOC (index.md or equivalent) must be updated to include the new domain's entry point MOC. The hierarchy becomes:
hub -> existing domain MOCs
-> new domain MOC
Rule 3: Cross-domain reflect searches all notes folders
If connection finding (reflect) is active, it must search across all domains -- a note in the new domain might connect to a note in the existing domain. Semantic search collections must include the new domain folder.
Rule 4: Domain-specific processing can coexist
If the new domain needs different processing intensity than the existing domain, the pipeline must route by note type. Heavy processing for research notes, light processing for relationship notes, etc.
Rule 5: Context file loading is progressive
T