Skill: shaochuanchao/kb-manager (version 0.2.0)

--- 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: ```text 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: ```text knowledge/03_projects/<project-name>/ ``` ### `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: ```text 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: ```text 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: ```text knowledge/03_projects/<project-name>/ ``` ## 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: ```text knowledge/03_projects/<project-name>/notes/ knowledge/03_projects/<project-name>/research/ knowledge/03_projects/<project-name>/meetings/ knowledge/03_projects/<project-name>/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 ```md # 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 ```md # 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 ```md # 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 ```md # 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: ```md - 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.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)