Building a personal IT knowledge base that outlives the chat window
I kept solving IT problems and forgetting how. The fix wasn't a smarter AI, it was a separate Markdown repository that holds my own troubleshooting history, with a rule that the AI writes the notes but never becomes the memory.
I solve IT problems and then forget how I solved them.
That sounds careless, but it's mostly a storage problem. I might spend an hour working through an Intune issue with an AI, get it fixed, and move on. Six months later something similar happens and I start from zero, because the whole investigation is buried in a chat log I will never scroll back through.
What I wanted was for that hour to become something I own. Not a transcript. A note I can find later. The second goal came after: I wanted to write technical blog posts from things I have actually done, instead of the kind of generic article an AI can produce about any topic on request.
The one decision the rest depends on#
The Markdown knowledge base is the source of truth, not the AI.
Everything else follows from that. The AI helps me write notes. It does not hold them. If I stop using any particular assistant tomorrow, my knowledge is still sitting in plain text files in a Git repository, and I can point some other tool at it.
Setting it up#
Started on my Fedora laptop:
mkdir -p ~/knowledge
cd ~/knowledgeThen came the folder structure, and this is where I nearly made a mistake. The obvious layout is something like Linux/, Networking/, Cybersecurity/. Tidy on paper. It also doesn't match how anything actually arrives at my desk.
My work comes in as specific vendors, specific applications, specific devices. A Huawei switch problem isn't a "networking" problem in any useful sense when I'm looking for it later, so the structure is built around what I actually touch:
knowledge/
├── 01-Environment/
├── 02-Microsoft/ Intune, Entra ID, Windows
├── 03-Networking/ Huawei, HP Aruba, Cisco, FortiGate, Ruckus
├── 04-Resort-Applications/ Opera PMS, MICROS Symphony, 3CX, IPTV
├── 05-Devices/ Printers, POS, IP phones, tablets, computers
├── 06-Infrastructure/ Servers, VMware, NAS, backup, monitoring
├── 07-Linux/
├── 08-Cybersecurity/
├── 09-Troubleshooting/
├── 10-Projects/
├── 11-Lessons-Learned/
└── 12-Blog/Why troubleshooting gets its own tree#
This is the part I'd keep if I had to throw away everything else.
There are two kinds of information here, and they behave differently. The first kind is reusable: 02-Microsoft/Intune/BitLocker.md tells me how something works, and I read it when setting up a new device. The second kind is an incident, a specific problem on a specific day with a specific device, filed under 09-Troubleshooting/ with a dated filename.
That file records the story: problem, symptoms, investigation, failed attempts, solution, verification, root cause, lesson learned.
The failed attempts are the reason the split exists. Vendor documentation tells you the correct configuration. It won't tell you that you spent forty minutes on the wrong theory first, and it won't stop you from having the same wrong theory again next year. My own incident notes will.
Teaching the AI the rules#
A CLAUDE.md in the repository root describes what belongs in each folder, how incidents and commands get written up, and how credentials are handled.
The rule I care about most: never invent my experience. If I configured something, it gets documented as mine. If the AI knows something from general technical knowledge instead, it gets labelled as technical knowledge, not personal experience. A suggestion should never end up written as a thing I supposedly did. Once that line blurs, the whole archive becomes untrustworthy, and an untrustworthy reference is worse than no reference, because I will act on it.
So notes carry labels: personal experience, technical knowledge, procedure, troubleshooting, lesson learned, recommendation, blog idea.
Keeping secrets out#
The repository describes a real production environment, so .gitignore went in before anything else did:
.env
*.key
*.pem
*.p12
*.pfx
credentials/
passwords/
private/Alongside a writing rule: not password MyRealPassword, but password <REDACTED>. Same for API keys, tokens, private keys, and anything device-specific that shouldn't travel. The repository syncs to a cloud service and gets read by AI tools, so the habit needs to be automatic rather than something I remember to apply.
Git, GitHub, Obsidian#
cd ~/knowledge
git init
git remote add origin git@github.com:<you>/knowledge-base.git
ssh -T git@github.comPrivate repository, main as the default branch, SSH for authentication. Then Obsidian, opened directly on ~/knowledge as a vault. Obsidian isn't a second copy of anything: it reads the same Markdown files Git tracks, so I get a browsable interface without giving up ownership of the format. That was the whole point of choosing Markdown in the first place.
What I got wrong at first#
I assumed I needed the AI to capture everything automatically. Every conversation logged, nothing lost.
That would have ruined it. Most of my conversations aren't worth keeping. If all of them became permanent notes, finding the useful ones later would take longer than just solving the problem again, which defeats the exercise.
What works better is the reverse. I troubleshoot normally, and when something turns out to be worth keeping, I ask for it directly: turn this troubleshooting session into a structured Markdown knowledge note. The output gets read before it goes anywhere. I check that nothing was invented, credentials are gone, and it's filed in the right place.
That review step isn't optional. It's where I catch the AI writing something plausible that didn't happen.
Where the blog comes in#
Instead of asking for an article about Intune, which produces exactly what you'd expect, I can ask something grounded: search my knowledge base for my actual Intune troubleshooting experience and find topics that could become posts.
The knowledge repository isn't the blog repository, though. A separate project manages this blog and deploys it to my VPS, and only content I choose to publish moves across:
IT Knowledge -> GitHub -> Blog project -> Blog repository -> VPS -> WebsiteThe separation is deliberate. My notes contain internal network architecture, vendor configurations and operational detail about a live environment. None of that should become public because a pipeline made it convenient. The blog is a curated selection from the knowledge base, never a mirror of it.
What I'm building, really#
The blog was the goal I started with, but it isn't the part I value most.
What's accumulating is a record of my own technical career. Every problem I work through can become knowledge, then a lesson, and sometimes an article. The same notes are useful for troubleshooting, for study, for certification prep, and for interviews.
The test will be whether I can eventually ask "show me every Huawei troubleshooting incident I've had" or "what are the biggest lessons I've learned in IT" and get a real answer back, built from things that actually happened. Right now the structure exists and the content is still thin. Ask me again in a year.