My teammate joined the project on a Tuesday. By Wednesday she asked
the question every new hire eventually asks: "Why is auth handled in
three different places?"
I didn't have a good answer — just a fuzzy memory of a decision made
months earlier, in a call nobody wrote down. That's the same problem
I wrote about last time — an AI agent with no memory of what we'd
already decided. Turns out it's not just an AI problem; a team
forgets too. Most real projects aren't a clean slate. Here's what
fixing that actually looks like on one that already has history.
Retrofitting memory onto an existing project
bootstrap has two modes. Fresh-project mode creates
docs/{facts,decisions,guardrails,skills}/ from nothing. Gap-fill mode
is for a project that already has some of that, inconsistent and
incomplete:
/kms:bootstrap
That's Claude Code. 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.
It found our existing docs/decisions/ folder and extended it instead
of replacing it. Then it scanned git history and existing docs for
decision language — a DECISION: marker, a "because we need to" — and
came back with draft stubs (id, title, a first-pass motivation,
status: draft) for decisions I'd genuinely forgotten were decisions
at all — not the full rationale, that's still ours to write, but a
real starting point instead of a blank page. The auth-in-three-places
thing was one of them.
It also flagged two guardrail files missing the field recording which
decision they came from — not silently, and not by guessing: each got
logged as undeclared debt with a proposed likely source, turning an
archaeology project into a five-minute confirmation.
A role-tailored ramp-up, not a wiki page
Once the knowledge base had real content, I pointed my teammate at:
/kms:onboard
First question back: which role was she ramping up as. Not guessed —
a backend-leaning plan and a frontend one pull from almost entirely
different decisions and guardrails. What came back was 5 days, each
with a goal, specific artifacts to read (real paths, not "the
decisions folder"), and a skill to run:
| Day | Focus |
|---|---|
| 1 | Highest-level facts, most consequential decisions |
| 2 | Role-specific decisions and guardrails — what not to violate, and why |
| 3 | Role-specific facts, current state |
| 4 | First real task; query for anything unclear |
| 5 | Practice a decision with clarify; capture afterward |
It also told her the truth: our facts directory was still thin, so the
plan opened with a plain warning that it was built on an incomplete
base. A wiki page doesn't flag its own staleness. This did.
Planning the refactor I'd been avoiding
The auth question turned into a real refactor — the kind I'd normally
put off because nobody could tell me what it'd break:
/kms:refactor-plan
Phase 1 searched the knowledge base and found two relevant artifacts:
the (now-recorded) decision that split auth in the first place, and a
session-handling guardrail I'd forgotten existed. Phase 2 mapped call
sites and config by reading the code directly — no dependency on any
other skill running first. Phase 3 came back with ordered phases, each
carrying concrete steps, a verification checkpoint, and a rollback
strategy specific to that phase, not "revert everything."
One planned step would've quietly violated the session-handling
guardrail. It wasn't dropped and it wasn't silently worked around — it
was flagged, cited by path, with an explicit ask to confirm before it
stayed in the plan.
What this doesn't do
onboard won't write the facts and decisions that don't exist yet —
that's bootstrap's job, run first. refactor-plan won't tell you a
refactor is worth doing, only what it'll cost and what could break;
if the knowledge base has nothing relevant to what you're touching, it
says so plainly instead of inventing a concern to sound thorough.
Neither replaces the actual conversation with your teammate.
And if kms isn't for you later, uninstall finds everything it added
— seeded guardrails, generated files like the doc manifest, the marker
block in your agent instructions — and asks about each one
individually: detach
(keep the content, stop tracking it as kms's) or remove. Same
confirm-first discipline as every other kms skill, including this one.
Nothing about adopting kms locks you in, and this piece exists partly
to prove that's not just a claim in the README.
Try it
If this is useful, a star helps other developers find it:
/plugin marketplace add vivantel/kms
/plugin install kms
If your project already has some history — an incomplete
decisions/ folder, a wiki nobody trusts — run /kms:bootstrap on it
before assuming you have to start clean. That's the case it's built
for.
Contributions welcome — see
CONTRIBUTING.md
for how to propose new skills or improve existing ones.
Top comments (0)