Wiki Update — Sync Any Project to Your Wiki

You are distilling knowledge from the current project into the user's Obsidian wiki. This skill works from any project directory, not just the obsidian-wiki repo.

Before You Start

Read ~/.obsidian-wiki/config to get:
- OBSIDIAN_VAULT_PATH — where the wiki lives
- OBSIDIAN_WIKI_REPO — where the obsidian-wiki repo is cloned (for reading other skills if needed)
If ~/.obsidian-wiki/config doesn't exist, tell the user to run bash setup.sh from their obsidian-wiki repo first.
Read $OBSIDIAN_VAULT_PATH/.manifest.json to check if this project has been synced before.
Read $OBSIDIAN_VAULT_PATH/index.md to know what the wiki already contains.

Step 1: Understand the Project

Figure out what this project is by scanning the current working directory:

README.md, docs/, any markdown files
Source structure (frameworks, languages, key abstractions)
package.json, pyproject.toml, go.mod, Cargo.toml or whatever defines the project
Git log (focus on commit messages that signal decisions, not "fix typo" stuff)
Claude memory files if they exist (.claude/ in the project)

Derive a clean project name from the directory name.

Step 2: Compute the Delta

Check .manifest.json for this project:

First time? Full scan. Everything is new.
Synced before? Look at last_commit_synced. Only consider what changed since then. Use git log <last_commit>..HEAD --oneline to see what's new.

If nothing meaningful changed since last sync, tell the user and stop.

Step 3: Decide What to Distill

This is the core question from Karpathy's pattern: what would you want to know about this project if you came back in 3 months with zero context?

Worth distilling:

Architecture decisions and why they were made
Patterns discovered while building (things you'd Google again otherwise)
What tools, services, APIs the project depends on and how they're wired together
Key abstractions, how they connect, what the mental model is
Trade-offs that were evaluated, what was picked and why
Things learned while building that aren't obvious from reading the code

Not worth distilling:

File listings, boilerplate, config that's obvious
Individual bug fixes with no broader lesson
Dependency versions, lock file contents
Implementation details the code already says clearly
Routine changes anyone could read from the diff

The heuristic: if reading the codebase answers the question, don't wiki it. If you'd have to re-derive the reasoning by reading git blame across 20 commits, wiki it.

Step 4: Distill into Wiki Pages

Project-specific knowledge

Goes under $VAULT/projects/<project-name>/:

projects/<project-name>/
├── <project-name>.md          ← project overview (named after the project, NOT _project.md)
├── concepts/                  ← project-specific ideas, architectures
├── skills/                    ← project-specific how-tos, patterns
└── references/                ← project-specific source summaries

The overview page (<project-name>.md) should have:

What the project is (one paragraph)
Key concepts and how they connect
Links to project-specific and global wiki pages

Global knowledge

Things that aren't project-specific go in the global categories:

What you found	Where it goes
A general concept learned	`concepts/`
A reusable pattern or technique	`skills/`
A tool/service/person	`entities/`
Cross-project analysis	`synthesis/`

Page format

Every page needs YAML frontmatter:

---
title: >-
    Page Title
category: concepts
tags: [tag1, tag2]
sources: [projects/<project-name>]
summary: >-
    One or two sentences (≤200 chars) describing what this page covers.
provenance:
  extracted: 0.6
  inferred: 0.35
  ambiguous: 0.05
created: TIMESTAMP
updated: TIMESTAMP
---

Use folded scalar syntax (summary: >-) for title and summary to keep frontmatter parser-safe across punctuation (:, #, quotes) without escaping rules.
Keep the title and summary contents indented by two spaces under summary: >-.

# Page Title

- A fact the codebase or a doc actually states.
- A reason the design works this way. ^[inferred]

Use [[wikilinks]] to connect to other pages.

Write a summary: frontmatter field on every new/updated page (1–2 sentences, ≤200 chars), using >- folded style. For project sync, a good summary answers "what does this page tell me about the project I wouldn't guess from its title?" This field powers cheap retrieval by wiki-query.

Apply provenance markers per llm-wiki (Provenance Markers section). For project sync specifically:

Extracted — anything visible in the code, config, or a doc/commit message: file structure, dependencies, function signatures, what a file does.
Inferred — why a decision was made, design rationale, trade-offs, "the team chose X because Y" — unless a commit message, doc, or ADR states it explicitly.
Ambiguous — when the code and docs disagree, or when there's clearly an in-progress migration with two patterns living side by side.

Compute the rough fractions and write the provenance: block on every new/updated page.

Updating vs creating

If a page already exists in the vault, merge new information into it. Don't create duplicates.
If you're adding to an existing page, update the updated timestamp and add the new source.
Check index.md to see what's already there before creating anything new.

Step 5: Cross-link

After creating/updating pages:

Add [[wikilinks]] from new pages to existing related pages
Add [[wikilinks]] from existing pages back to the new ones where relevant
Link the project overview to all project-specific pages and relevant global pages

Step 6: Update Tracking

Update `.manifest.json`

Add or update this project's entry:

{
  "projects": {
    "<project-name>": {
      "source_cwd": "/absolute/path/to/project",
      "last_synced": "TIMESTAMP",
      "last_commit_synced": "abc123f",
      "pages_in_vault": ["projects/<project-name>/<project-name>.md", "..."]
    }
  }
}

Update `index.md`

Add entries for any new pages created.

Update `log.md`

Append:

- [TIMESTAMP] WIKI_UPDATE project=<project-name> pages_updated=X pages_created=Y source_cwd=/path/to/project

Tips

Be aggressive about merging. If the project uses React Server Components, don't create a new page if concepts/react-server-components.md already exists. Update the existing one and add this project as a source.
Consult the tag taxonomy. Read $VAULT/_meta/taxonomy.md if it exists, and use canonical tags.
Don't copy code. Distill the knowledge, not the implementation. "This project uses a debounced search pattern with 300ms delay" is useful. Pasting the actual debounce function is not.
Project overview is the anchor. The <project-name>.md file is what you'd read to get oriented. Make it good.

wiki-update