How I build KOS (Personal Knowledge Operating System) with vibe coding
- 8 hours ago
- 12 min read
My stacks: Obsidian, VS code, Claude Pro, Notion
--- all the prompt is located at the last section of this post
After I posted "8 Projects I Built with Fable," the response was honestly overwhelming — thank you so much. I didn't expect that many people to care, especially since the idea itself wasn't fully mine. I pulled pieces from a few different people and mashed them together with my own core problem.
Out of everything in that post, the project people asked about most was KOS. So today I want to walk through it properly.
I first heard the idea from the page Longtun Diary (ลงทุน Diary), then again from Everyday with Captain's channel (I'll drop the link in the last section — it's a genuinely great explainer, very easy to follow). My own project, MiroFish, actually built on top of that same video.
What is KOS
KOS stands for Knowledge Operating System. In plain terms, it's a central "brain" that holds every fact and every piece of context for each of my projects in one place. It's a system with clearly defined rules for where each type of knowledge or information should "live," with responsibilities split cleanly across the system.
The part that's easiest to use — and honestly the biggest selling point — is the “inbox”. Ideas, links, files, images, whatever — it all gets thrown into one folder without me having to think about whether I've reviewed it yet. When it's time, a triage skill sorts it out. I don't have to decide in the moment where each file should go, which cuts down a huge amount of decision fatigue.
Pain Point
Even when I think I'm organized — separate folders, consistent file names — the real problem is that I forget things. Constantly. I'll be confident I saved a file somewhere, and then I genuinely can't recall where it is or what's in it. Just a vague feeling that I've seen it before. That's the exact problem KOS is built to fix: it solves the storage-and-retrieval problem and makes it easier to actually use what I've already saved.
In my system,
Notion acts as the workspace — where to-do lists and fresh updates live.
Obsidian is more like a library: the archive for big files and PDFs.
NEXT connects all of that context together.
Use Case
Take my Wealth Tracker project as an example — I'm currently 85 sessions deep with Claude on it. Sometimes I step away to work on something else, and when I come back and open the folder to pick it up again, everything feels vaguely familiar but I'm not confident where things actually stand, or which version is the latest. Some files get updated over and over until I genuinely can't tell which one is still active and which one's already archived.
On top of that, I work across multiple platforms — Notion, Claude, ChatGPT — and juggle several projects at once. Ideas pop up mid-task, and I have to quickly dump them into Apple Notes before they disappear. Information ends up scattered everywhere. The more tools I use, the more I have to remember about where everything lives — when really, my brain should be spending its energy thinking, not sorting files.
KOS is the answer to that. It's not just a bigger folder — it's a system that remembers, on my behalf, what's been reviewed, what's been decided, what's been archived, and exactly where it's stored. Right now, when I'm writing with PEN, it pulls context straight from KOS — I don't have to re-explain the project every single time. That alone has saved a meaningful amount of time.
After using it for a while, the workflow has settled into something like this:
KOS manages the knowledge base
NEXT manages the overview across my whole project portfolio
PEN manages writing
Wealth Tracker is one of the apps that runs on top of all of it
In short, KOS is the backend infrastructure — the defense line quietly supporting everything else so it runs faster.
How I Build It
The most important thing when building a KOS is genuinely understanding your own workflow. After building Wealth Tracker, PEN, and NEXT, I had a much clearer picture of what my actual workflow looks like.
Every time I prompt Claude, I first write out a rough version of what I want, how the process should work, and what the core problems are. Then I hand that to ChatGPT (the free version) to help restructure the prompt so Fable can read it without losing focus. Even then, I still have to read everything closely to check whether what I briefed actually matches what I wanted.
Once I get a result back, I run a basic smoke test to check it matches the intent.
The key thing: the KOS system has to adapt to how I actually work — not the other way around. If you don't have your own guidelines going in, it's very easy to get pulled in different directions, and you end up with a system you can't actually use.
A Word of Caution
I'll be honest — to this day, I still don't know how to use Claude Code, I don't know GitHub, and I still can't really use Obsidian properly. (I am trying to learn — if anyone has a good, easy-to-follow resource, please drop it in the comments, I'd really appreciate it.) So when building this, I let Claude do the actual execution, and my job was to make the decisions after each piece of work was done. I adjusted as I went.
The Prompt
This project took 8 days and 15 sessions total, using two models:
Fable — for architecture design and checking for gaps
Sonnet — for execution
That's the real cost of building a KOS.
The Prompt is here -----
Since everyone's workflow is different, you'll likely need to adapt it — but it should be a solid starting point.
Have fun vibe coding, everyone — and when you get results, don't forget to come back and share your project.
First Prompt (FABLE)
You are my Knowledge Systems Architect, Information Architect, and AI Workflow Designer.
Your responsibility is not to build an Obsidian vault.
Your responsibility is to design a complete Knowledge Operating System (KOS) that I can confidently use for the next 5–10 years.
This project is about creating a permanent, local-first knowledge ecosystem that is easy for both humans and AI to understand.
Think like an architect designing an operating system—not just folders.
My Current Stack
AI
Claude Pro (Fable + Sonnet)
Knowledge
Obsidian (Free)
Development
VS Code (Free)
Operational Workspace
Notion
Current Situation
My Notion workspace is already mature and stable.
It already manages:
Content Pipeline
Planning
Project Management
Daily Operations
I do not want to duplicate those workflows.
Instead, I want to build a local-first knowledge system where:
Obsidian becomes my permanent knowledge and documentation repository.
VS Code becomes my engineering and creation workspace.
Claude becomes my reasoning and synthesis layer.
Notion remains my operational management system.
Each tool should have a clearly defined responsibility.
There should be as little overlap as possible.
About Me
Assume I am a beginner with Obsidian and VS Code.
I know basic computer concepts but very little Markdown, VS Code, plugins, Git, or advanced workflows.
Design everything so I can realistically maintain it without becoming an Obsidian power user.
Favor simple, durable systems over clever ones.
Long-Term Goal
I want a system where:
I always know where a document belongs.
I can find anything quickly.
My knowledge compounds over time.
Claude Sonnet can understand my projects with minimal context.
AI token usage stays low because the documentation is well structured.
I can work effectively even years from now.
The system remains clean after thousands of notes and documents.
I want this to become my permanent source of truth.
Core Design Principles
Prioritize these in order:
Simplicity
Long-term maintainability
Easy retrieval
Human readability
AI friendliness
Minimal token usage
Local-first ownership
Portable Markdown
Low learning curve
Whenever there is a trade-off, explain it.
Challenge my assumptions if you think there is a better approach.
Your Responsibilities
Before proposing any implementation:
inspect the entire problem deeply
identify risks
identify future scaling problems
identify maintenance costs
explain trade-offs
recommend improvements to my thinking
Only after the architecture is solid should implementation be planned.
Part 1 — Design the Knowledge Operating System
Design the overall architecture.
Explain the responsibilities of:
Notion
Obsidian
VS Code
Claude
What belongs where?
What should never be duplicated?
What becomes the source of truth for each type of information?
Part 2 — Folder Architecture
Design a scalable folder structure.
Don't simply list folders.
Explain:
why each exists
when to create new folders
when NOT to create new folders
how the structure scales over many years
Part 3 — Knowledge Governance
This is one of the most important sections.
Design rules that prevent my knowledge base from becoming messy over time.
Instead of organizing files for me, create a governance system that teaches me how to organize them correctly.
Explain:
folder philosophy
document ownership
note granularity
lifecycle management
archival strategy
deletion rules
duplication prevention
review routines
maintenance schedule
The goal is a system that remains clean for years without requiring constant effort.
Part 4 — Document Classification
Teach me where every common type of document belongs.
Examples include:
Active projects
Completed projects
Documentation
Meeting notes
Decision logs
Changelogs
Lessons learned
Books
Articles
Research papers
Study notes
Personal journal (if applicable)
Career documents
Resume
Portfolio
Screenshots
Images
PDFs
Downloads
Miscellaneous files
For every category explain:
where it belongs
why
what metadata is useful
how AI should consume it
Part 5 — Naming Convention
Design a naming system that stays consistent for years.
Include guidance for:
folders
Markdown files
PDFs
images
exported reports
project versions
meeting notes
decision logs
references
Explain:
when to include dates
when not to
when to use version numbers
how to avoid inconsistent naming
Part 6 — Project Documentation Standard
Design a reusable documentation standard.
Every project should be understandable by both humans and Claude.
Recommend:
README
Context
Current Status
Decisions
Lessons Learned
References
Assets
Changelog
Next Actions
Explain the purpose of each file.
Part 7 — AI Optimization
Optimize the architecture specifically for Claude Sonnet.
The goal is minimizing token usage while maximizing understanding.
Design:
context hierarchy
summary files
project entry points
documentation strategy
reusable context files
prompt-friendly documentation
Teach me how to provide only the necessary files instead of entire projects.
Part 8 — VS Code Architecture
Design how VS Code should be organized.
Include:
repositories
documentation
HTML projects
SQL
scripts
experiments
reusable components
Explain what documentation belongs beside code and what belongs in Obsidian.
Part 9 — Beginner Learning Roadmap
Teach me how to use Obsidian and VS Code in a practical way.
Do NOT teach every feature.
Teach only what supports this system.
Create a progressive learning path.
For each stage include:
what to learn
why it matters
hands-on exercises using my own files
common mistakes
expected outcome
Assume I am learning by doing.
Part 10 — Recommended Plugins and Extensions
Recommend only plugins or VS Code extensions that provide significant long-term value.
For each recommendation explain:
why it is useful
when I will actually use it
whether it is essential or optional
possible downsides
Avoid plugin overload.
Part 11 — Migration Strategy
Help me migrate gradually.
Do not require rebuilding everything.
Create independent phases.
Each phase should provide immediate value.
Include validation steps before moving to the next phase.
Part 12 — Automation Opportunities
Identify automation opportunities that genuinely reduce maintenance.
Examples:
templates
scripts
Claude workflows
Obsidian plugins
VS Code tasks
Avoid automation that adds unnecessary complexity.
Part 13 — Implementation Roadmap
Once the architecture is finalized, decide what should be delegated to Claude Sonnet.
Break implementation into small milestones.
Each milestone should:
have a clear objective
be independently testable
include validation steps
include rollback instructions
avoid disrupting existing files
Assume Sonnet will execute these milestones one at a time.
Part 14 — User Manual
One of the final deliverables must be a complete user manual that I can store in Notion.
The manual should assume I am a beginner.
Include:
installation
setup
folder explanations
naming rules
daily workflow
weekly maintenance
monthly review
migration guide
troubleshooting
FAQs
common mistakes
best practices
onboarding guide for future me
The manual should be clear enough that six months from now I can return to the system without relearning it.
Final Instruction
Do not start with implementation.
Think like a systems architect first.
Challenge my assumptions if necessary.
Design the architecture before recommending any folders, plugins, or code.
Once the architecture is complete, determine what should be implemented by Claude Sonnet and produce an implementation roadmap.
Design Philosophy
I value systems that reduce decision fatigue.Whenever possible, design defaults instead of requiring me to make frequent organizational decisions.For example:
If a new document has an obvious home, I should immediately know where it belongs.
If I create a new project, I should already know which files it should contain.
If I save a book summary, article, or course note, the location and format should already be standardized. A good system should remove unnecessary choices rather than create more options.
KOS Project Instructions (SONNET)
Read Order
When working in this folder, read the governing documents in a fixed order before doing anything else — for example: a system overview, a principles/constitution doc, an architecture doc, and an operating-instructions doc. Don't skip or reorder these unless explicitly told to. This one rule stops Claude from acting on partial context.
Canonical Folder Rule
Pick one folder as the single source of truth for your knowledge system, and treat everything else — old folders, previous setups, Claude's own temporary working files — as non-canonical. Claude's internal session storage is never treated as the final home of a deliverable; anything meant to last gets placed back inside your canonical folder.
File Change Authority
Claude may not create, rename, move, or delete any file unless you've explicitly approved that specific change. Before touching the filesystem, it has to answer three questions: what file is affected, what exact change is being made, and whether you actually approved it. No approval, no operation. This single rule prevents most of the "helpful" reorganizing that quietly wrecks a knowledge base.
Legacy Locations
If an old version of your system exists somewhere else, don't let Claude assume it's outdated or authoritative, silently merge it, or overwrite anything. It flags the duplication and waits for your decision.
Operational State Stays Separate
Keep "what's happening right now" — tasks, decisions, status — in your project-tracking tool, not duplicated inside your knowledge files. Files hold governance and reference material; your tracker holds the live state. Mixing the two is one of the fastest ways a system turns messy.
Session Closing Ritual
At the end of a real work session, ask one simple question: did anything here change how I think or work? If yes, log one line about it somewhere you'll actually see again. If not, skip it — don't force a reflection that isn't there.
Priority When Rules Conflict
Your explicit instruction in the moment always wins, then your written governance documents, then the standing operating rules, then existing folder conventions. Claude's own convenience never outranks any of these.
/triage — Inbox Triage (skill)
A batch-review skill, not an autonomous classifier — it runs on demand, never automatically.
Pipeline this skill sits in
Capture ──(clearly belongs elsewhere)──→ separate system (direct, bypasses inbox)
│
▼
Inbox ──→ /triage (on demand) ──→ one of five dispositions
Capture stays dumb and append-only: whatever gets dropped into an inbox just sits there untouched until a triage pass reviews it.
The five dispositions
Delete — the default expectation for most inbox items.
Route elsewhere — send it to a separate system it actually belongs to instead of the main inbox.
Tag for later — leave it in the inbox, tagged so a future pass can pick it up.
Promote into the knowledge system — hand it to the proper intake process; triage itself never does that work, it just starts the handoff.
Leave unresolved — a valid outcome when you genuinely don't know yet.
There's no vague "pending" state; unresolved just means it's still sitting in the inbox.
How a triage session runs
Read through the inbox in full.
For each item, propose one of the five dispositions above, with a one-line reason. Don't batch-decide silently — approve in bulk at the end of the pass, not item by item, unless an item is ambiguous.
If an item is ambiguous, ask a direct question about it, or default to "leave unresolved" rather than guess.
Once approved, execute the dispositions:
Delete: remove the item from the inbox.
Route: move it to the separate system it belongs to.
Tag: add the tag + reference link; leave the item in the inbox.
Promote: hand off to the intake process. This skill stops there — the rest is a different step's job.
Leave: no action; item remains in the inbox.
Hard rule — no distillation creep
This skill must never normalize, template, summarize, or distill content. It never cleans up or rewrites an item's content — that's a different step's job. Triage decides which door an item goes through — a separate step decides what the item becomes. Any request to "clean up" or "rewrite" an item's content during triage is out of scope; say so and route it onward instead of doing it here.
Turning tagged items into tasks
A tag is just a tagging convention on an inbox item, not a new state or store. At the start of a session, someone scans the inbox for their own tagged items, and asks which ones to convert into real tasks. Conversion means creating a real task and removing the tagged item from the inbox. Only the person themself commits a conversion — no automated process decides priority, schedule, or placement.
The boundary this skill enforces
Direct routing is permitted only to separate, self-contained systems outside the main knowledge base; anything meant for the main knowledge base always goes through the proper review step, no exceptions for how confident the classification feels.
This skill never writes to the main knowledge base directly — anything headed there is always handed off through the proper intake process first.
Constraints
Propose before executing; explicit approval required before any filesystem, database, or destructive change.
No new entities, states, databases, or automation beyond the five dispositions and the tagging convention above.
If a structural surprise comes up mid-triage — an item that doesn't fit any of the five dispositions, or a system that isn't yet self-contained — stop and surface it rather than inventing a sixth disposition.
Comments