Every week I re-explain the same architecture choices to my AI coding
agent. New session, zero memory — like we never talked. That's not a
prompting problem, it's a memory problem, and I fixed it with a
git-based knowledge system that lives right next to the code. Here's
the actual walkthrough, the schema it writes, and where it falls
short — not just the pitch.
I plan a feature with Claude Code on Tuesday. Wednesday, fresh
session: "Where did we leave off?" No idea. I re-explain everything.
By Thursday I've explained it a third time to a different agent. Each
one asks good questions, gets a good answer, and forgets it the moment
the session ends. The plan was never the problem — nothing durable
ever got written down, so there was nothing for the next session to
read.
kms
is a Claude Code plugin that captures decisions, facts, and
guardrails as plain markdown files, version-controlled right alongside
your code. Any agent that reads the repo reads the knowledge base
first, before it asks you anything.
Install:
/plugin marketplace add vivantel/kms
/plugin install kms
Four artifact types, each with one job:
| Type | Answers | Lives in |
|---|---|---|
| Fact | What's true right now | docs/facts/ |
| Decision | What you're committing to, and why | docs/decisions/ |
| Guardrail | What must (or must not) happen, derived from a decision | docs/guardrails/ |
| Skill | How to act on all of the above | docs/skills/ |
One command:
/kms:quickstart
If docs/{facts,decisions,guardrails,skills}/
doesn't exist yet,
quickstart sets it up first. Then it asks one direct question:
"What decision or plan is currently live for you right now?"
Say you're picking an auth provider. Quickstart interviews you — what
you're choosing, why, what would make this wrong — then writes the
result to docs/decisions/0001-auth-provider-choice.md
:
---
id: 0001-auth-provider-choice
title: Use Auth0 for user authentication
status: accepted
date: 2026-09-03
tags: [auth, infra]
track: product
---
## Decision
Auth0 for all user-facing auth. Rejected rolling our own — team of
two, no time to own session security. Rejected Firebase Auth — we're
not on the rest of the Firebase stack and didn't want the lock-in.
## Rationale
...
Nothing gets summarized or paraphrased away — that's your call,
captured once, in your own words. The session closes by naming what to
run next, not leaving you to guess: query
to pull this decision back
up later with a citation, capture
after the next session that
touches it.
From that point on, Claude Code
reads that file the next time it opens the repo and knows exactly
what was decided. Codex reads the same skill set through its own
plugin manifest. Kilo Code CLI reads it too, once kilo.jsonc
points
at the published skills manifest.
Facts and guardrails link back to why they exist, not just what they
say. Say you decide Medium posts close with an install CTA, Dev.to
posts close with a GitHub-stars ask. That's a decision. The guardrail
that enforces it on every article cites that decision by id. A skill
that tells you how to adapt a draft per platform references the
guardrail. Change the decision later, and capture
/lint
catch the
guardrail and skill silently drifting out of sync with it — instead
of you finding out three articles later.
Commands worth knowing once you've got a knowledge base going:
query
— retrieve a past decision with a citation, instead of
re-explaining it.capture
— log what a work session changed, after the fact; flags
contradictions it finds along the way.lint
— validate the whole knowledge base on demand: dangling
references, missing fields, stale derived artifacts.brainstorm
— generate fresh approaches with no anchor to past
decisions, for exploring before anything's locked in.onboard
— a role-tailored, 5-day ramp-up plan for a new teammate,
built from the existing knowledge base.conform
— check whether a pending change respects the guardrails before it lands.It's not magic memory — you still write the interview answers
yourself; quickstart just makes sure they get written down instead of
staying in your head. It doesn't replace tests, code review, or
actual documentation for end users. And it only helps if the habit
sticks — a knowledge base nobody updates after month one is just a
docs/
folder with extra steps. The parts that make that less likely
are capture
(so updating it is a five-minute pass after a session,
not a separate chore) and lint
(so drift gets caught instead of
silently rotting).
I've tried system prompts, paste-in context files, separate
note-taking apps I'd open in another window. They all fail the same
way: they live outside the repo, so they don't survive a fresh
session, and they rely on you remembering to open them, paste them in,
and keep them updated. This is different because it's part of the
repository — every decision is version-controlled, every fact is
verified, and a guardrail is derived from a real commitment instead of
vibes. When the project changes, the knowledge base changes with it,
in the same commit history as the code.
If this is useful to you, a star helps other developers find it:
Then install the plugin and run /kms:quickstart
on one real decision
that's been living in your head. You'll never explain it twice.
Contributions welcome — see
for how to propose new skills or improve existing ones.