knowledge-base

Claude Code Knowledge Base Plugin

Stop re-solving the same problems in Claude Code. A lightweight plugin with two skills that consult and maintain your Obsidian knowledge base automatically — so gotchas, patterns, and hard-won fixes persist across sessions.

Why

LLM sessions forget. You fix a silent Drizzle migration bug on Monday, hit the same bug on Friday, and Claude cheerfully re-derives the wrong fix from conversation memory. This plugin replaces guess-from-memory with research-from-your-KB — using Obsidian (or any markdown vault) as the durable store and two tight skills as the reflex.

• knowledge-lookup — consults a one-line index in your Obsidian vault before Claude guesses. Fires on task start, on errors, on CI failures, on Jira subtask kickoffs, before editing tricky areas (migrations, auth, deploys, nginx, Docker, CORS).
• knowledge-save — captures gotchas and patterns after you solve them, via a rigid 5-item checklist. Fires after surprising behavior, after multi-attempt fixes, after establishing a reusable pattern, or at the end of any Jira implement/fix subtask.

No servers, no API keys, no daemons. Just two skills and a folder structure in your vault.

Install

1. Add the marketplace + install the plugin

claude plugin marketplace add Harsh1210/claude-code-knowledge-base
claude plugin install knowledge-base@knowledge-base-plugin

The marketplace registers under its internal name knowledge-base-plugin (from marketplace.json), so the install command uses @knowledge-base-plugin even though the GitHub repo is claude-code-knowledge-base.

Or from a local clone:

git clone https://github.com/Harsh1210/claude-code-knowledge-base.git
claude plugin marketplace add ./claude-code-knowledge-base
claude plugin install knowledge-base@knowledge-base-plugin

2. Point it at your vault

The plugin expects your Obsidian vault at:

~/Documents/workspace/obsidian-vault/claude-code/

If your vault lives elsewhere, either symlink it or edit the vault path in the two SKILL.md files under skills/knowledge-lookup/ and skills/knowledge-save/.

3. Create the index file

Create a single MOC (Map Of Content) file in your vault. This is the one-line-per-entry index Claude reads on every lookup:

mkdir -p ~/Documents/workspace/obsidian-vault/claude-code/Resources/{gotchas,patterns}
touch ~/Documents/workspace/obsidian-vault/claude-code/Resources/MOC-Knowledge-Base.md

Seed MOC-Knowledge-Base.md with sections like:

# MOC — Knowledge Base

## Gotchas (cross-project)
<!-- newest first -->

## Patterns (cross-project)
<!-- newest first -->

That's it. The plugin does the rest — every new gotcha/pattern adds one line to this file so future lookups are cheap.

4. Restart Claude Code

# quit and relaunch, or in an existing session:
claude plugin list

You should see knowledge-base@knowledge-base-plugin listed.

Test it

Lookup skill

Open a Claude Code session and paste a prompt that should trigger the skill, e.g.:

Starting WFR-84 — I need to add a new column to the accounts table.
It's a Drizzle migration against Postgres. Anything weird I should know
before I run drizzle-kit generate?

Expected: Claude invokes knowledge-lookup, reads MOC-Knowledge-Base.md, and announces either KB hit: [[…]] or KB checked — no matches. The no-matches announcement is the forcing function that proves the skill ran.

Save skill

Paste a "just finished" prompt:

OK — WFR-189 is done. The CI deploy failed twice because I hadn't bumped
the Drizzle journal `when` timestamp above the last applied one — silent
no-op otherwise. Shipping now.

Expected: Claude walks the save checklist, decides this is a gotcha, writes a new file in Resources/gotchas/ with a proper frontmatter + symptom/root-cause/fix template, and prepends a one-line entry to MOC-Knowledge-Base.md. Vault changes are not committed — you review them manually.

How the skills work

Both skills follow a rigid sequence so they're cheap, predictable, and auditable.

knowledge-lookup

1. Load the MOC index (one file, one line per entry).
2. Identify scope: current project slug + tech area + specific keywords.
3. Scan index lines whose scope and keywords match.
4. For reactive lookups (errors), grep full docs for distinctive error strings.
5. Announce findings — KB hit or KB checked — no matches. Always.
6. If no KB entry exists, research the real code/docs/error — never fall back to memory.