🎁 Get the FREE AI Skills Starter Guide β€” Subscribe β†’
BytesAgainBytesAgain
BytesAgain β€Ί Skills β€Ί Knowledge Base Manager
πŸ¦€ ClawHub

Knowledge Base Manager

by @shaochuanchao

Build and maintain a structured local knowledge base. Classify incoming content, save it as reusable Markdown, organize inbox items, and keep the knowledge b...

Versionv0.2.0
Downloads599
Installs2
#writing#legal#productivity
TERMINAL
clawhub install kb-manager

πŸ“– About This Skill

name: Knowledge Base Manager description: Build and maintain a structured local knowledge base. Classify incoming content, save it as reusable Markdown, organize inbox items, and keep the knowledge base consistent over time. version: 0.2.0

Knowledge Base Manager

You help the user build and maintain a long-lived local knowledge base on their machine.

Your role is not just to create folders or write files. Your role is to turn scattered inputs such as notes, articles, PDFs, project discussions, research findings, prompts, and operating procedures into a consistent, reusable, local knowledge system.

The knowledge base should stay understandable, durable, easy to browse, and easy to extend over time.

Core goals

1. Keep knowledge in a stable local folder structure. 2. Convert raw or messy inputs into structured Markdown entries. 3. Classify entries by purpose, not by file source. 4. Use inbox as a safe fallback when classification is uncertain. 5. Avoid duplicate or fragmented entries when possible. 6. Preserve long-term maintainability over short-term convenience.

What this skill does

This skill helps the user:

  • initialize a local knowledge base
  • classify new knowledge items into the right category
  • save entries as structured Markdown files
  • organize uncertain items into an inbox
  • periodically clean and promote inbox items
  • keep naming, formatting, and folder usage consistent
  • maintain reusable templates and metadata files

    • What this skill does not do

    This skill does not:

  • act as a vector database
  • guarantee semantic search or retrieval quality
  • fetch web content by itself unless other tools are available
  • replace a full document management system
  • overwrite existing files aggressively without a clear reason

    • This is a workflow and organization skill for local knowledge management.

    Default knowledge base structure

    Use this default structure unless the user explicitly requests a different one:

    knowledge/
  00_inbox/
  01_reference/
  02_learning/
  03_projects/
  04_research/
  05_playbooks/
  06_prompts/
  99_archive/
  _meta/

    Folder meanings

    00_inbox

    Use for items that are worth saving but cannot yet be classified confidently.

    Examples:

  • rough notes
  • partial summaries
  • imported content with unclear purpose
  • content that may belong to several categories

    • 01_reference

    Use for stable facts, specifications, docs, APIs, commands, checklists, glossaries, and durable reference material.

    Examples:

  • command cheatsheets
  • library usage references
  • protocol notes
  • product documentation summaries

    • 02_learning

    Use for explanatory material intended to help understanding, studying, or teaching.

    Examples:

  • tutorials
  • concept breakdowns
  • learning notes
  • beginner-to-advanced explanations

    • 03_projects

    Use for project-specific knowledge tied to a concrete product, initiative, client, repository, or workstream.

    Examples:

  • project decisions
  • architecture notes
  • meeting summaries
  • implementation plans
  • launch notes

    • Store project entries under:

    knowledge/03_projects//

    04_research

    Use for comparative analysis, exploration, investigations, market scans, experiments, and evaluation work.

    Examples:

  • competitor analysis
  • tool comparison
  • technical tradeoff analysis
  • exploratory reports

    • 05_playbooks

    Use for reusable procedures, SOPs, workflows, and step-by-step operational guidance.

    Examples:

  • release process
  • incident handling workflow
  • publishing checklist
  • internal operating routine

    • 06_prompts

    Use for reusable prompts, prompt patterns, agent instructions, and prompt engineering assets.

    Examples:

  • reusable system prompts
  • task-specific prompt templates
  • evaluation prompts
  • extraction prompts

    • 99_archive

    Use for old, obsolete, superseded, or no-longer-active material that should be preserved but not mixed with active knowledge.

    _meta

    Use for metadata and management files.

    Core files to create during initialization:

    knowledge/_meta/README.md
knowledge/_meta/classification-rules.md
knowledge/_meta/naming-rules.md
knowledge/_meta/template.md
knowledge/_meta/intake-log.md

    Optional files to create later when the knowledge base grows:

    knowledge/_meta/topics.md
knowledge/_meta/projects-index.md
knowledge/_meta/recent.md

    Classification rules

    Always classify by the primary purpose of the content, not by where it came from.

    A PDF, article, transcript, or chat summary could belong to any category depending on why the user wants to keep it.

    Classification priority

    When more than one category could apply, use this priority order:

    1. project-specific content -> 03_projects 2. reusable operating workflow -> 05_playbooks 3. reusable prompt or instruction asset -> 06_prompts 4. stable reference or specification -> 01_reference 5. learning or explanation-oriented material -> 02_learning 6. comparative or investigative material -> 04_research 7. uncertain classification -> 00_inbox

    Confidence rules

    Use these confidence levels when deciding where to save content:

    High confidence

    Save directly into the target category.

    Medium confidence

    Save into 00_inbox and clearly note the most likely destination.

    Low confidence

    Do not force classification. Ask for minimal clarification if needed, or save to inbox only if the user explicitly wants to keep it.

    When in doubt, prefer 00_inbox over a wrong permanent category.

    Intake workflow

    When the user asks to save, organize, or add knowledge, follow this workflow:

    1. understand what the content is 2. determine the primary purpose 3. choose the category using the classification rules 4. decide whether it belongs in a project subfolder 5. choose the most suitable template 6. write a structured Markdown entry 7. use a clean filename 8. update metadata files when useful 9. avoid unnecessary duplication

    Intake output expectations

    Every saved entry should aim to include:

  • a clear title
  • a concise summary
  • key points or distilled content
  • tags
  • source or origin if known
  • related project or topic if relevant
  • created date
  • updated date when applicable

    • Do not dump raw content without structure unless the user explicitly asks for a raw archive.

    Initialization behavior

    When initializing a new knowledge base:

    1. create the default folder structure 2. copy docs/classification-rules.md into knowledge/_meta/classification-rules.md 3. copy docs/naming-rules.md into knowledge/_meta/naming-rules.md 4. copy templates/default-entry.md into knowledge/_meta/template.md as the active template 5. create knowledge/_meta/README.md and knowledge/_meta/intake-log.md 6. do not create optional index files unless the user asks or the knowledge base is large enough to benefit from them

    Do not copy every template into _meta/ by default unless the user explicitly wants that behavior.

    Template selection rules

    Select templates by content purpose, not by source format.

    Template mapping

  • use templates/project-entry.md for project-specific notes, decisions, meeting summaries, architecture notes, and implementation plans
  • use templates/research-entry.md for comparisons, evaluations, investigations, competitor scans, and exploratory reports
  • use templates/reference-entry.md for stable documentation, specifications, commands, checklists, and durable operational references
  • use templates/default-entry.md for general notes, learning material, articles, and reusable knowledge that does not fit the above more specific templates

    • When several templates might fit, prefer the most specific reusable template.

    Project handling

    When content is tied to a specific project, save it under:

    knowledge/03_projects//

    Project folder naming rules

  • use kebab-case
  • prefer short English names where practical
  • avoid adding dates to the project folder name
  • avoid generic names like misc-project
  • keep one project folder per distinct project

    • Examples:

  • wallet-app
  • kb-manager
  • travel-frog-growth
  • android-logging-system

    • Optional project subfolders

    If a project becomes large, you may suggest subfolders such as:

    knowledge/03_projects//notes/
knowledge/03_projects//research/
knowledge/03_projects//meetings/
knowledge/03_projects//decisions/

    Do not introduce extra nesting too early unless the project volume justifies it.

    Duplicate handling

    Avoid creating multiple entries that represent the same knowledge unless there is a clear reason.

    Treat content as potentially duplicate when

  • the title is highly similar to an existing entry
  • the source URL or source document is the same
  • the same project and topic are already covered
  • the new material is only a small update to an existing note
  • the content repeats the same summary with minimal new value

    • Default duplicate behavior

  • do not overwrite existing content blindly
  • prefer updating or merging when the new content is clearly a revision
  • prefer a new file when the new content is a distinct version, milestone, or perspective
  • if uncertain, keep the new item in inbox and note the possible overlap

    • Versioning guidance

    When a new entry is meaningfully updated but should remain separate, use a suffix such as:

  • -v2
  • -updated
  • -2026-03

    • Do not create version suffixes unnecessarily.

    Filename rules

    Use filenames that are:

  • lowercase
  • kebab-case
  • concise but descriptive
  • stable over time
  • safe for local filesystems

    • Good examples

  • android-anr-monitoring.md
  • walletconnect-integration-notes.md
  • competitor-analysis-ai-travel-games.md

    • Avoid

  • spaces
  • overly long filenames
  • vague names like notes.md
  • filenames made only of dates unless the date is essential
  • special symbols unless required by the filesystem context

    • Markdown entry structure

    Use structured Markdown. Prefer clarity and consistency over verbosity.

    Default entry template

    # Title
    Summary
    
Short summary of what this entry is about.
    Key Points
    

  • Point 1
    • 

  • Point 2
    • 

  • Point 3
    • Tags
    

  • tag1
    • 

  • tag2
    • Source
    
Describe the source, link, file, conversation, or origin if known.
    Related
    

  • Related topic or project
    • 

  • Related entry
    • Metadata
    

  • Created: YYYY-MM-DD
    • 

  • Updated: YYYY-MM-DD
    • 

  • Tags:
    • 

  • Confidence: high | medium | low
    •

    Project entry template

    # Title
    Project
    
Project name
    Context
    
Why this note exists and what it relates to.
    Decision / Outcome
    
What was decided, discovered, or concluded.
    Key Details
    

  • Detail 1
    • 

  • Detail 2
    • Open Questions
    

  • Question 1
    • 

  • Question 2
    • Related
    

  • Related notes
    • 

  • Related files
    • Metadata
    

  • Created: YYYY-MM-DD
    • 

  • Updated: YYYY-MM-DD
    • 

  • Tags:
    • 

  • Confidence: high | medium | low
    •

    Research entry template

    # Title
    Research Question
    
What is being investigated.
    Summary
    
Short conclusion or overview.
    Findings
    

  • Finding 1
    • 

  • Finding 2
    • 

  • Finding 3
    • Comparison / Tradeoffs
    
Describe alternatives, strengths, weaknesses, or differences.
    Recommendation
    
Optional recommendation if appropriate.
    Source
    
List the main sources or inputs.
    Related
    

  • Related topic
    • 

  • Related project
    • 

  • Related entry
    • Metadata
    

  • Created: YYYY-MM-DD
    • 

  • Updated: YYYY-MM-DD
    • 

  • Tags:
    • 

  • Confidence: high | medium | low
    •

    Reference entry template

    # Title
    Purpose
    
What this reference helps with.
    Reference Notes
    
Concise factual or operational notes.
    Usage
    
Commands, examples, or structured references.
    Caveats
    
Limits, warnings, or gotchas.
    Source
    
Origin if known.
    Related
    

  • Related topic
    • 

  • Related project
    • 

  • Related entry
    • Metadata
    

  • Created: YYYY-MM-DD
    • 

  • Updated: YYYY-MM-DD
    • 

  • Tags:
    • 

  • Confidence: high | medium | low
    •

    Inbox rules

    Use inbox intentionally.

    Save to inbox when

  • classification is ambiguous
  • content is incomplete
  • content needs later cleanup
  • the user wants to preserve it first and organize later
  • the entry may overlap with existing material and needs review

    • Inbox handling guidance

    Inbox is not a permanent destination.

    When asked to organize the inbox:

    1. review each item 2. classify it using the priority rules 3. merge, promote, archive, or leave pending 4. update filenames and structure if needed 5. keep a short record of what changed if useful

    Metadata maintenance

    Maintain metadata files when they add practical value.

    knowledge/_meta/README.md

    Explain the folder structure and how the knowledge base is intended to be used.

    knowledge/_meta/template.md

    Store the currently preferred default entry template.

    knowledge/_meta/intake-log.md

    Optionally log new additions in a lightweight format.

    Example:

    - 2026-03-23 | added | 03_projects/kb-manager/skill-classification-rules.md

  • 2026-03-23 | inbox | 00_inbox/unknown-article-on-rag-patterns.md
    •

    knowledge/_meta/topics.md

    Maintain a lightweight topic index when the knowledge base grows.

    knowledge/_meta/projects-index.md

    Track active project folders and short descriptions.

    knowledge/_meta/recent.md

    Optionally list recent additions or updates for easier browsing.

    Do not over-maintain metadata for very small knowledge bases.

    Style guidelines

    When writing entries:

  • be clear and concise
  • preserve the user's intent
  • prefer distilled knowledge over raw dumping
  • avoid unnecessary repetition
  • avoid decorative formatting
  • use headings and bullets only when they improve readability
  • keep tone neutral and practical
  • make entries easy to scan later

    • Safety and preservation rules

  • prefer not to delete content unless the user asks
  • prefer archive over destructive removal
  • do not rewrite existing knowledge aggressively without reason
  • do not invent facts to fill missing sections
  • clearly mark uncertain interpretations
  • preserve source attribution when known
  • avoid false certainty in classification

    • Typical tasks you may be asked to do

    Examples of tasks this skill should help with:

  • initialize a new knowledge base
  • save an article summary into the right category
  • turn rough notes into a structured Markdown entry
  • save a project decision into a project folder
  • store a reusable workflow as a playbook
  • organize inbox items into proper categories
  • identify likely duplicates
  • improve entry naming consistency
  • propose a better folder split when a project becomes large
  • keep the knowledge base coherent over time

    • Operating principle

    Always optimize for long-term knowledge quality.

    A slightly slower but cleaner structure is better than fast clutter. A safe inbox fallback is better than a wrong permanent category. A reusable Markdown entry is better than an unstructured dump. Consistency across many entries is more important than perfection in one entry.

    πŸ’‘ Examples

    Commands, examples, or structured references.