LLM Knowledge Bases

Inspired by a public workflow shared by Andrej Karpathy (@karpathy). From raw research to a living Markdown knowledge base that compounds with every question...

Security Scan

The skill's code, instructions, and file manifest align with its stated purpose: orchestrating a plugin-backed Obsidian Markdown knowledge base; it asks for no secrets, has no installer, and uses only plugin tool primitives described in SKILL.md.

Purpose & Capability

The name/description (manage a Markdown knowledge base) match the included docs and scripts. The skill requires plugin-provided tools (kb_*) which are exactly what the workflow needs. The scaffold script and publish helper are reasonable complements for a repo-oriented workflow.

Instruction Scope

SKILL.md narrowly scopes runtime behavior to calling plugin tools (kb_status, kb_list_raw, kb_read_raw, kb_prepare_source, kb_upsert_source_note, kb_search, kb_read_notes, kb_prepare_output, kb_upsert_output, kb_rebuild_indexes, kb_lint). It explicitly forbids direct generic file writes to the Vault and instructs failure handling. No steps ask the agent to read unrelated system files or exfiltrate data.

Install Mechanism

There is no install spec and no network downloads. The only executables are two small local shell scripts (scaffold and publish). Nothing in the manifest writes arbitrary code to disk or pulls remote archives.

Credentials

The skill requires no environment variables, no credentials, and no config paths. All declared and implicit requirements (plugin tools) are proportionate to operating an Obsidian/Markdown Vault.

Persistence & Privilege

always is false, model invocation is allowed (platform default). The skill does not request persistent elevated presence or modify other skills' configurations. Local scaffold script writes repo files only when run explicitly.

Assessment

This skill appears coherent and self-contained, but before installing: (1) ensure the corresponding Obsidian/LLM Knowledge Bases plugin (the provider of the kb_* tools) is installed and trusted — the skill depends on those primitives to do any Vault I/O; (2) the scaffold script (init_llm_kb_repo.sh) will create directories and a manifest file if you run it — review and, if present, update the 'vault_root' placeholder before pointing any agent at a real Vault; (3) the skill makes no network calls or request secrets itself, but the agent will be able to call the plugin tools autonomously (platform default). Only enable autonomous runs if you trust the plugin and the agent's permissions over your Vault. If you need higher assurance, confirm the plugin implementation and inspect its tool bindings before granting access.

Use this skill to operate a Vault that is managed by the LLM Knowledge Bases plugin.

The operating model is:

• raw/ stores captured Markdown or text source material
• wiki/sources/ stores compiled source notes
• wiki/outputs/ stores archived answer notes
• wiki/_indexes/ stores plugin-generated indexes
• .llm-kb/ stores plugin state

The plugin owns Vault I/O. The agent owns understanding and writing.

Important Model

• The Obsidian Vault may be outside the current workspace.
• Do not assume generic file tools can safely access the Vault.
• Treat the Vault as managed by the plugin.
• Use plugin tools for all Vault reads and writes.
• The plugin performs deterministic execution; the LLM performs the actual compile and answer writing.

Required Tools

• kb_status
• kb_list_raw
• kb_read_raw
• kb_prepare_source
• kb_upsert_source_note
• kb_search
• kb_read_notes
• kb_prepare_output
• kb_upsert_output
• kb_rebuild_indexes
• kb_lint

If these tools are unavailable, say so clearly instead of pretending the workflow can proceed.

High-Level Actions

Treat the following as the three canonical high-level actions for this skill.

compile-changed

Use this when the user says things like:

• compile changed sources
• update the wiki
• ingest the new raw notes
• compile the new material

This is the closest high-level action to the original Karpathy-style "call the LLM to compile" step.

The sequence is:

1. call kb_status
2. call kb_list_raw with changed_only=true
3. for each returned raw file:
   • call kb_prepare_source
   • call kb_read_raw
   • use the LLM to convert the raw content into one valid source note
   • call kb_upsert_source_note
4. after the batch, call kb_rebuild_indexes
5. report successes, failures, and remaining changed files

Important:

• the actual LLM compile happens between kb_read_raw and kb_upsert_source_note
• never guess doc_id, source_note_path, or raw_hash without kb_prepare_source
• never write source notes with generic file tools
• prefer small incremental batches over rewriting many notes at once

ask-and-archive

Use this when the user wants an answer grounded in the wiki and may want it saved.

The sequence is:

1. call kb_search
2. select the most relevant 3 to 8 notes
3. call kb_read_notes
4. answer only from the retrieved notes
5. if the user wants the answer saved:
   • call kb_prepare_output
   • use the LLM to write one valid output note
   • call kb_upsert_output

Important:

• search before answering
• do not cite notes you did not read
• keep source_refs aligned with the source notes actually used

lint-check

Use this when the user wants a deterministic health check of the knowledge base.

The sequence is:

1. call kb_lint
2. report the issues clearly
3. do not auto-fix unless the user explicitly asks
4. if asked to fix, keep the repair narrow and controlled

Writing Rules

Source Notes

Required frontmatter fields:

• id
• type: source
• title
• raw_path
• raw_hash
• source_kind
• tags
• created_at
• updated_at
• status

Required headings:

# Summary

# Key Points

# Evidence

# Open Questions

# Related Links

Writing guidance:

• Summary: short grounded summary of the raw material
• Key Points: concrete takeaways
• Evidence: only claims supported by the raw content
• Open Questions: unresolved uncertainty or follow-up work
• Related Links: only plausible internal links or references, never invented pages

Output Notes

Required frontmatter fields:

• id
• type: output
• title
• query
• source_refs
• created_at
• updated_at

Required headings:

# Answer

# Sources Used

# Follow-up Questions

Writing guidance:

• Answer: directly answer the user's question
• Sources Used: list only source ids actually used
• Follow-up Questions: note worthwhile next questions
• never fabricate source_refs

Safety Boundaries

• Never modify files under raw/.
• Never use generic file-writing tools to modify wiki/ directly.
• Never assume a Vault path is valid unless it came from the plugin or matches the plugin's documented read boundaries.
• Never fabricate source ids, output ids, or Vault paths.
• Never claim a compile or write succeeded unless the plugin confirms it.
• Never bypass the plugin after a tool failure.

Failure Handling

If a plugin tool fails:

• explain the failure in plain language
• keep the user context intact
• propose the next executable step
• do not work around the error by writing directly to the Vault

Language Policy

• Write outward-facing artifacts in English by default.
• Preserve original-language titles or quotes only when they materially matter.
• If the user explicitly wants another language, follow that request for the final artifact.

Finish Standard

When you finish a task with this skill, report:

• what was compiled, answered, or checked
• which plugin tools were used
• which files were created or updated
• any unresolved ambiguity or weak evidence
• the best next one to three follow-up steps