Recover and maintain decision provenance in an LLM-Wiki. Use when the user asks why a technical/product decision was made, wants ADRs generated or connected, or needs PRs, issues, discussions, commits, and docs distilled into decision memory.
Decide what belongs in LLM-Wiki versus agent memory, AGENTS.md, CLAUDE.md, Auto Memory, Codex project memory, or other runtime memories. Use when instruction files are bloated, domain facts live in agent memory, or the user wants clean memory boundaries.
Prepare an LLM-Wiki for long-term durability and archival. Use when the user wants a wiki to remain readable in 5-10+ years, export opaque stores, preserve raw sources, rebuild indexes, vendor key references, or create an archive manifest.
Design cross-channel capture architecture and named connector runbooks for LLM-Wiki. Use when the user wants an inbox/raw topology, metadata contract, dedupe boundary, triage handoff, privacy defaults, capture-to-ingestion flow, or Telegram/email/Slack/PDF/GitHub/voice connector rules.
Help a user choose between ready-made LLM-Wiki tools, a local-first workflow, a team rollout, retrieval/GraphRAG systems, or a custom implementation. Use when the user asks what solution fits their needs, whether to use OpenWiki/Obsidian/qmd/GraphRAG, or whether to build their own.
Insert deterministic claim and source anchor IDs after evidence has been inspected. Use when the user wants stable claim IDs, source anchor IDs, support-label formatting, anchor validation, or reproducible claim references; route missing-evidence investigation to llm-wiki-provenance.
Map company/team information flows into an LLM-Wiki adoption plan. Use when the user asks where team knowledge lives, which streams can be automated, how Confluence/Jira/Slack/Drive changes stay synced, how fragile review is, how confidential data is handled, or whether maintenance cost is worth the benefit.
Help resolve contradictions found by wiki-lint, provenance checks, or user review. Use when LLM-Wiki pages disagree about facts, recommendations, tool status, decisions, definitions, or stale claims and the agent should mediate rather than auto-fix truth.
Produce an adversarial risk audit for an LLM-Wiki proposal, domain, vault, rollout, or product plan. Use when the user wants a failure-mode register, bad-fit decision, mitigation plan, residual-risk scorecard, or criticism-first stress test; route short adoption answers to llm-wiki-faq.
Design a custom LLM-Wiki implementation, CLI, Obsidian plugin, repo-docs agent, team workflow, or product architecture. Use when the user wants to build their own system and needs data model, retrieval tier, provenance, storage, sync, review, agent integration, or MVP planning.
Diagnose an existing vault, docs folder, repository wiki, or Markdown knowledge base before changing files. Use when the user asks what is wrong with their current notes/docs, whether they are LLM-Wiki-ready, or what the safest next step is.
Generate domain-specific LLM-Wiki templates, taxonomies, domaintype mappings, stale policies, capture rules, and review gates. Use for research papers, codebase docs, startup research, trading research, personal second brain, team onboarding, competitive intelligence, or other specialized domains.
Build or refresh a current registry of LLM-Wiki implementations and adjacent open-source frameworks. Use when the user asks what projects exist, which technologies are missing, how OpenWiki/nashsu/vouch/RepoAgent compare, or which ready-made implementation to evaluate.
Select evaluation tools and CI gates for LLM-Wiki measurement. Use when the user asks which eval framework, dataset format, scorecard file, red-team config, prompt regression test, hosted/self-hosted service, or human calibration workflow to use; route actual pilot runs to llm-wiki-eval.
Define and execute LLM-Wiki measurement, including bounded pilot benchmarks. Use for usefulness, grounding, maintenance-health, and citation-coverage metrics, baseline vs with-wiki comparison, scoring, and decision gates; route framework/CI choices to llm-wiki-eval-tooling.
Export or publish a safe subset of an LLM-Wiki as public docs, an internal handbook, a static site, llms.txt, JSONL/JSON-LD, graph export, or an archive. Use when publishing from the wiki must preserve provenance and exclude private raw sources, sensitive notes, and draft pages.
Explain LLM-Wiki adoption and answer stakeholder objections. Use when the user wants a concise FAQ response, evidence summary, ROI framing, migration answer, or plain-language rebuttal; route adversarial risk registers and bad-fit audits to llm-wiki-critique-audit.
Configure GitHub Actions for LLM-Wiki maintenance. Use when the user wants scheduled wiki lint reports, PR-based documentation updates, Agent Skills validation, provenance checks, or safe repo-docs maintenance without direct writes to main.
Design an LLM-Wiki team operating model for self-hosted GitLab and internal enterprise environments. Use for GitLab Self-Managed or air-gapped contours with groups, merge requests, CODEOWNERS, approval rules, protected branches, CI/CD, LDAP/SAML, RBAC, audit and compliance.
Design or audit an LLM-Wiki so it remains useful to humans without agents. Use when the user fears an agent-generated document dump or a new Confluence-like mess, or needs human-readable page contracts, navigation maps, and agent-free acceptance tests.
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/llmwiki, Vouch, RepoAgent, llm-wiki-compiler, SwarmVault, Obsidian plugins, or session-transcript wikis.
Design an ingestion and document-conversion stack for LLM-Wiki. Use when PDFs, Office files, web clips, audio/video, code repos, chats, scans, or tables must become source-preserving Markdown, or for source manifests, incremental sync, golden corpora, and ingestion evals.
Extract tacit knowledge into an LLM-Wiki through an agent-led interview. Use when the wiki has open questions, weak areas, onboarding gaps, undocumented decisions, or the user wants voice/text answers turned into draft pages without pretending they are sourced facts.
Design a local-first LLM-Wiki stack. Use when the user wants Markdown, git, Obsidian, ripgrep, local embeddings, qmd-style retrieval, SQLite/FTS/vector indexes, local LLMs, offline operation, or safe sync without cloud lock-in; route retrieval/index layer design to llm-wiki-retrieval-architect.
★not rated 3 19d agoA81 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: