Wiki Mode

wiki-mode: Methodology Modes for the Compound Vault

The v1.6 + v1.7 vault structure was opinion-free — wiki/sources/, wiki/entities/, wiki/concepts/, and so on. That works for power-users with their own organizational instincts. It does NOT serve the large segment of Obsidian users who want a named methodology to follow.

v1.8 ships `wiki-mode` to close that gap. A vault declares a mode (LYT, PARA, Zettelkasten, or Generic) in .vault-meta/mode.json; the other skills consult it before deciding where to file new pages. Mode = generic is the default and preserves v1.6/v1.7 behavior exactly.

Per May 2026 compass artifact: This was priority gap 5 of the 5 identified. Ideaverse Pro 2.0 ($200 paid vault) ships LYT as an opinionated structure; no Claude+Obsidian competitor ships PARA / Zettelkasten / mode-aware routing as a first-class skill. v1.8 takes us from TIE → LEAD on the audit §9 methodology-support axis (5 of 7 axes #1).

---

The four modes

LYT (Linking Your Thinking — Nick Milo)

Philosophy: notes link, folders don't. The organizational primitive is the MOC (Map of Content) — a hub note that links into a cluster of atomic notes. You never browse folders; you navigate by following links.

Filing convention:

• wiki/mocs/<topic>-moc.md — the MOC for a topic cluster
• wiki/notes/<atomic-note>.md — flat list of atomic notes, named by their idea, all linked from at least one MOC

When to use: mid-to-large knowledge bases (>100 notes), users who think in terms of conceptual clusters, knowledge graphs.

PARA (Tiago Forte)

Philosophy: organize by actionability, not topic. Active work in Projects, ongoing responsibilities in Areas, reference material in Resources, completed/inactive in Archives.

Filing convention:

• wiki/projects/<project-name>/<note>.md — active projects with a deadline/outcome
• wiki/areas/<area-name>/<note>.md — ongoing responsibilities (no deadline)
• wiki/resources/<topic>/<note>.md — reference material, organized by topic
• wiki/archives/<year>/<note>.md — completed projects, sunsetted areas

When to use: workflow-heavy users, knowledge workers managing many projects, GTD-adjacent practitioners.

Zettelkasten (Niklas Luhmann's slip-box)

Philosophy: atomic notes, unique IDs, dense bidirectional linking. No folders. Every note answers exactly one idea. Notes find each other by ID references.

Filing convention:

• wiki/<YYYYMMDDHHMMSSffffff>-<slug>.md — flat, timestamped IDs (20 digits = date + microseconds, collision-resistant)
• Every note has id:, parent_id: (optional), child_ids: (optional) in frontmatter
• No subdirectories; the wiki/ root is the whole vault

When to use: academics, researchers, long-term thinkers building permanent knowledge artifacts. Highest discipline; smallest filing surface.

Generic (default — v1.7 behavior)

Filing convention: preserves the v1.6/v1.7 default — wiki/sources/, wiki/entities/, wiki/concepts/, wiki/<domain>/. No opinion imposed.

When to use: when you don't want to commit to a methodology, or you're migrating from v1.7 and want zero behavior change.

---

How to set the mode

bash bin/setup-mode.sh

Interactive prompt: pick one of the 4 modes. Writes .vault-meta/mode.json. Optionally seeds template folders (LYT mocs/, PARA projects/areas/resources/archives/).

To check the current mode programmatically:

cat .vault-meta/mode.json | python3 -c 'import json,sys; print(json.load(sys.stdin)["mode"])'

To switch modes later: re-run setup-mode.sh. Existing files are NOT auto-migrated; the new mode only affects newly-filed pages from that point. Migration is a manual operation (see migration section below).

---

Mode config schema (.vault-meta/mode.json)

{
  "schema_version": 1,
  "mode": "lyt|para|zettelkasten|generic",
  "configured_at": "ISO-8601 timestamp",
  "config": {
    "lyt": {
      "moc_folder": "wiki/mocs/",
      "notes_folder": "wiki/notes/"
    },
    "para": {
      "projects_folder": "wiki/projects/",
      "areas_folder": "wiki/areas/",
      "resources_folder": "wiki/resources/",
      "archives_folder": "wiki/archives/"
    },
    "zettelkasten": {
      "id_format": "YYYYMMDDHHMMSSffffff",
      "no_folders": true,
      "root_folder": "wiki/"
    },
    "generic": {
      "sources_folder": "wiki/sources/",
      "entities_folder": "wiki/entities/",
      "concepts_folder": "wiki/concepts/",
      "sessions_folder": "wiki/sessions/"
    }
  }
}

The config block always includes ALL four modes; the active one is named by mode. This lets you switch modes without losing custom folder overrides.

---

How other skills consume the mode

The integration layer is in three skills:

• skills/wiki-ingest/SKILL.md — "## Mode awareness (v1.8+)" section
• skills/save/SKILL.md — "## Mode awareness (v1.8+)" section
• skills/autoresearch/SKILL.md — "## Mode awareness (v1.8+)" section

Each consults .vault-meta/mode.json (via cat or direct Read). If absent → mode = generic, behavior unchanged. If present and mode != generic, route per the mode's config.

The routing table:

---

Templates

Per-mode templates live at skills/wiki-mode/templates/:

• `lyt/moc-template.md` — MOC scaffolding
• `lyt/atomic-template.md` — atomic note linking into MOCs
• `para/project-template.md` — project with status + deadline + next-action
• `para/area-template.md` — ongoing responsibility
• `para/resource-template.md` — reference material
• `zettel/atomic-template.md` — atomic claim + parent/child IDs

Skills that file new pages consult the template matching the (mode, content-type) pair as a structural starting point. Templates are SUGGESTIONS; the skill's own content logic always wins.

---

Migration between modes

Switching modes does NOT auto-migrate existing files. Manual migration:

1. Set new mode: bash bin/setup-mode.sh 2. Existing files remain in their original locations and continue to work 3. New files file per the new mode 4. (Optional) Manually move existing files to the new structure using your file manager or git mv

Why no auto-migration: the wiki contains your thinking. Auto-rewriting paths could break wikilinks, lose data, or surprise you. Manual migration forces explicit decisions about what fits the new methodology vs what stays in its current home.

For LYT specifically: after switching to LYT, run lint the wiki (skill: wiki-lint) to identify orphan pages that would benefit from MOC inclusion.

---

Feature gating

This skill is universally available in v1.8+. No bin/setup-*.sh required for the skill itself — only for explicitly setting a non-default mode. Skills that consume the mode check for .vault-meta/mode.json; absence = generic.

# Detection idiom for consumers:
if [ -f .vault-meta/mode.json ]; then
  MODE=$(python3 -c 'import json; print(json.load(open(".vault-meta/mode.json"))["mode"])')
else
  MODE="generic"
fi

---

Why v1.8 ships this, not v2.0+

Per audit §9: methodology support is the cheapest axis to lead. Nobody else ships it. The implementation is mostly conventions + routing + templates; no new infrastructure, no new dependencies. It's the highest-ROI release in the roadmap before the bigger v2.0 (derive) + v2.5 (GUI) work.

After v1.8: claude-obsidian leads on 5 of 7 axes per compass artifact. The remaining 2 (GUI ergonomics, derivative outputs) are major releases by themselves.

---

Cross-reference

• `docs/methodology-modes-guide.md` — narrative guide, when-to-use-which decision tree
• `wiki/references/methodology-modes.md` — short decision tree
• `docs/compound-vault-guide.md` — v1.7 omnibus (v1.8 builds on this)
• v1.7.0 audit §9 axis 6 (methodology TIE → LEAD): `docs/audits/v1.7.0-audit-2026-05-17.md`

---

How to think (10-principle mapping)

When working on this skill, apply the 10-principle loop. See `skills/think/SKILL.md` for the canonical framework.

{{title}}

(One atomic idea, claim, or observation. Should fit on one screen; if it grows past that, split into two notes and link them.)

Sources

• [[{{source-1}}]]
• (external citation, if any)

See also

• [[{{related-note}}]]

{{title}} — Map of Content

A Map of Content (MOC) links into a cluster of related atomic notes. It is a navigation hub, not a container. Notes are not stored under this MOC; they live flat under wiki/notes/ and are reached by following these links.

Why this MOC exists

(One paragraph: what cluster of thinking does this MOC serve? What question does following its links answer?)

Core notes

• [[note-1]]
• [[note-2]]
• [[note-3]]

Adjacent MOCs

• [[adjacent-moc-1]]
• [[adjacent-moc-2]]

Open questions / frontier

• What questions does this cluster not yet answer?
• What atomic notes would close those gaps?

{{title}}

Scope

(One paragraph: what ongoing responsibility does this area cover? What's IN scope, what's OUT of scope?)

Standards

(What good looks like. What you aim to maintain.)

Active projects in this area

• [[{{project-1}}]]
• [[{{project-2}}]]

Reference material

• [[{{resource-1}}]]

Review cadence

(How often you check in on this area. Default: weekly.)

{{title}}

Outcome

(One sentence: what does "done" look like?)

Status

• Current state: active
• Deadline: {{deadline-or-tbd}}
• Next action: (single concrete next step)

Notes

(Working notes, decisions, blockers.)

Related

• Areas: [[{{related-area}}]]
• Resources: [[{{related-resource}}]]

{{title}}

Summary

(2-3 sentences: what is this, why is it here, what is it useful for?)

Key content

(The actual reference material — quotes, summaries, links, structured information.)

Sources

• (citations, links to external material)

Related

• Areas using this: [[{{area-1}}]]
• Projects using this: [[{{project-1}}]]

{{id}} — {{title}}

Claim

(One atomic claim. Should answer one question or assert one observation. If you can't state it in 1-3 sentences, split into multiple zettels.)

Reasoning

(Why is this claim true? What does it rest on?)

Sources

• (external citations)
• Parent zettel: [[{{parent-id}}]] (the broader claim this refines)
• Child zettels: (claims that build on this one, populated as they're written)

Cross-references

• [[{{related-zettel-1}}]] — (relationship)
• [[{{related-zettel-2}}]] — (relationship)