Wiki Update
Distill whatever you are building in the current repo into your Obsidian wiki vault without switching to the obsidian-wiki project.
Overview
Wiki Update is a journey-wide agent skill that syncs the current project’s knowledge into your Obsidian wiki—usable whenever a solo builder needs to capture work into the vault before context fades.
Install
npx skills add https://github.com/ar9av/obsidian-wiki --skill wiki-updateWhat is this skill?
- Cross-project skill: run from any working directory when the user says update wiki, sync to wiki, or save to obsidian.
- Resolves vault path via .env walk-up, ~/.obsidian-wiki/config, or setup prompt per llm-wiki protocol.
- Reads .manifest.json and index.md to avoid duplicating what the wiki already contains.
- Honors wikilink vs markdown link format from OBSIDIAN_LINK_FORMAT.
- Structured flow: scan README/docs/source, distill, write internal links per vault conventions.
Adoption & trust: 2.2k installs on skills.sh; 1.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are deep in a random repo and your best notes still live in chat or local markdown that never reaches your Obsidian knowledge base.
Who is it for?
Builders with an Obsidian wiki workflow who want one command from any project to push structured updates.
Skip if: Teams without Obsidian, vaults missing config resolution, or users who only need a one-off README with no persistent wiki graph.
When should I use this skill?
User says update wiki, sync to wiki, save this to my wiki, update obsidian, or wants to distill current work into the Obsidian knowledge base.
What do I get? / Deliverables
Your vault gains an updated, linked distillation of the current project aligned with manifest and index, without manually copying files into the wiki repo.
- Updated vault pages and internal links for the current project
- Manifest-aware sync that respects existing index.md content
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Capture competitor and audience notes from a spike repo into the vault index after a research session.
Sync scope decisions and prototype learnings so validation artifacts live beside older product notes.
Push API and data-model summaries from an active feature branch into linked wiki pages.
Record review outcomes and launch checklists into the wiki before merge.
Update runbooks and incident learnings from production work into the knowledge base.
How it compares
Cross-repo wiki sync workflow—not a generic markdown linter or in-repo docs generator that never touches your vault.
Common Questions / FAQ
Who is wiki-update for?
Solo and indie builders using obsidian-wiki who maintain a central Obsidian vault and want agents to publish from any project directory.
When should I use wiki-update?
Whenever you say update wiki, sync to wiki, save to my wiki, or update obsidian—during research spikes, feature builds, launch prep, or ops runbook updates across the journey.
Is wiki-update safe to install?
It writes to your configured vault path on disk; confirm OBSIDIAN_VAULT_PATH and review the Security Audits panel on this page before granting filesystem access on sensitive machines.
SKILL.md
READMESKILL.md - Wiki Update
# 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. **Resolve config** — follow the Config Resolution Protocol in `llm-wiki/SKILL.md` (walk up CWD for `.env` → `~/.obsidian-wiki/config` → prompt setup). This gives `OBSIDIAN_VAULT_PATH`, `OBSIDIAN_WIKI_REPO`, `OBSIDIAN_LINK_FORMAT` (`wikilink` default or `markdown`), and optional QMD settings such as `QMD_WIKI_COLLECTION`. Works from any project directory. 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. When writing internal links in Steps 4–5, apply the link format from `llm-wiki/SKILL.md` (Link Format section) using the `OBSIDIAN_LINK_FORMAT` value. ## 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`. Before computing the delta, verify the stored SHA is still reachable: ```bash git merge-base --is-ancestor <last_commit_synced> HEAD ``` - **Exit 0 (ancestor):** Safe. Run `git log <last_commit_synced>..HEAD --oneline` to see what changed. - **Exit 1 (not an ancestor — rebase or force-push occurred):** The stored SHA is no longer in this branch's history. Warn the user: *"Stored commit `<sha>` is no longer reachable — branch may have been rebased or force-pushed. Falling back to full scan."* Then treat as first-time sync: re-scan everything and update `last_commit_synced` to the current HEAD SHA at the end of Step 6. 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)