Build the knowledge base future-you can actually search.
A plain-text, searchable base of facts, playbooks, stakeholders, and how-tos, organized so the answer is one search away.
Inside: Sort-by-type capture, a README front door, and per-entry freshness.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
the base lives as markdown files you can grep, diff, and review.
entries land where your team already looks.
they cross-link, so a fact points to the decision that set it.
This was built for an operator tired of re-finding the same answer. Set these to your world:
The four types cover most of what an operator forgets. Add or rename to fit. The rule that it stays plain and searchable does not change.
| Set this | What it is | Default / Example |
|---|---|---|
| KB_HOME | where the base lives | a git repo/kb; a notes/wiki tool |
| ENTRY_TYPES | the categories you keep | factsplaybooksstakeholdershow-tos |
| NAMING | how files are named | type-slug.mdlower-kebab-case |
| INDEX | the front door | a README that lists and links everything |
| REVIEW_CADENCE | when entries get re-checked | quarterlyor on change |
| OWNER_FIELD | who is accountable for an entry | youby default |
Everything the skill does, in full.
Turns the facts you keep re-deriving into a knowledge base you and your tools can search. It captures four things: facts (the stable truths), playbooks (how a repeated thing gets done), stakeholders (who owns what), and how-tos (the specific steps). It writes them as plain markdown, organized and cross-referenced, so the next time you or an AI needs the answer, it is one search away. A thing you have looked up twice belongs here.
- 1Sort by type
Every capture is one of four things. A fact is a stable truth ("the trial is 14 days"). A playbook is how a repeated process runs. A stakeholder entry is who owns what and how to reach them. A how-to is the steps for a specific task. Mixing them is why old wikis rot; keeping them separate is why this one stays usable.
- 2Greppable structure
Plain markdown. Consistent headings. A predictable filename. So a search for a term lands on the entry, not near it. No entry hides inside a screenshot or a table nobody can grep.
- 3The index is the front door
One README lists every entry, grouped by type, each a link. If it is not in the index, it does not exist. The index is maintained on every add, not once a year.
- 4Cross-links over duplication
A fact that a playbook depends on is linked, not copied. One source of truth per fact. When it changes, it changes in one place. The skill flags a would-be duplicate instead of writing it.
- 5Freshness, not just capture
Every entry carries a last-checked date and an owner. Stale knowledge is worse than none, because it is trusted. The base surfaces what is overdue for a look.
- Nothing is written or overwritten without your explicit approval, per entry. The skill drafts; you place it.
- No duplicate facts. A would-be duplicate is flagged and linked to the existing source, not written again.
- Every entry has a type, an owner, and a last-checked date. An undated fact is a trap.
- The index is updated whenever an entry is added. An orphan entry nobody can find is not knowledge.
KNOWLEDGE BASE · proposed additions · 3 entries FACT · trial-length.md The standard trial is 14 days. Owner: you. Last checked: today. Linked from: onboarding-playbook.md PLAYBOOK · new-signup-routing.md How a signup gets routed to an owner (5 steps). Owner: you. Depends on fact: company-size-bands.md (linked, not copied) STAKEHOLDER · eu-signups-owner.md UNRESOLVED. No named owner for EU signups yet. Flagged, not invented. INDEX UPDATE + 3 entries added to README under Facts / Playbooks / Stakeholders (all drafts. approve to write; the EU owner stays blank until you name one)
Where an operator takes this next.
The capture is step one. Here is where an operator takes it once the manual version proves out.
You built the base once, now it stays the place people actually check first.
Wire a scheduled Claude task to scan your Slack search history weekly for repeated questions, and draft a KB entry for anything asked twice.
Run a monthly freshness check against the last-checked date on every entry, and post the overdue list to Slack for the named owner.
Sync the base into Notion or a wiki tool so any AI agent your team runs (a support bot, a sales assistant) reads from the same source of truth instead of guessing.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.