Llm wiki vault manager

LLM Wiki Vault Manager

Overview

Use this skill to maintain a durable learning vault where raw sources, wiki notes, schema/instructions, indexes, logs, and git history stay separate and auditable.

The end goal is to help the user and their AI agents absorb a chosen area over time: collect material, convert it into source-backed knowledge, expose questions and tensions, and turn stable repeated workflows into new validated skills.

Default to the local vault's rules first: read AGENTS.md, then wiki/index.md, then search the relevant wiki and raw source files.

Resource Map

• For vault layout, page types, frontmatter, naming, and log conventions, read references/vault-schema.md.
• For source ingestion and question-answering workflows, read references/ingestion-and-query.md.
• For git review, GitHub setup, commit, push, and safety gates, read references/git-and-review.md.
• For downloading raw material and converting repeated vault work into Codex skills, read references/acquisition-and-skill-distillation.md.
• For area-learning loops and skill-evolution signals, read references/learning-loop.md.
• For Claude Code portability and installation, read references/claude-code-transfer.md.
• To scaffold a new vault, run scripts/scaffold_llm_wiki_vault.py.
• To scaffold a learning area inside a vault, run scripts/scaffold_learning_area.py.
• To lint an existing vault, run scripts/lint_llm_wiki_vault.py.
• To plan or execute Git/GitHub vault publishing, run scripts/publish_vault_to_github.py.
• To plan where a provided link or file belongs, run scripts/plan_raw_intake.py.
• To scan for repeated workflows that may become skills, run scripts/scan_skill_candidates.py.
• To validate and export a Claude Code copy, run scripts/export_to_claude_code.py.

Operating Rules

1. Treat raw/ as immutable source material after capture.
2. Keep source facts separate from interpretation.
3. Link factual claims to source notes with Obsidian wikilinks or cite raw source paths.
4. Update durable wiki pages only after reading the relevant source note or raw source.
5. Preserve contradictions, tradeoffs, and stale claims in wiki/tensions/.
6. Ask before deleting notes, bulk-renaming files, rewriting taxonomy, or overwriting raw sources.
7. Before any git or GitHub publish, inspect the actual diff and exclude unrelated user work.
8. Treat enrichment, ingest, update, save, or sync requests as user intent to review, summarize, commit, and push the resulting vault changes when the vault is already git-managed.
9. Treat first-time GitHub repo creation, visibility changes, destructive git actions, and risky or unrelated worktree changes as explicit approval gates.

Workflow

Orient

1. Read AGENTS.md or equivalent vault instructions.
2. Read wiki/index.md if it exists.
3. Run a targeted search over wiki/, templates/, and relevant raw/ files.
4. Run git status --short --branch before edits when the vault is git-managed.
5. Identify the requested operation: scaffold, define a learning area, intake links/files, ingest, query, synthesize, lint, publish, acquire sources, or distill a skill.

Learn An Area

Use this when the user wants the vault to help them and their AI agents learn a domain, field, tool, workflow, or research area.

1. Define the learning area as a project, question set, or synthesis target.
2. Collect raw materials into the proper raw/ categories.
3. Convert each source into a source summary before making broad claims.
4. Maintain concept, entity, question, synthesis, and tension pages as the area matures.
5. Keep wiki/index.md useful as the learning map.
6. Periodically identify repeated workflows, useful heuristics, scripts, or checklists that should become skills.
7. Distill only stable, source-backed patterns into new or updated agent skills for Codex, Claude Code, or another Agent Skills-compatible tool.

For a new area, use scripts/scaffold_learning_area.py to create the starter project and question notes, then review and revise them before ingesting sources.

Scaffold A Vault

Use this when creating a new LLM-wiki vault or repairing a missing framework.

Run:

python path/to/scripts/scaffold_llm_wiki_vault.py /path/to/vault

Then review the generated AGENTS.md, templates/, wiki/index.md, and wiki/log.md before adding content. Do not overwrite an existing taxonomy unless the user explicitly asks.

Ingest Sources

Use this when the user provides papers, articles, transcripts, docs, bookmarks, notes, or downloads to add to the vault.

1. Classify each provided link or file by source type and topic.
2. Preserve the raw source under the proper raw/<category>/ directory, using the existing vault convention when one is present.
3. If the source is a URL or cannot be stored directly, create a source card under raw/<category>/<YYYY-MM-DD>-<slug>-source-card.md.
4. Create or update one source summary under wiki/sources/<category>/<slug>.md.
5. Extract source facts, relevance, best-practice signals, uncertainties, and raw links.
6. Update related concept, entity, project, question, synthesis, and tension pages.
7. Add backlinks both from the source summary and from updated topic pages.
8. Update wiki/index.md so the new source and any new page type are discoverable.
9. Append an entry to wiki/log.md with the date, action, source, raw path, and updated notes.
10. Run the lint script and fix issues caused by the ingest.

Answer Vault Questions

Use this when the user asks a knowledge question about the vault.

1. Read wiki/index.md first.
2. Search relevant wiki pages and source summaries.
3. Answer from source-backed notes, citing note wikilinks or raw paths.
4. Separate source-backed claims from interpretation.
5. If the answer is durable or reusable, ask whether to save it as a synthesis or question note.

Lint And Maintain

Run:

python path/to/scripts/lint_llm_wiki_vault.py /path/to/vault

Use lint results as prompts for careful review, not as permission to rewrite the vault. Fix broken links, missing frontmatter, missing raw pointers, stale index entries, unlogged changes, and orphan source notes when the fix is clear.

Auto-Publish After Enrichment

When the user asks to enrich, ingest, update, save, or sync a git-managed vault, finish with a reviewed commit and push unless the user explicitly opts out.

1. Complete the content work first: raw capture, source summaries, linked wiki pages, wiki/index.md, and wiki/log.md.
2. Run the vault lint script when available and fix issues caused by the current work.
3. Run git status --short --branch, git diff --stat, and targeted diffs for representative changed files.
4. Inspect wiki/log.md, wiki/index.md, and representative new or changed source/concept/question/synthesis/tension notes.
5. Stage only reviewed vault changes. Exclude unrelated user work, credentials, transient caches, generated bytecode, and local skill source repositories unless the user explicitly wants those included.
6. Derive a concise commit subject from the actual diff and latest vault log entries, such as Ingest AI Engineer agent videos or Update agent configuration notes.
7. Commit and push to the configured upstream branch.
8. Final response must include the commit SHA, subject, pushed remote/branch, a brief change summary, and whether the working tree is clean.

Pause before commit/push only when the review finds unrelated/risky changes, missing auth or remote setup, destructive operations, possible secrets, or an explicit user request not to publish.

Publish With Git And GitHub

Use the Git/GitHub workflow after content edits are complete and reviewed. For normal enrichment requests in an existing git-managed vault, this is automatic; do not ask for a second confirmation unless an approval gate applies.

1. Read references/git-and-review.md.
2. Run python scripts/publish_vault_to_github.py /path/to/vault --repo OWNER/REPO --message "Commit subject" without --execute to see the plan when setup is uncertain. Use --auto-message when a reviewed existing vault update needs a generated fallback subject.
3. Run git status --short --branch, git diff --stat, and targeted git diff.
4. Inspect wiki/log.md, wiki/index.md, and representative changed notes.
5. Confirm whether the vault already has .git, origin, and an upstream branch.
6. If the vault is not yet on GitHub, use gh auth status, create or choose the repo, add origin, and push main.
7. Stage only reviewed vault changes.
8. Commit with a concise subject derived from the diff and vault log.
9. Push to the configured remote.
10. Verify GitHub visibility/URL, final status, upstream branch, and latest commit.

If the vault-git-publish skill is available, use it for the final review/commit/push portion.

Acquire Raw Material

Use official APIs, connected apps, browser tools, or command-line fetches according to the user's available connectors and permissions. Preserve provenance: URL, retrieval date, author, publication date, source type, and license/access notes when available. Do not flatten downloaded material directly into syntheses; first save or place the material in raw/, create a raw source card when needed, then create a source summary.

Distill Reusable Skills

Use this when repeated vault work becomes a reusable agent workflow.

1. Search the vault for source-backed notes about the workflow.
2. Check whether the pattern is repeated, useful beyond one source, and stable enough to guide a future agent.
3. Identify stable operating rules, scripts, reference docs, and examples.
4. Run scripts/scan_skill_candidates.py when the vault is large enough that candidates are not obvious.
5. Use the skill-creator skill if available.
6. Create the smallest useful skill: concise SKILL.md, optional scripts, optional references, and optional platform metadata.
7. Keep the core skill portable: make SKILL.md and referenced scripts/ or references/ usable without Codex-only UI metadata.
8. Validate the skill with the skill validator and, for Claude Code, run the export script in dry-run or real export mode.
9. Install outside the vault only with user approval when that requires writing outside the workspace.