wiki-mode

What this skill does

# 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>.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/`:

- [`lyt/moc-template.md`](templates/lyt/moc-template.md) — MOC scaffolding
- [`lyt/atomic-template.md`](templates/lyt/atomic-template.md) — atomic note linking into MOCs
- [`para/project-template.md`](templates/para/project-template.md) — project with status + deadline + next-action
- [`para/area-template.md`](templates/para/area-template.md) — ongoing responsibility
- [`para/resource-template.md`](templates/para/resource-template.md) — reference material
- [`zettel/atomic-template.md`](templates/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.

```bash
# Detection idiom for consumers:
if [ -f .vaul