Vault sync

Vault Sync

Reconcile Claude's stored memory with the user's Obsidian vault, then propagate any changes into CLAUDEMEM.md. The goal is a fast, honest delta — correct what's stale, add what's genuinely new, drop what's dead — not a full rewrite. Be surgical, not verbose.

Requirements

This skill assumes your agent has a persistent memory tool (the steps below use memory_user_edits — Claude's user-memory tool). If your agent stores memory under a different tool name, substitute it; if it has no memory store at all, this skill only does the vault→CLAUDEMEM.md half and can't diff against prior memory.

Configuration

This skill needs your Obsidian vault's root path. Look it up before Step 1:

1. Check ~/.claude/skills-user-config.json for a top-level key "obsidian_vault_path".
2. If present, use it directly — don't ask again.
3. If missing (file or key doesn't exist), ask the user for their vault root path once, then write it to that file (create the file/dirs if needed, preserving any other keys already in it) so future runs don't need to ask.

If running under Claude Code / OpenClaw on a remote host, the vault root may instead be the current working directory (a synced vault checkout) — confirm with the user which applies rather than guessing.

The CLAUDEMEM.md rule (read this first)

CLAUDEMEM.md lives at the vault root and is a mirror of Claude's memory, written by Claude for other agents. It is an OUTPUT of this skill, never an input.

• NEVER read CLAUDEMEM.md as a source of truth during the diff (Steps 1–3). Diffing memory against a file that was itself generated from memory is a feedback loop: it launders stale facts back in and makes nothing more accurate.
• The vault's hand-maintained notes (the status/goals/priorities notes, etc.) are the source of truth. CLAUDEMEM.md only gets written to, in Step 6, after memory is updated.
• The only time you may open CLAUDEMEM.md is in Step 6, to compute a write-delta — and even then you treat memory (not the file) as authoritative.

Step 0 — Read current memory first

Before reading any vault files, call memory_user_edits view. You cannot diff against memory you haven't looked at. Hold this list in mind as the baseline.

Step 1 — Read the core files (in this order)

These are the canonical "current state" files. Read all of them:

Adapt these to your own vault's note names — the paths below are examples of the kind of file to read, not a fixed layout:

• a status note (e.g. Now.md) — active/paused projects, current learning
• a goals note (e.g. Goals.md) — long/short-term goals
• a priorities note (e.g. Priorities.md) — current + daily priorities, things being dropped
• a principles note (e.g. Reminders.md) — principles, mindset, warnings (rarely changes; skim)
• a vault map / home note (e.g. Home.md) — vault map + last-updated date

Then the 5 most recent daily notes (newest first): sort your daily-notes folder (e.g. Daily/<year>/*.md) by filename descending and read the latest 5.

Then the active work/project files:

• a projects folder — read the files for projects marked Active in the status note
• any client/consulting engagement notes (if the vault has them)
• a master to-do list — skim for status flips (only note big ones)

Finally, scan for brain dumps:

• any scratch/inbox notes — raw, unstructured. Mine for new facts, decisions, and project status. Ignore code snippets, model lists, and noise.

Exclusion: Do NOT read CLAUDEMEM.md here, even if a glob or directory walk surfaces it. It is not a source. (See "The CLAUDEMEM.md rule" above.)

Don't read the whole vault. If a daily note references a project file you haven't read and it looks materially new, read that one file — but don't spider endlessly.

Step 2 — Diff against memory

For each thing you learn, classify it:

• Correction — contradicts a stored memory (e.g. framework switched, goal number changed, project status flipped). These are the highest-value updates. Replace the stale memory.
• New — a fact, project, client, health issue, or decision not yet in memory. Add it.
• Dead — a memory that the vault now shows is closed/abandoned and no longer worth carrying. Remove or fold into a correction.
• Unchanged — already captured accurately. Do nothing. Do NOT re-add or reword for its own sake.

Bias toward fewer, denser memories. Prefer editing an existing memory over adding a near-duplicate.

Keep a running list of every change you make (correction / addition / removal) — you will need it in Step 6 to update CLAUDEMEM.md and in Step 7 to report the delta.

Step 3 — Apply updates

Use memory_user_edits (replace / add / remove). Rules:

• Each memory entry has a 500-character hard limit. Draft tight; if it overflows, cut words, don't split hairs. Abbreviate tool stacks (Claude Code+Playwright+...).
• Keep the total set lean — there's a 30-entry cap. If near it, consolidate.
• Lead corrections with a short tag like "UPDATE (corrects older memory):" so the change is legible later.
• Date-stamp time-sensitive state ("as of May 2026") so future syncs know its age.

Step 4 — NEVER store secrets

Some vault files may contain real secrets (API keys, passwords, SSH keys) sitting in plaintext — treat any scratch/brain-dump or project note as a potential source.

• NEVER write a secret into memory.
• NEVER write a secret into CLAUDEMEM.md either — it is agent-readable and may sync to a remote host in plaintext.
• If you encounter a secret sitting in plaintext in a synced/version-controlled file, FLAG it to the user in the summary (file + what kind of secret) and recommend rotating it and moving it to an env var / secrets manager. Do not reproduce the secret value.

Step 5 — Decide whether CLAUDEMEM.md needs touching

If Steps 2–3 produced no corrections, additions, or removals, memory is already in step with the vault. CLAUDEMEM.md was generated from memory, so it's already current — skip Step 6 entirely and just report "no changes" in Step 7. Don't rewrite a file that hasn't drifted.

Otherwise, proceed to Step 6.

Step 6 — Mirror the changes into CLAUDEMEM.md

CLAUDEMEM.md is the portable context file other agents load. After memory changes, bring it back in step — surgically, not by regenerating from scratch.

1. Read the existing CLAUDEMEM.md (this is the one allowed read, and only to compute a write-delta — memory remains authoritative, not the file).
2. For each change from Step 2's running list, edit the matching section:
   • Correction → replace the stale line/fact in place.
   • New → add it under the right heading (Projects, Stack, Personal, etc.).
   • Dead → remove it, or fold it into the condensed history if it's worth keeping as context.
3. Preserve the file's structure, headings, frontmatter, and the "How to use this file" / Interaction Rules block. Do not reorder or restyle for its own sake.
4. Update the generated_on: (or equivalent date) field in the frontmatter to today.
5. Keep it dense and agent-oriented. Don't let it balloon — the actionable top third (interaction rules, positioning, current priority, stack) does most of the work.
6. Apply secret hygiene from Step 4 — no secrets land here.

If CLAUDEMEM.md doesn't exist yet, note that in the report and offer to generate it fresh from current memory rather than silently creating it.

Step 7 — Report the delta (briefly)

End with a short prose summary, no walls of text:

• Corrected: what changed and from→to (one line each)
• Added: genuinely new items (one line each)
• Dropped: anything removed
• CLAUDEMEM.md: updated (which sections) or skipped (no drift)
• Flags: secrets found, or honest gaps worth calling out (be blunt — if the vault shows scope creep, stalled wins, or priority drift against the user's stated priorities, say so plainly)

Then stop. Don't offer to do ten follow-ups. One or two relevant offers max.

Cadence note

This is a weekly-review-grade ritual, not a daily one. Normal conversations already feed memory passively; running this every day mostly burns tokens re-reading unchanged files. Weekly, or after a burst of vault changes, is the sweet spot.