| name | knowledge-base-ingester |
| description | Converts raw notes, brain dumps, documents, and unstructured text into structured
knowledge base entries suitable for Notion, Confluence, a wiki, or a personal PKM
system. Use this skill whenever a user says "turn these notes into a KB article",
"add this to our knowledge base", "structure these raw notes", "write a wiki page
from this", "convert this into a how-to guide", "make this searchable", or
"ingest this into our docs". Also activate when someone pastes a long unstructured
document and wants it organized. Do NOT use for meeting notes (use
meeting-notes-to-actions) or code documentation generation.
|
Knowledge Base Ingester
Transform raw, unstructured content into clean, searchable, consistently formatted
knowledge base entries that teams can actually find and use.
When to Use
- Converting a Subject Matter Expert's brain dump into a reference article
- Turning Slack thread discussions into permanent KB entries
- Structuring onboarding notes, runbooks, or how-to guides from raw text
- Migrating content from disparate sources into a unified KB
When NOT to Use
- Meeting notes extraction (use
meeting-notes-to-actions)
- Code documentation (use
documentation-generator)
- Full documentation refactoring (use
docs-refactorer)
Workflow
Step 1 — Receive and Clarify
Accept the raw content (any format: prose, bullets, transcript, email thread).
Ask:
- Target system: Notion, Confluence, GitHub wiki, static site, or generic Markdown?
- Content type: How-to guide / Reference / FAQ / Runbook / Glossary entry?
- Audience: Internal team, new hires, customers, or public?
- Tags / categories: If the KB has a taxonomy, what category does this belong to?
Step 2 — Extract Core Knowledge
Read the input and identify:
| Element | What to capture |
|---|
| Key concept or procedure | The main thing this entry teaches |
| Prerequisites | What the reader needs to know first |
| Steps or facts | The core content in logical order |
| Examples | Concrete instances that illustrate the concept |
| Edge cases / gotchas | Things that commonly trip people up |
| Related topics | Links to other KB entries to add |
Step 3 — Structure the Entry
Use this default template:
# [Descriptive Title]
> **Summary:** One-sentence description of what this article covers.
**Last updated:** [Date] | **Author:** [Name] | **Category:** [Tag]
---
## Overview
[2–3 sentence context: what this is, when you'd need it, why it matters]
## Prerequisites
- [Prerequisite 1]
- [Prerequisite 2]
## [Main Content Section — How-To / Reference / Explanation]
### Step 1 — [Action]
[Explanation]
`code or example`
### Step 2 — [Action]
[Explanation]
## Common Issues & Gotchas
- **[Issue]:** [How to handle it]
## Related Articles
- [Link placeholder 1]
- [Link placeholder 2]
Adapt the template to the content type:
- FAQ: Q&A format with bold questions
- Runbook: numbered steps with verification checkpoints
- Glossary: term, definition, example usage, related terms
Step 4 — Tag and Categorize
Suggest 3–5 tags based on content. Common categories:
engineering, product, onboarding, security, operations, data, api
Step 5 — Review
Present the draft and ask:
- "Does this capture everything important from the original?"
- "Should I adjust the complexity level for your audience?"
- "Are there related KB articles I should reference?"
Output Format
Default: Markdown suitable for any KB system.
For Notion: structure using heading blocks with callout boxes for warnings/tips.
For Confluence: use Confluence wiki markup hints where different from standard Markdown.
Safety & Confirmation
- Never include credentials, API keys, passwords, or PII in the KB entry. Replace with
<PLACEHOLDER>.
- Flag any content that appears sensitive and ask before publishing.
- Mark content that may be outdated with
> ⚠️ This section may be outdated — verify before relying on it.
