Knowledge Base
What this does
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.
What you'll need
You do not need to connect anything to get value today. Paste what you know and the skill structures it. Connect the tools below and it maintains the base as a living, greppable store.
- Works today with: whatever you can dump, notes, a thread, a list of who-does-what. It sorts it into the four types and structures each entry.
- More powerful connected to a repo: the base lives as markdown files you can grep, diff, and review.
- Sharper with a notes or wiki tool: entries land where your team already looks.
- Sharper with a decision log or context pack: they cross-link, so a fact points to the decision that set it.
How this runs at your connection level
This skill is never reliant on a connector. It structures what you give it and gets more durable as you connect somewhere to keep it. It never writes or overwrites an entry without approval.
- Bring your data: paste the raw material. The skill sorts, structures, and cross-links it today. No connection required.
- Connect your tools: it writes the entries as files, keeps the index current, and flags duplicates, once you approve each change.
- Just exploring: nothing to capture yet? Get the four entry templates and a worked example, so the structure is ready when you are.
Every run ends with the one entry most worth adding next, usually the fact you just looked up again.
Customize this for yourself
This was built for an operator tired of re-finding the same answer. Set these to your world:
| 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 | facts, playbooks, stakeholders, how-tos |
| NAMING | how files are named | type-slug.md, lower-kebab-case |
| INDEX | the front door | a README that lists and links everything |
| REVIEW_CADENCE | when entries get re-checked | quarterly, or on change |
| OWNER_FIELD | who is accountable for an entry | you, by default |
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.
The method
Sort 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.
Greppable 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.
The 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.
Cross-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.
Freshness, 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.
Quality gates
- 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.
Output (example)
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 the inputs come from
ENTRY_TYPES and REVIEW_CADENCE are defaults, not laws. Some operators add a "glossary" type or a "vendors" type; some review monthly, some on change only. The four types are the starting set because they are what an operator forgets most. Reshape the categories. Keep it plain and greppable.
Make it yours
Fork it. Add types, change the naming, wire the freshness check to a reminder. Cut what your work never needs. The point is that the second time you look something up, you find it instead of re-deriving it. Built by an operator. Customize it, break it, make it better.