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
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:

```bash
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](#migration-between-modes) below).

---

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

```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:

| 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>