agentleFS
chobizzychobizzy/llm-wiki/skills/wiki-rebuild/SKILL.md

wiki-rebuild

Skill3 starsChanged 12 days agoMITView on GitHub

Archive existing wiki knowledge and rebuild from scratch, or restore from a previous archive. Use this skill when the user wants to start fresh, rebuild the wiki from all sources, archive current knowledge before a major change, or restore an older version. Triggers on "rebuild the wiki", "start over", "archive and rebuild", "restore from archive", "nuke and repave", "clean rebuild". Also use when the wiki has drifted too far from sources and incremental fixes won't cut it.

  • Reads credentials

2 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 8 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read .manifest.json to understand current state

    line 18
  2. Distinctive:

    When the user wants to snapshot the current state without rebuilding.

    line 63
  3. Very specific:

    Create archive directory: _archives/YYYY-MM-DDTHH-MM-SSZ/

    line 67
  4. Very specific:

    Write archive-meta.json with reason "snapshot"

    line 69
  5. Distinctive:

    When the user wants to start fresh.

    line 79
  6. Very specific:

    Remove all content from the category folders listed in the CATEGORIES table (references/, entities/, synthesis/, concepts/ in a standard …

    line 87
  7. Distinctive:

    Important: Don't run the ingest yourself automatically.

    line 105
  8. Distinctive:

    When the user wants to go back to a previous state.

    line 118
  9. Very specific:

    Read _archives/ directory.

    line 122
  10. Distinctive:

    Ask the user which archive they want.

    line 135
  11. Very specific:

    Before restoring, archive the current state (reason: "pre-restore") so nothing is lost.

    line 139
  12. Distinctive:

    Always archive before destructive operations: No exceptions.

    line 163
  13. Distinctive:

    Always confirm with the user: before clearing the live wiki.

    line 164
  14. Very specific:

    The .obsidian/ directory is sacred: Never touch it during archive/rebuild/restore — it contains the user's Obsidian settings, plugins, …

    line 166
  15. Distinctive:

    If something goes wrong mid-rebuild, the archive is there.

    line 167

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 (inline @name override → walk up CWD for .env → ~/.llm-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/ (create it on the first archive). Each archive is a timestamped directory containing a full copy of the wiki state at that point: every folder in the vault's CATEGORIES table (AGENTS.md, or llm-wiki layout --json), plus the bookkeeping files. The example shows a standard vault:

$OBSIDIAN_VAULT_PATH/
├── _archives/
│   ├── 2026-04-01T10-30-00Z/
│   │   ├── archive-meta.json
│   │   ├── references/
│   │   ├── entities/
│   │   ├── synthesis/
│   │   ├── concepts/
│   │   ├── index.md
│   │   ├── log.md
│   │   └── .manifest.json
│   └── 2026-03-15T08-00-00Z/
│       └── ...
├── concepts/          ← live wiki
├── entities/
└── ...

archive-meta.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 every category folder listed in the CATEGORIES table, plus index.md, log.md, and .manifest.json, 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 folders listed in the CATEGORIES table (references/, entities/, synthesis/, concepts/ in a standard vault; plus projects/ and any other folder the table lists). Keep the folders themselves (with a .gitkeep) so the layout survives. Keep:

  • _archives/ (obviously)
  • .obsidian/ (Obsidian config)
  • .env (if present in vault)

Reset index.md to an empty catalog: one ## <Folder> heading per CATEGORIES row, then ## Meta (see index.md in llm-wiki/SKILL.md). 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. hermes-history-ingest — to reprocess Hermes history
  4. wiki-ingest — to reprocess documents and any other raw 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:

- [TIMESTAMP] REBUILD archived_to="_archives/2026-04-06T10-30-00Z" previous_pages=87

Refresh QMD after clearing and logging the live wiki (see "QMD Refresh After Live Wiki Changes"), then report that the vault is ready for selected re-ingest skills.

Mode 3: Restore from Archive

When the user wants to go back to a previous state.

Step 1: List available archives

Read _archives/ directory. For each archive, read archive-meta.json and present:

## Available Archives

| Date | Reason | Pages | Sources |
|---|---|---|---|
| 2026-04-06 10:30 | rebuild | 87 | 42 |
| 2026-03-15 08:00 | snapshot | 65 | 31 |

Step 2: Confirm which archive to restore

Ask the user which archive they want. Warn them that restoring will overwrite the current live wiki.

Step 3: Archive current state first

Before restoring, archive the current state (reason: "pre-restore") so nothing is lost.

Step 4: Restore

  1. Clear the live wiki (same as Mode 2, Step 2)
  2. Copy all content from the chosen archive back into the live wiki directories
  3. Restore index.md, log.md, and .manifest.json from the archive
  4. Append to log.md:
    - [TIMESTAMP] RESTORE from="_archives/2026-03-15T08-00-00Z" pages_restored=65

Step 5: Report

Refresh QMD after restore (see "QMD Refresh After Live Wiki Changes"), then tell the user what was restored and suggest running wiki-lint to check for any issues with the restored state.

QMD Refresh After Live Wiki Changes

GUARD: If $QMD_WIKI_COLLECTION is unset — the default — skip this step. QMD is a search index, not the source of truth.

When it is set, read llm-wiki/references/qmd.md and follow the Refresh section once the rebuilt vault files are on disk. A rebuild replaces page content wholesale, so expect the embedding pass to be needed. If refresh fails, keep the rebuilt vault and report the QMD status separately.

Safety Rules

  1. Always archive before destructive operations. No exceptions.
  2. Always confirm with the user before clearing the live wiki.
  3. Never delete archives unless the user explicitly asks. Archives are cheap insurance.
  4. The .obsidian/ directory is sacred. Never touch it during archive/rebuild/restore — it contains the user's Obsidian settings, plugins, and themes.
  5. If something goes wrong mid-rebuild, the archive is there. Tell the user they can restore.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.