agentleFS
Ivy-Chen1999Ivy-Chen1999/llm-wiki-kit/skills/wiki-rebuild/SKILL.md

wiki-rebuild

Skill21 starsChanged 4 months 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

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 66
  3. Very specific:

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

    line 70
  4. Very specific:

    Write archive-meta.json with reason "snapshot"

    line 72
  5. Distinctive:

    When the user wants to start fresh.

    line 81
  6. Very specific:

    Remove all content from the category directories (concepts/, entities/, skills/, etc.) and the projects/ directory.

    line 89
  7. Distinctive:

    Important: Don't run the ingest yourself automatically.

    line 108
  8. Distinctive:

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

    line 119
  9. Very specific:

    Read _archives/ directory.

    line 123
  10. Distinctive:

    Ask the user which archive they want.

    line 136
  11. Very specific:

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

    line 140
  12. Distinctive:

    Always archive before destructive operations: No exceptions.

    line 158
  13. Distinctive:

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

    line 159
  14. Very specific:

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

    line 161
  15. Distinctive:

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

    line 162

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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 the vault path (precedence, highest first): the OBSIDIAN_VAULT_PATH environment variable if set, else a .env in the current working directory (vault-scoped), else ~/.obsidian-wiki/config (global default).
  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

{
  "archived_at": "2026-04-06T10:30:00Z",
  "reason": "rebuild",
  "total_pages": 87,
  "total_sources": 42,
  "total_projects": 6,
  "vault_path": "<your vault path>",
  "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. 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:

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

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

Tell the user what was restored and suggest running wiki-lint to check for any issues with the restored state.

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.

Reviews can't be read right now.

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.