Wiki Rebuild
Archive an Obsidian wiki snapshot then rebuild from sources—or restore an old archive—when incremental fixes no longer match upstream docs.
Overview
Wiki Rebuild is an agent skill most often used in Operate (also Build docs) that archives Obsidian wiki state and either rebuilds from all sources or restores a prior archive after user confirmation.
Install
npx skills add https://github.com/ar9av/obsidian-wiki --skill wiki-rebuildWhat is this skill?
- Three explicit modes: archive only, archive + rebuild, or restore from _archives
- Mandatory user confirmation before destructive wiki changes
- Config resolution via .env walk-up and ~/.obsidian-wiki/config for vault path and QMD
- Timestamped full wiki copies under $OBSIDIAN_VAULT_PATH/_archives/
- Triggers when wiki has drifted too far for incremental sync fixes
- Three supported modes: archive only, archive + rebuild, restore
- Archives stored under $OBSIDIAN_VAULT_PATH/_archives/ as timestamped directories
Adoption & trust: 2.1k installs on skills.sh; 1.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent-managed Obsidian wiki no longer matches upstream repos and docs, and patching note-by-note will take longer than a controlled rebuild.
Who is it for?
Maintainers of obsidian-wiki style vaults who need a documented disaster-recovery path before major source or skill changes.
Skip if: Casual note edits or single-page fixes—use incremental wiki sync skills instead of a full archive-and-rebuild.
When should I use this skill?
User wants to rebuild the wiki, start over, archive and rebuild, restore from archive, nuke and repave, clean rebuild, or when wiki drift exceeds incremental repair.
What do I get? / Deliverables
You get a timestamped archive for rollback, then either a clean regenerated wiki or a restored snapshot from `_archives` once intent is confirmed.
- Timestamped archive directory under _archives
- Rebuilt wiki tree from all sources or restored prior archive state
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because rebuild addresses drift and maintenance debt in a living knowledge base, not first-time authoring. Iterate fits destructive refresh cycles: archive, confirm intent, reprocess sources, or roll back to a prior timestamped snapshot.
Where it fits
After adding major new repos to the wiki config, archive the old graph and rebuild so onboarding docs match current APIs.
Run archive-only before experimenting with a new ingestion skill so you can restore if link graph breaks.
Restore `_archives/2026-...` when a bad automated merge polluted hundreds of wikilinks.
Refresh public-facing internal wiki mirrors right before launch after confirming a clean rebuild snapshot.
How it compares
Destructive maintenance workflow for whole vaults, not a lightweight markdown formatter or single-file linter.
Common Questions / FAQ
Who is wiki-rebuild for?
Solo builders running Obsidian-based agent wikis who own vault integrity and need archive-first rebuild or restore procedures.
When should I use wiki-rebuild?
In Operate when drift blocks trust in the wiki; in Build docs when onboarding a new source corpus and you want a clean baseline after archiving the old tree.
Is wiki-rebuild safe to install?
It performs destructive vault operations after explicit confirmation—review the Security Audits panel on this page and verify backups before archive + rebuild or restore.
SKILL.md
READMESKILL.md - Wiki Rebuild
# Wiki Rebuild — Archive, Rebuild, Restore You are performing a destructive operation on the wiki. Always archive first, always confirm with the user before proceeding. ## 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` and optional QMD settings such as `QMD_WIKI_COLLECTION` 2. Read `.manifest.json` to understand current state 3. **Confirm the user's intent.** This skill supports three modes: - **Archive only** — snapshot current wiki, no rebuild - **Archive + Rebuild** — snapshot, then reprocess all sources from scratch - **Restore** — bring back a previous archive ## The Archive System Archives live at `$OBSIDIAN_VAULT_PATH/_archives/`. Each archive is a timestamped directory containing a full copy of the wiki state at that point. ``` $OBSIDIAN_VAULT_PATH/ ├── _archives/ │ ├── 2026-04-01T10-30-00Z/ │ │ ├── archive-meta.json │ │ ├── concepts/ │ │ ├── entities/ │ │ ├── skills/ │ │ ├── references/ │ │ ├── synthesis/ │ │ ├── journal/ │ │ ├── projects/ │ │ ├── index.md │ │ ├── log.md │ │ └── .manifest.json │ └── 2026-03-15T08-00-00Z/ │ └── ... ├── concepts/ ← live wiki ├── entities/ └── ... ``` ### archive-meta.json ```json { "archived_at": "2026-04-06T10:30:00Z", "reason": "rebuild", "total_pages": 87, "total_sources": 42, "total_projects": 6, "vault_path": "/Users/name/Knowledge", "manifest_snapshot": ".manifest.json" } ``` ## Mode 1: Archive Only When the user wants to snapshot the current state without rebuilding. ### Steps: 1. Create archive directory: `_archives/YYYY-MM-DDTHH-MM-SSZ/` 2. Copy all category directories, `index.md`, `log.md`, `.manifest.json`, and `projects/` into the archive 3. Write `archive-meta.json` with reason `"snapshot"` 4. Append to `log.md`: ``` - [TIMESTAMP] ARCHIVE reason="snapshot" pages=87 destination="_archives/2026-04-06T10-30-00Z" ``` 5. Optionally refresh QMD if `log.md` is indexed and `QMD_WIKI_COLLECTION` is configured (see "QMD Refresh After Live Wiki Changes"). 6. Report: "Archived 87 pages. Current wiki is untouched." ## Mode 2: Archive + Rebuild When the user wants to start fresh. This is the full sequence: ### Step 1: Archive current state Same as Mode 1 above, but with reason `"rebuild"`. ### Step 2: Clear live wiki Remove all content from the category directories (`concepts/`, `entities/`, `skills/`, etc.) and the `projects/` directory. Keep: - `_archives/` (obviously) - `.obsidian/` (Obsidian config) - `.env` (if present in vault) Reset `index.md` to the empty template. Reset `log.md` with just the rebuild entry. Delete `.manifest.json` (it'll be recreated during ingest). ### Step 3: Rebuild Tell the user the vault is cleared and ready for a full re-ingest. They can now run: 1. `wiki-status` — to see all sources as "new" 2. `claude-history-ingest` — to reprocess Claude history 3. `codex-history-ingest` — to reprocess Codex session history 4. `wiki-ingest` — to reprocess documents 5. `data-ingest` — to reprocess any other data Each of these will rebuild the manifest as they go. **Important:** Don't run the ingest yourself automatically. The user should choose what to re-ingest and in what order. Some sources may no longer be relevant. ### Step 4: Log the rebuild Append to `log.md`: ``` - [T