llm-wiki-implementation-deep-dive

name	llm-wiki-implementation-deep-dive
description	Compare concrete open-source LLM-Wiki implementations at architecture depth. Use when the user asks for implementation deep dives, production readiness, architecture patterns, or what to copy from OpenWiki, nashsu/llm_wiki, Vouch, RepoAgent, llm-wiki-compiler, SwarmVault, Obsidian plugins, or session-transcript wikis.
license	MIT
compatibility	Designed for Agent Skills-compatible coding agents. Browse official upstream sources before making current maturity, release, license, activity, compatibility or production-readiness claims.
metadata	{"author":"po4yka","version":"1.0.0","install_scope":"self-contained"}

LLM-Wiki Implementation Deep Dive

Goal

Produce an implementation-level comparison of existing open-source LLM-Wiki systems and extract reusable architecture patterns for a user's adoption plan or custom build.

When to use

• The user asks for an implementation deep dive, architecture comparison, or "what to copy from" for OpenWiki, nashsu/llm_wiki, Vouch, RepoAgent, llm-wiki-compiler, SwarmVault, Obsidian LLM-Wiki plugins, or session-transcript wikis.
• The user is deciding between a repo-docs generator, a full local-first desktop wiki, a review-gated agent-memory system, a compiler-first system, an Obsidian-native workflow, or a session-transcript wiki archetype.
• The user wants production-readiness or licensing guidance before embedding one of these projects.
• The user maintains llm-wiki-skills and wants the ecosystem/stack/deep-dive reference docs refreshed with newly re-verified facts.

Inputs

• User use case: repo docs, personal local-first wiki, governed team wiki, product/reference implementation, Obsidian workflow, session-transcript wiki.
• Candidate projects if named.
• Required comparison dimensions.
• Sensitivity/privacy constraints.
• Whether the user wants recommendation, design patterns, or PR/documentation updates.

Procedure

1. Re-check current upstream facts

Before making current claims, browse official upstream sources for each named project:

• README and docs;
• release/activity/issue signals;
• license;
• install path;
• storage layout;
• retrieval/indexing implementation;
• MCP/API surfaces;
• review/provenance model;
• security and eval docs.

If you cannot verify a current fact, mark it verify-before-use.

2. Classify the project archetype

Use these archetypes:

Archetype	Examples	Primary fit
Repo-docs generator	langchain-ai/openwiki, OpenBMB/RepoAgent	Codebase documentation and coding-agent context.
Full local-first desktop wiki	nashsu/llm_wiki	Personal/local knowledge operating system.
Review-gated agent memory	vouchdev/vouch	Team or governed knowledge where agents propose and humans approve.
Compiler-first knowledge system	atomicstrata/llm-wiki-compiler, smaller compiler projects	Typed, cited, linted, queryable compiled wiki artifacts.
Obsidian-native workflow	green-dalii/obsidian-llm-wiki, other Obsidian plugins	Vault-native human editing and graph-aware retrieval.
Session-transcript wiki	Pratiyush/llm-wiki	Agent session history as raw source material.
Graph-heavy local vault	swarmclawai/swarmvault	Broad ingestion, graph export, context packs and agent handoff.

3. Compare implementation dimensions

Create a matrix with these columns:

| Project | Archetype | License | Maturity | Storage | Retrieval | Ingestion | MCP/API | Review/provenance | Eval/security | Best idea to adopt | Risks |
|---|---|---|---|---|---|---|---|---|---|---|---|

Use references/docs/15-implementation-deep-dive.md as a baseline, then refresh facts with browsing.

4. Extract architectural lessons

Look for these patterns:

• pointer pattern instead of prompt stuffing;
• raw/wiki/state separation;
• durable plain-file storage with rebuildable indexes;
• review-gated durable writes;
• claim-level or paragraph-level evidence;
• progressive retrieval tiers;
• read-only MCP before proposal-write MCP;
• AST/code-structure analysis for repo docs;
• graph-native retrieval for Obsidian vaults;
• session transcript ingestion;
• AI-readable exports such as llms.txt, JSONL, JSON-LD and GraphML;
• eval/lint/security gates.

5. Recommend an adoption path

Route by use case:

Use case	Default path
Code repository docs	OpenWiki-style generated docs, pointer pattern, scheduled PRs; add RepoAgent-style AST analysis only if needed.
Personal local-first wiki	Minimal Markdown/git/Obsidian first; full desktop app if UX matters; hybrid search only after measured misses.
Governed team/company wiki	Vouch-style proposal/approval boundary plus compiler-first typed pages and metadata-filtered retrieval.
Product/reference implementation	Combine compiler, governance, retrieval, MCP, eval, security and export subsystems explicitly.
Obsidian-only workflow	Use graph-native retrieval and protected human sections before adding databases.
Agent-session memory	Treat transcripts as raw sources and add redaction before persistence.

6. Identify repository updates

If the user is maintaining llm-wiki-skills, propose or implement updates to:

• references/docs/13-ecosystem-matrix.md for registry changes;
• references/docs/14-technology-stack.md for stack choices;
• references/docs/15-implementation-deep-dive.md for architecture-level findings;
• related skills such as llm-wiki-ecosystem-registry, llm-wiki-retrieval-architect, llm-wiki-mcp-integration, llm-wiki-security-review, and llm-wiki-eval-tooling.

Output

## Implementation recommendation

## Current-source checks

| Project | Sources checked | Freshness/status | Notes |
|---|---|---|---|

## Architecture comparison

| Project | Archetype | Storage | Retrieval | MCP/API | Review/provenance | Best idea to adopt | Risk |
|---|---|---|---|---|---|---|---|

## Deep dives

### Project name

- Architecture:
- Storage/data model:
- Retrieval:
- Ingestion:
- MCP/API:
- Review/provenance:
- Eval/security:
- Strengths:
- Weaknesses:
- What to copy:

## Recommended stack for the user's case

## Gaps and next research

## Repository updates

Safety gates

• Do not claim a project is production-ready based only on stars or README language.
• Do not recommend GPL-licensed code for proprietary embedding without noting license risk.
• Do not treat repo-docs generators as general personal wiki systems.
• Do not treat broad ingestion as proof of trustworthy knowledge; review/provenance still matter.
• Do not recommend direct-write MCP tools until read-only tools, filters and review gates are tested.
• Do not route sensitive raw sources through cloud parsers/models without explicit policy approval.