AutoGineer
Generated banner for LLM Knowledge Bases
Generated logo for LLM Knowledge Bases

LLM Knowledge Bases

LLM wiki kit

First committed by rvk7895

Published in rvk7895/llm-knowledge-bases. Publisher page

35 GitHub stars

What it is

Claude Code plugin for building LLM-maintained Obsidian wikis from raw research — compile, query, lint, and evolve your personal knowledge base. Inspired by Karpathy's knowledge base workflow.
— the description by rvk7895

AutoGineer overview, from the brain’s own files

LLM Knowledge Bases is a plugin for Claude Code designed to automate the creation and maintenance of a personal knowledge base in Obsidian. By treating the LLM as a knowledge compiler, the system ingests raw materials—such as articles, papers, and transcripts—and organizes them into a structured, interlinked wiki. Users interact with the system by feeding raw data into a designated folder, while the agent handles the compilation, indexing, and health maintenance of the vault. It supports multiple query depths, ranging from quick index lookups to deep, multi-agent research pipelines, ensuring that the knowledge base evolves alongside the user's research interests.

How it works

Memory model: LLM wiki

AutoGineer overview, from the brain’s own files

The system operates by ingesting raw source documents from a raw folder. It then compiles these into an Obsidian vault containing summaries, backlinks, and indexes. Users can query the knowledge base at three levels of depth: quick, standard, or deep. The system also performs automated maintenance tasks like linting for broken links or orphans and provides tools for deep research, which involves generating outlines and deploying parallel agents to research specific topics. All outputs are saved to an output folder or integrated back into the wiki.

Folders
FolderRoleFiles
.claudeagent-config1
docsdocs2
.claude-pluginfolder1
pluginsfolder12

Requirements

Works with: Claude Code, OpenCode

Set it up

  1. This brain runs code automatically: 1 script. Review plugins/kb/setup.sh before opening the folder in Claude Code. No step below turns a hook on for you.

    • plugins/kb/setup.sh: sh plugins/kb/setup.sh
  2. Download the brain as a ZIP and unzip it where you keep your notes or project: https://mp-staging.autogineer.com/agent-brains/rvk7895/llm-knowledge-bases/download

  3. Claude Code reads CLAUDE.md from this folder automatically.

  4. cd llm-knowledge-bases && claude

  5. AutoGineer scanned these files at commit 342686f.

  6. Not scanned by AutoGineerThe author’s README also describes installing it as a Claude Code plugin marketplace. Read its install section: AutoGineer did not scan that path. https://github.com/rvk7895/llm-knowledge-bases/blob/342686f4cdf0e969872601eabbcc10466da91431/README.md#installation

  7. First committed by rvk7895. Published in rvk7895/llm-knowledge-bases. Licence: MIT License.

Usage

AutoGineer overview, from the brain’s own files

  • Initialize a new knowledge base structure
  • Compile raw research documents into an Obsidian wiki
  • Query the knowledge base for information at varying depths
  • Perform automated health checks on the wiki
  • Execute deep research on specific topics using multi-agent pipelines
“/kb compile”
The agent processes all files in the raw/ directory and updates the Obsidian wiki with new summaries and backlinks.
“/research-deep Artificial Intelligence trends”
The agent generates a research outline and launches parallel agents to conduct deep research on each item in the outline.
“/kb lint”
The agent scans the wiki for broken links, orphans, and inconsistencies, reporting them for resolution.

Documentation by rvk7895

LLM Knowledge Bases

A Claude Code plugin that turns raw research material into an LLM-maintained Obsidian wiki -- inspired by Andrej Karpathy's description of using LLMs as knowledge compilers rather than just code manipulators.

You drop source material into raw/, run a single command, and Claude handles the rest: compiling interlinked wiki articles, maintaining indexes and backlinks, answering complex questions at multiple depth levels, and continuously improving the knowledge base over time.

The LLM owns the wiki. You rarely edit it manually -- just explore in Obsidian and keep feeding it raw data.

How It Works

  1. Ingest -- Raw documents (articles, papers, repos, YouTube transcripts, images, datasets) go into raw/

  2. Compile -- Claude builds a structured Obsidian vault with summaries, backlinks, concept articles, and auto-generated indexes

  3. Query -- Three depth levels:

    • Quick -- Answers from wiki indexes and summaries alone

    • Standard -- Cross-references the full wiki, supplements with web search

    • Deep -- Multi-agent research pipeline with parallel web search agents

  4. Output -- Markdown reports, Marp slides, matplotlib charts -- saved to output/ and optionally filed back into the wiki

  5. Maintain -- Automated health checks (broken links, orphans, inconsistencies) and suggestions for new articles and connections

Prerequisites

Obsidian plugins (Dataview, Obsidian Git, etc.) are installed automatically by the setup script during /kb-init.

Installation

In Claude Code, run:

/plugin marketplace add rvk7895/llm-knowledge-bases
/plugin install kb@llm-knowledge-bases

All skills are installed as a single plugin.

Quick Start

# Initialize a new knowledge base
/kb-init

# Add sources to raw/, then compile the wiki
/kb compile

# Query the knowledge base
/kb query

# Run a health check
/kb lint

# Deep multi-agent research on a topic
/research <topic>
/research-deep

Available Skills

SkillPurpose
kb-initOne-time setup: scaffolds directories, generates config, writes project files
kbMain skill with four workflows: compile, query, lint, evolve
researchGenerate a structured research outline for a topic
research-deepLaunch parallel agents for deep research on each outline item
research-add-fieldsAdd field definitions to an existing research outline
research-add-itemsAdd research targets to an existing outline
research-reportCompile deep research results into a markdown report

Directory Structure (after /kb-init)

raw/           -- Raw source documents
wiki/          -- LLM-compiled Obsidian vault
output/        -- Query results, slides, charts, reports
kb.yaml        -- Configuration
CLAUDE.md      -- Project instructions for Claude

X/Twitter Integration (Optional)

To ingest tweets, threads, and bookmarks from X, install Smaug:

npm install -g @steipete/bird
git clone https://github.com/alexknowshtml/smaug && cd smaug && npm install
npx smaug setup  # configures X session cookies

Once configured, paste any x.com link and the kb skill will fetch and compile it automatically. Without Smaug, you can still add X content by pasting tweet text directly or using Thread Reader App for threads.

Note: Smaug uses X session cookies for read-only access to your own data. This is not officially supported by X's TOS. Practical risk for personal use is very low, but be aware.

Attribution

  • Andrej Karpathy -- Original vision for LLM-maintained knowledge bases

  • Weizhena -- Deep Research skills adapted for the research pipeline

plugins/kb/references/report-style-guide.md

Report Style Guide — Factory Defaults

Source of factory-default text for report_preferences fields in a vault's kb.yaml.

Read by: kb-init (at vault creation) and kb-preferences (at reset time).

Not read at report-generation time. Once a vault is initialized, kb.yaml's report_preferences: block is authoritative. Skills (research-report, kb compile, kb query) load preferences from kb.yaml, not this file.

Format: one top-level section per preference field. Each section has a ### Default subsection (used when the user accepts defaults) and zero or more ### Variant (...) subsections that the init skill can pick from based on user answers.

How init uses this file: the init skill reads the user's free-text answers to the 5 onboarding questions, picks the best-matching variant per field, optionally adjusts wording with the user's specific phrasing, and writes the result into kb.yaml as a free-text string. The resulting field is the working rule — it does not reference this file afterward.

audience

Who the report is written for. Shapes framing, polish level, and hedging.

Default (for own learning)

For my own learning and reference. Skip polish. Favor depth over summary. Honest framing about what's documented vs my own interpretation — say "I think" when I'm interpreting, "the paper says" when I'm citing. Flag [uncertain] claims explicitly, don't hide them behind confident prose. No need for executive-summary wrappers or "in this report we will" throat-clearing. Assume the reader (me) is willing to read carefully.

Variant (for team audience)

For a small internal team. Assume shared context on broad topic but not on specific technical details. Light polish. Keep opinion sections labeled. Include a short TL;DR at the top. Technical depth OK but glossaries for terms specific to this investigation.

Variant (for external / publication)

For external readers (blog post, paper, public share). Polished prose. Strong opening. Clear thesis. Every claim citeable. Remove "I think" hedges in favor of explicit confidence markers. No raw [uncertain] flags — either verify the claim or drop it. Structured like a paper: introduction, body sections, discussion, limitations.

register

Tone and sentence-level style.

Default (plain)

Plain, direct language. Short sentences — split multi-idea sentences on an em-dash or semicolon rather than stacking clauses with "and", "which", "that". Drop academic connectives (notably, crucially, indeed, it should be noted, moreover, furthermore). Active voice. First person is allowed and preferred over hedges like "one might observe". Contractions are fine. Paragraphs run 3–5 sentences, not 10-sentence walls. Prefer plain words over Latinate alternatives: use not utilize, show not demonstrate, because not owing to the fact that, help not facilitate, about not with respect to, part not component (usually), thing when it's actually just a thing.

No scaffolding. Drop sentences that announce what the next section will do. "This subsection explains X", "before we discuss Y, let's set the scene", "the four subsections below follow the same template: 1. ... 2. ..." — all scaffolding. The reader discovers structure by reading. Drop forward-reference promises too ("we'll come back to this", "more on this below"); just come back to it when you do.

No production-process narration. Describe what was surveyed and which sources were consulted, not who/what did the surveying or what pipeline produced the output. "We reviewed the README, DeepWiki pages, and arXiv paper per system" is fine; "N parallel sub-agents made X tool calls", "drawn from per-item JSONs with 100% validator coverage", "each sub-agent covered 2 items" are not. Pipeline artifacts are irrelevant to a reader trying to understand findings.

No self-evaluation. Don't grade your own analysis inside the analysis. "The report's sharpest original analysis", "this is the most important insight", "the key takeaway here" are self-grading. Present the analysis; let the reader judge what's sharp or important. You can label a section "Where this might be wrong" — that's flagging a weakness, not grading a strength.

Variant (formal)

Formal, polished prose suitable for a paper or white paper. Full sentences, no contractions. Third person or impersonal constructions OK. Academic connectives are fine in moderation — but still don't overuse them. Defined technical vocabulary expected; glossaries optional. Paragraph length flexible.

Variant (casual)

Conversational tutorial tone. Second person ("you'll notice"). Contractions throughout. Short punchy sentences. Humor and asides allowed. Occasional lists where prose would be tedious.

depth

How much content per item and how much cross-cutting synthesis.

Default (deep walkthroughs)

Fewer items covered more thoroughly. For a survey of N items, each item gets a multi-paragraph profile: who built it, when, what it is in one sentence, what problem it solves, its interface (with at least one concrete example), an analogy to something the reader likely knows, and how it relates to the other items. Appendix-style dossiers for the full set when the survey is large. Cross-cutting synthesis sections that compare items across axes (patterns, taxonomies, timelines) — these are the value-add over just listing items.

Variant (survey)

Broad coverage. Short per-item sections (1–2 paragraphs max). Emphasis on completeness of the set, not depth per item. Comparison tables do most of the work. Cross-cutting analysis is shorter — one section, not multiple.

Variant (overview)

Top-level map only. Named items, one-line description each, grouped. Cross-cutting analysis becomes the main content. Use when the goal is to orient the reader, not to teach them details.

code_handling

How to incorporate code into reports. Scales with codebase count and snippet length.

Default (mixed — scales by codebase count and snippet size)

Small snippets (under ~30 lines): inline in a code block, immediately followed by a prose walkthrough naming each moving part. The reader should not need to open an editor for these.

Larger snippets or full files: link to the source URL (github, local path, or wherever the code actually lives). A short prose explanation in the report. Don't reproduce entire files inline.

Deep walkthroughs of 1–2 codebases: this is the case where asking the reader to open their editor is reasonable. Tell them which files to open, then guide line-by-line with file:line references. The report acts as narration.

3+ codebases: switch to link-heavy mode. For each codebase, link to the relevant file/function on github (or a permalink), pull out the 5–10 key lines inline if they're worth dissecting, and keep prose lean. The reader uses links to context-shift between codebases.

Never reproduce entire codebases inline. If you find yourself writing more than ~100 lines of quoted code in one section, something has gone wrong.

Variant (inline-walkthrough)

All code inline regardless of length, with aggressive annotation. Report is self-contained — reader never has to leave the document. Suitable for tutorials, not surveys.

Variant (link-external)

Minimal inline code. Every code reference is a link to the source. Report is short and dense; reader does the navigation.

diagrams

Visual aids — what kind, when to use them.

Default (ascii + tables)

ASCII diagrams for flows, pipelines, and block-level relationships. Markdown tables for comparing items across axes. Mermaid only when specifically requested — ASCII renders reliably everywhere, mermaid does not. Drop diagrams when prose is equally clear; don't add them as decoration. For hierarchies and taxonomies, tables almost always beat tree diagrams.

Variant (mermaid)

Mermaid diagrams preferred for flows and state machines. Tables still used for multi-axis comparisons. Reader is on a platform that renders mermaid (Obsidian, GitHub, Notion).

Variant (prose-only)

No diagrams. All relationships expressed in prose, optionally supported by tables. Use when the target environment does not render diagrams reliably, or when the reader prefers reading over viewing.

self_containment

How much context the report carries inside itself vs deferring to external sources.

Default

Every term is glossed the first time it appears. Every project, model, paper, or tool mentioned gets a mini-profile the first time it appears: who built it (org / team), what it is in one sentence, when it came out. No [see appendix] deferrals in the main narrative — either inline the context or don't mention the thing yet. Interface examples (API calls, config files, CLI invocations) shown with enough surrounding context that the reader can parse them without guessing. Bare code drops without context are not acceptable.

Applies to depth-default reports, not survey/overview reports (where mini-profiles would bloat the prose).

Variant (loose)

Assume shared background on the topic. Introduce only the items that are novel to this specific report. Use when writing follow-ups or for readers who asked for this report in the context of a larger investigation.

citations

How to handle references, attributions, and primary sources.

Default (ground in published literature)

Ground every taxonomic and historical claim in published literature. Cite with arXiv ID, venue (or "preprint" if unpublished), and publication date. Format: Author et al. "Title." arXiv:2509.02547 (TMLR, Jan 2026). Distinguish three kinds of claims:

  • Inherited: directly taken from a cited source. Cite it.

  • Extended: built on a cited source but adds new analysis. Cite the source, then mark what's new.

  • Original: claim that the report is making for the first time. Say so explicitly, and note it's not yet peer-reviewed.

Save every cited PDF or blog to raw/papers/ (or raw/articles/) so the sources live with the vault. When a cited source disagrees with current code or current project state, flag the disagreement explicitly — don't pretend it doesn't exist.

Variant (for-self loose references)

Loose references are fine. Link to sources when convenient. No strict format. Save obviously-important sources to raw/ but don't make a production of it.

argument_iteration

How to structure and validate non-trivial arguments (justifying a design, defending a taxonomy, etc.).

Default

For any non-trivial argument (more than a paragraph, making a claim that could reasonably be challenged):

  1. Draft the argument with explicit premises and conclusion.

  2. Advisor pass. Call advisor() for a second opinion on the argument's structure and assumptions.

  3. Verifier pass. Dispatch a custom subagent briefed on argument analysis: identify hidden premises, find the strongest counter-argument, stress-test the conclusion. Not a code reviewer — an argument reviewer.

  4. Revise with a changelog noting what was weakened, strengthened, or dropped in response to the verifier's critique.

  5. Engage the strongest counter-arguments, not straw versions. If the verifier names a counter-argument, it gets its own subsection, not a dismissive footnote.

  6. Every argument section ends with "Where this might be wrong" — a real list of genuine threats to the argument, not decorative humility. This section is one of the most important parts of any report.

Skip this iteration for arguments that are just restating uncontroversial facts or summarizing a single source.

Variant (loose)

One draft, one revision. No verifier loop. Use for quick memos or when the argument is genuinely uncontroversial.

Applying this file

kb-init reads this file during vault setup, asks the user 5 open-ended questions about how they want reports written, picks the best-matching ### Default or ### Variant for each preference field, and writes the result into the vault's kb.yaml under report_preferences:. The user's specific phrasing may be woven into the default text.

After init, the vault's kb.yaml is the authoritative source. This file is consulted again only during:

  • /kb-preferences reset <field> — copies the factory default for one field back into kb.yaml

  • /kb-preferences reset-all — full regeneration from this file + re-asked questions

  • /kb-preferences init — re-runs the init flow

Skills never read this file at report-generation time.

21 files

Advantages

  • Automates the maintenance of interlinked wiki articles and indexes, reducing manual effort. evidence: README.md
  • Supports multi-agent research pipelines for deep, parallel investigation of topics. evidence: README.md

Limitations

  • Requires Claude Code CLI and Obsidian to function. evidence: README.md
  • The LLM owns the wiki, and manual editing of articles outside of the provided workflows is discouraged. evidence: CLAUDE.md

Security

Risk level: Medium risk

This brain runs

Install scripts (1)

  • plugins/kb/setup.sh: sh plugins/kb/setup.sh · uses the network

Agent instructions that run or fetch something (44)

  • plugins/kb/skills/kb-init/SKILL.md: After confirming the vault path, run the bundled setup script via Bash tool:
  • plugins/kb/skills/kb-init/SKILL.md: The script is idempotent — safe to re-run.
  • plugins/kb/skills/kb-init/SKILL.md: python -c "import pptx" 2>/dev/null && echo "python-pptx: available" || echo "python-pptx: not installed (needed for slide extraction)"
  • plugins/kb/skills/kb-init/SKILL.md: python -c "import pandas" 2>/dev/null && echo "pandas: available" || echo "pandas: not installed (needed for dataset analysis)"
  • plugins/kb/skills/kb-init/SKILL.md: When the user sets up Smaug (during init or later), save the install path here.
  • plugins/kb/skills/kb-preferences/SKILL.md: If missing, tell the user to run `kb-init` and stop.
  • plugins/kb/skills/kb-preferences/SKILL.md: | Invocation | Mode | Action | |---|---|---| | `/kb-preferences` (bare) | interactive | Show current prefs, ask what to update | | `/kb-preferences init` | init | Re-run the 5 init questions, regenerate all fields from style-guide + user answers | | `/kb-preferences update <field>` | up …[+30 chars]
  • plugins/kb/skills/kb-preferences/SKILL.md: re-ask matching question or accept free-text | | `/kb-preferences add-note "..."` | add-note | Append the quoted string as a new line/paragraph under `notes:` | | `/kb-preferences reflect` | reflect-now | Run the reflection step against the current conversation explicitly | | `/kb-pref …[+164 chars]
  • plugins/kb/skills/kb-preferences/SKILL.md: If missing, tell user to run `/kb-preferences init` first and stop.
  • plugins/kb/skills/kb-preferences/SKILL.md: Confirm loudly: "This will replace all 9 fields with factory defaults and re-run the 5 init questions.
  • plugins/kb/skills/kb/SKILL.md: If missing, tell the user to run `kb-init` and stop.
  • plugins/kb/skills/kb/SKILL.md: Run `/kb-preferences init` to customize."
  • plugins/kb/skills/kb/SKILL.md: After a compile or query finishes writing its output, run a **lightweight reflection step** — only propose preference updates for **high-confidence signals**:
  • plugins/kb/skills/kb/SKILL.md: The user can run `/kb-preferences reflect` manually if they want a forced pass.
  • plugins/kb/skills/kb/SKILL.md: Run lightweight reflection at the end.
  • plugins/kb/skills/kb/SKILL.md: **Detection heuristic:** Run this check for each file:
  • plugins/kb/skills/kb/SKILL.md: Please provide a transcript, or install: pip install openai-whisper"
  • plugins/kb/skills/kb/SKILL.md: Try: `yt-dlp --write-auto-sub --sub-lang en --skip-download --output "/tmp/%(id)s" "<url>"` to get subtitles · uses the network
  • plugins/kb/skills/kb/SKILL.md: Try extracting with python-pptx: `python -c "from pptx import Presentation;
  • plugins/kb/skills/kb/SKILL.md: For Parquet: `python -c "import pandas as pd;
  • plugins/kb/skills/kb/SKILL.md: Run lightweight reflection at the end (after the answer is delivered;
  • plugins/kb/skills/kb/SKILL.md: Run the appropriate pipeline.
  • plugins/kb/skills/kb/SKILL.md: Run the graph health script if available:
  • plugins/kb/skills/kb/SKILL.md: python plugins/kb/scripts/graph_health.py "<vault_path>" --json --fix-suggestions
  • plugins/kb/skills/kb/SKILL.md: Run the evaluation script if available:
  • plugins/kb/skills/kb/SKILL.md: python experiments/evaluate.py "<vault_path>" --json
  • plugins/kb/skills/kb/SKILL.md: If user approves, execute the improvements
  • plugins/kb/skills/kb/SKILL.md: Re-run evaluation to measure improvement
  • plugins/kb/skills/kb/SKILL.md: Run: `npx smaug fetch <tweet_id>` then `npx smaug process`
  • plugins/kb/skills/kb/SKILL.md: **Install Smaug** (recommended) — `git clone https://github.com/alexknowshtml/smaug && cd smaug && npm install`, then `npx smaug setup` to configure X session cookies (`auth_token` + `ct0` from browser DevTools → Cookies → x.com). · uses the network
  • plugins/kb/skills/kb/SKILL.md: After setup, **save the install path to `kb.yaml`** under `integrations.smaug.path`.
  • plugins/kb/skills/kb/SKILL.md: Try to fetch transcript: `yt-dlp --write-auto-sub --sub-lang en --skip-download --output "/tmp/%(id)s" "<url>" 2>&1` · uses the network
  • plugins/kb/skills/kb/SKILL.md: If yt-dlp not installed: try `pip install yt-dlp` then retry
  • plugins/kb/skills/kb/SKILL.md: Extract video metadata: `yt-dlp --dump-json "<url>" 2>/dev/null | python -c "import sys,json; · uses the network
  • plugins/kb/skills/kb/SKILL.md: On the next `/kb compile` run (for compile-time context searches)
  • plugins/kb/skills/kb/SKILL.md: Forgetting to dispatch the auto-evolve subagent after a query -- it must always run, even if it usually exits silently
  • plugins/kb/skills/research-add-items/SKILL.md: Execute simultaneously:
  • plugins/kb/skills/research-deep/SKILL.md: Execute in batches by batch_size (need user approval to proceed to next batch after completing one)
  • plugins/kb/skills/research-deep/SKILL.md: After completing JSON output, run validation script to ensure complete field coverage:
  • plugins/kb/skills/research-deep/SKILL.md: python ~/.claude/skills/research/validate_json.py -f {fields_path} -j {output_path}
  • plugins/kb/skills/research-deep/SKILL.md: After completing JSON output, run validation script to ensure complete field coverage:
  • plugins/kb/skills/research-deep/SKILL.md: python ~/.claude/skills/research/validate_json.py -f /home/weizhena/AIcoding/aicoding-history/fields.yaml -j /home/weizhena/AIcoding/aicoding-history/results/GitHub_Copilot.json
  • plugins/kb/skills/research-report/SKILL.md: **If `kb.yaml` itself is missing:** tell the user to run `kb-init` and stop.
  • plugins/kb/skills/research-report/SKILL.md: Run `python {topic}/generate_report.py`
  • Medium risk: runs-install-script-network-variable-host (plugins/kb/setup.sh)
  • Medium risk: network-variable-host (plugins/kb/setup.sh:81)
  • Medium risk: runs-instruction-instruction-network (plugins/kb/skills/kb/SKILL.md:206)
  • Medium risk: runs-instruction-instruction-network (plugins/kb/skills/kb/SKILL.md:571)
  • Medium risk: runs-instruction-instruction-network (plugins/kb/skills/kb/SKILL.md:596)
  • Medium risk: runs-instruction-instruction-network (plugins/kb/skills/kb/SKILL.md:600)
  • Low risk: network-instructions (.claude/settings.local.json:14)
  • Low risk: scripts-present (plugins/kb/setup.sh)
  • Low risk: network-instructions (plugins/kb/skills/kb/SKILL.md:202)
  • Low risk: autonomy-phrase (plugins/kb/skills/kb/SKILL.md:402)

Attribution and licence

First committed by
GitHub avatar of rvk7895rvk7895
Publisher
Ritvik Aryan Kalra (Community)
Source
rvk7895/llm-knowledge-bases · commit 342686f
Licence
MIT License (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
ritvik-sarvam, rvk7895

AutoGineer is not affiliated with or endorsed by rvk7895.

Download

The ZIP holds the files AutoGineer serves, with ATTRIBUTION.md and the licence. Download llm-knowledge-bases.zip