Route by vault methodology

This skill returns filing suggestions. It does not write knowledge pages or move existing notes. If .vault-meta/mode.json is absent, use generic. If the file exists but is invalid, fail closed and repair it through a reviewed configuration operation before suggesting routes; never silently substitute Generic for corrupt user configuration.

Resolve the installed product root from this skill's own location, not from the vault or current working directory:

PRODUCT_ROOT=/absolute/path/to/installed/claude-obsidian
CORE="$PRODUCT_ROOT/scripts/claude-obsidian.py"
MODE_HELPER="$PRODUCT_ROOT/scripts/wiki-mode.py"
test -f "$CORE" && test -f "$MODE_HELPER"

Every ../wiki/references/ link in this file resolves the same way, relative to this skill's own directory under $PRODUCT_ROOT, never relative to the selected vault's wiki/ directory.

Read and route safely

Always select the vault explicitly:

python3 "$MODE_HELPER" --vault "$VAULT" get
python3 "$MODE_HELPER" --vault "$VAULT" config
python3 "$MODE_HELPER" --vault "$VAULT" route concept "Concept name"
python3 "$MODE_HELPER" --vault "$VAULT" route source "Source title"

The helper validates the selected vault, confines paths, sanitizes names, and prints a suggestion only. A calling skill may override the suggestion when the user supplies a more specific project, area, MOC, or parent note, but it must still apply its eventual writes through one operation transaction.

Use the templates as structural guidance: LYT atomic, LYT MOC, PARA area, PARA project, PARA resource, or Zettelkasten atomic. They use canonical type values from claude_obsidian/page_schema.py and a separate flat methodology_role property:

A resource template describes a topic collection. Use source instead when the new page represents a particular captured source. The methodology role does not add a router type: pass the canonical type and respect the chosen project, area, or MOC destination. Structural MOCs use an explicit destination; meta is not a routable new-note type. Existing user pages, custom type vocabularies, and saved Dataview queries remain unchanged. Any requested migration needs its own reviewed plan; switching mode never rewrites existing notes.

Change mode

A mode change is one configuration operation, dry-run first:

1. Read the current .vault-meta/mode.json, or start from the helper's default config when it is absent.

2. Validate the requested mode as exactly generic, lyt, para, or zettelkasten. Preserve the other mode-specific settings.

3. Choose and retain a pinned UTC timestamp and operation ID for both commands.

4. Preview the canonical configuration transaction; the command records the current target hash and limits the write to .vault-meta/mode.json:

   python3 "$CORE" mode set "$MODE" --vault "$VAULT" \
     --generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID"

5. Show the old mode, new mode, exact changed path, and complete preview. Copy its approved_plan_sha256 only after review.

6. Apply by regenerating that exact vault-bound plan:

   python3 "$CORE" mode set "$MODE" --vault "$VAULT" \
     --generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID" \
     --approved-plan-sha256 "$APPROVAL_SHA256" --apply

Follow the operation transaction contract. Do not use scripts/wiki-mode.py's legacy direct-write set action or a setup script to bypass this workflow.

Changing mode affects routing for future operations only. Never bulk-create folders, move notes, rewrite wikilinks, or migrate existing pages as a side effect. If migration is later requested, plan and review it as a distinct operation with its own hashes and transaction.

Checkpoint

Observe the user's current structure, think about how they retrieve and act on notes, verify a few proposed routes before changing configuration, and grow by revisiting the mode only when real filing friction appears.