| name | wiki-mode |
| description | Methodology modes for the Compound Vault. Lets the vault declare an organizational style (LYT / PARA / Zettelkasten / Generic) that wiki-ingest, save, and autoresearch consult before filing new pages. Reads `.vault-meta/mode.json`; defaults to `generic` when absent. Triggers on: set vault mode, switch to PARA, use LYT, what's my vault mode, zettelkasten setup, wiki mode, methodology mode, change mode, configure 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.
This skill lets codex-obsidian route new pages through common PKM structures instead of forcing the generic source/entity/concept layout.
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 clusterwiki/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/outcomewiki/areas/<area-name>/<note>.md — ongoing responsibilities (no deadline)wiki/resources/<topic>/<note>.md — reference material, organized by topicwiki/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+)" sectionskills/save/SKILL.md — "## Mode awareness (v1.8+)" sectionskills/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:
| Content type | Generic | LYT | PARA | Zettelkasten |
|---|
| New source ingest | wiki/sources/foo.md | wiki/notes/foo.md + add to topic MOC | wiki/resources/<topic>/foo.md | wiki/<ID>-foo.md |
| New entity | wiki/entities/<Name>.md | wiki/notes/<Name>.md + entity MOC | wiki/resources/people/<Name>.md | wiki/<ID>-<name>.md |
| New concept | wiki/concepts/<Name>.md | wiki/notes/<Name>.md + concept MOC | wiki/resources/concepts/<Name>.md | wiki/<ID>-<name>.md |
Session note (/save) | wiki/sessions/<date>-<topic>.md | wiki/notes/<date>-<topic>.md + session MOC | wiki/projects/<project>/<date>-<topic>.md | wiki/<ID>-session-<topic>.md |
Research output (/autoresearch) | wiki/concepts/<topic>.md | wiki/notes/<topic>.md + topic MOC | wiki/resources/<topic>/<topic>.md | wiki/<ID>-<topic>.md |
Templates
Per-mode templates live at skills/wiki-mode/templates/:
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:
- Set new mode:
bash bin/setup-mode.sh
- Existing files remain in their original locations and continue to work
- New files file per the new mode
- (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.
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.
Keep mode routing boring and predictable: the router decides paths, consumer skills should not special-case filing logic.
Cross-reference
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.
| # | Principle | Application here |
|---|
| 1 | OBSERVE (ext) | Read .vault-meta/mode.json to know which mode is active before routing anything. |
| 2 | OBSERVE (int) | Audit the assumption that mode=generic is the default — the user may be on LYT/PARA/Zettelkasten. |
| 3 | LISTEN | The mode is the user's organizational instinct, not yours. Respect what they configured. |
| 4 | THINK | Apply the mode-specific routing rule to the content type at hand (source / entity / concept / session / research). |
| 5 | CONNECT (lat) | This skill's safe_name is the canonical sanitizer — wiki-ingest, save, autoresearch all funnel through here. |
| 6 | CONNECT (sys) | Three consumer skills depend on route output; consistency across consumers is the v1.8 contract. |
| 7 | FEEL | Does the routed path feel right to the user? wiki/notes/Foo.md (LYT) means something different from wiki/concepts/Foo.md (generic). |
| 8 | ACCEPT | Mode choice is the user's call. Accept that PARA users will sometimes want to override the auto-route. |
| 9 | CREATE | Return the routed path string — a single safe filesystem location. |
| 10 | GROW | When modes change mid-vault, surface the migration cost honestly; existing pages do NOT auto-migrate. |
