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

1. 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)
2. If

   ~/.obsidian-wiki/config

   doesn't exist, tell the user to run

   bash setup.sh

   from their obsidian-wiki repo first.
3. Read

   $OBSIDIAN_VAULT_PATH/.manifest.json

   to check if this project has been synced before.
4. 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

• 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

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

concepts/

skills/

entities/

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:

>-

wiki-query

Apply provenance markers per

llm-wiki

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

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

Update

hot.md

Read

$OBSIDIAN_VAULT_PATH/hot.md

wiki-ingest

updated

Write conceptually: "Synced obsidian-wiki — added wiki-capture and wiki-research skills, core new capabilities are autonomous web research and conversation capture."

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.