When working with LLMs I find myself needing to update or correct the model with information specific to my work environment. The in-house processes, bespoke systems, and tribal knowledge of how things work for our organization is just not something that the model has been trained on. After repeating myself a few too many times, I thought there might be a better way to give the model access to that knowledge in a scalable way that allows me to augment the LLMs training data with a personalized knowledge base specific to me.

The solution I came up with is pretty simple and involves two parts: the first is a local wiki of personal knowledge, and the second is teaching the model to reference the local wiki with a skills file. An optional third part is having the LLM update the knowledge base.

Part One: a local wiki for the personal knowledge base

The local wiki can be anything accessible to an LLM. In my case, I used a folder of Markdown files in Obsidian format. Obsidian is a note-taking app that stores all of its files as local Markdown documents, with the added benefit of being able to link between documents using wikilinks. You don’t particularly need to use Obsidian for this, and can instead write Markdown directly. The benefit I saw from using Obsidian is that it ties into an ecosystem with some loose standards on how to organize, tag, and link information together. Tagging and linking help create a full featured searchable knowledge base for both agents and myself.

I populated the knowledge base with some internal documentation. As a simple example, I listed out the different AWS environments and Kubernetes clusters in use at work, with a bit of guidance on the meaning for each. This is a short snippet from the environment guide I have in Obsidian today.

Workiva environments fall into three tiers:

- **Dev** — development and testing. Open to all employees. Runs in
  the Dev AWS account.
- **Corp** — internal tooling (CI, Docker registry, dev portals). Runs in
  the Corp AWS account. Deploys go through Release Management.
- **Prod** — customer-facing. Runs in the Prod AWS account (or
  region-specific accounts). Deploys go through Release Management.

Of course, your situation will be different and your knowledge base would reflect the private knowledge specific to you or your organization. With the knowledge base in place, the second part of this solution is teaching the LLM to search the knowledge base for specific information.

Part Two: interacting with the knowledge base

To teach the LLM to use the knowledge base to find workplace-specific information, I used an agent skill. The skill is pretty simple and just notes when and how the agent should consult the knowledge base before answering a question.

This is the full skills file I am using today:

---
name: knowledge-base
description: Consult the Workiva platform knowledge base before answering questions about infrastructure, deployment, CI/CD, security, observability, or Kubernetes at Workiva. Use when the user asks about workiva.yml, wk CLI, Vault secrets, GitHub Actions workflows, SLOs, Dockerfiles, cluster components, pod sizing, probes, deploy/migration planning, NetworkPolicies, IAM, messaging consumers, RDS, Helm wrapping, or runbooks/postmortems.
---

# Workiva Knowledge Base

The Obsidian vault at `/Users/kevinsookocheff/Documents/Obsidian/Workiva`
is the authoritative local reference for Workiva's platform. Do not
answer from general knowledge when vault content exists — the platform
has Workiva-specific tooling and conventions that differ from defaults.

## Always read the relevant README first

- `environment-guides/README.md` — indexed TOC for how the platform works
- `operation-guidelines/README.md` — indexed TOC for what good looks like

## Follow wikilinks

Files use Obsidian `[[wikilinks]]` to cross-reference related content.
Follow them — a link from `ips.md` to `workiva-deploy.md` means those
systems interact and understanding both matters. The **Related** section
at the bottom of each file is the fastest way to find adjacent context if
needed.

## Out of scope

The vault does not cover:
- Service-specific business logic (check the service repo's `CLAUDE.md` or README)
- Team-specific runbooks (check the service repo)
- Real-time cluster state (use `kubectl`, Datadog, or the RMConsole)

Part Three: building the knowledge base

Lastly, I needed a way to easily update the knowledge base whenever I found myself repeating information during LLM interactions.

For this, I used a second skill explaining how to create and update notes in Obsidian:

---
name: obsidian
description: Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.
---

# Obsidian Vault

## Vault location

`/Users/kevinsookocheff/Documents/Obsidian/Workiva`

## Linking

- Use Obsidian `[[wikilinks]]` syntax: `[[Note Title]]`
- Notes link to dependencies/related notes at the bottom
- Index notes are just lists of `[[wikilinks]]`

## Workflows

### Search for notes

```bash
# Search by filename
find "/Users/kevinsookocheff/Documents/Obsidian/Workiva" -name "*.md" | grep -i "keyword"

# Search by content
grep -rl "keyword" "/Users/kevinsookocheff/Documents/Obsidian/Workiva" --include="*.md"

Or use grep/glob tools directly on the vault path.

Create a new note

  1. Use Title Case for filename
  2. Write content as a unit of knowledge (per vault rules)
  3. Add [[wikilinks]] to related notes at the bottom
  4. If part of a numbered sequence, use a hierarchical numbering scheme

Search for [[Note Title]] across the vault to find backlinks:

grep -rl "\\[\\[Note Title\\]\\]" "/Users/kevinsookocheff/Documents/Obsidian/Workiva"

Find index notes

find "/Users/kevinsookocheff/Documents/Obsidian/Workiva" -name "*INDEX*"

Now, to update the knowledge base with new information, I can invoke the /obsidian skill to have the LLM update the skill on my behalf.

And that’s it! We have a personal knowledge base integrated with the LLM to answer Workiva-specific questions easily and consistently.