My AI Keeps Forgetting What We Already Decided

A developer built a git-based knowledge system called kms to solve AI coding agents' lack of persistent memory across sessions. The plugin, available for Claude Code and other agents, stores decisions, facts, guardrails, and skills as markdown files in the repo, allowing agents to recall past context. The developer shared a walkthrough of the tool, including its schema and commands, noting its limitations.

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 CONTRIBUTING.md https://github.com/vivantel/kms/blob/main/CONTRIBUTING.md for how to propose new skills or improve existing ones.