dbs-knowledge

• Build: Create a new folder knowledge base, or enable existing folders to have knowledge base navigation.
• Store: Place new materials in appropriate locations, retain sources, and handle duplicate names and version relationships.
• Use: Locate original files from the knowledge base, provide comprehensive answers and explain the basis.
• Check: Check for invalid paths, version conflicts, scattered files, duplicate materials, and maintenance gaps.

SOURCE_OF_TRUTH.md

• Read-only scan of the user-specified knowledge base directory.
• Identify directory responsibilities, candidate authoritative files, original materials, summary files, and historical versions.
• Generate or update the knowledge base navigation.
• Supplement a minimal call entry for the current Agent.
• Perform archiving, searching, or health checks according to the user's intent.

• Do not require users to install databases, vector databases, Embedding services, or RAG systems.
• Do not upload user files to third-party platforms.
• Do not rewrite the content of original materials.
• Do not speculate on file content and authority based on file titles.
• Do not batch move, rename, overwrite, or delete files without confirmation.
• Do not register every file into the knowledge base navigation.
• Do not read sensitive content such as keys, passwords, browser data, chat databases, etc.

1. Which paths will be modified;
2. What will be retained;
3. Whether the original files will be moved;
4. Whether existing Agent rules will be affected.

1. User explicitly provides a directory: Use that directory.
2. User says "this folder" and the current working directory boundary is clear: Use the current working directory.
3. Current directory is the user's home directory, disk root directory, download directory, or obviously too large: Ask the user to specify a more specific directory first.
4. User has no materials: Ask for the knowledge base name and save location, only ask the minimal questions that will change the actual path.

• SOURCE_OF_TRUTH.md

• AGENTS.md

• CLAUDE.md

• CODEBUDDY.md

• README.md

  in the root level and main directories
• Top-level directories that reflect business structure
• Files with signals such as date, version, final version, original, summary, archive in the file name

• .git/

• node_modules/

• .trash/

  , recycle bins, and explicit archive areas
• Caches, build artifacts, temporary directories, and dependency directories

• .env

  , key files, password files, credential databases
• Large binary content; only register file names, types, sizes, and locations unless the user's task requires reading
• Demonstrations, test fixtures, and historical backups in other projects

• What types of materials do users mainly save?
• Do existing directories clearly express business boundaries?
• Which files may be the currently valid versions? What is the basis?
• Which files belong to original records, and which belong to summaries or derived results?
• Does a knowledge base navigation already exist? Are the paths in it valid?
• Can the current host automatically read project rules?

{Knowledge Base Root Directory}/
├── 00-To-Be-Organized/
├── SOURCE_OF_TRUTH.md
├── AGENTS.md
└── CLAUDE.md

• 00-To-Be-Organized/

  is a low-threshold entry; users can put materials here temporarily when they don't know where to place them.
• According to the usage the user has explained, you can add 2~5 business directories with clear responsibilities.
• Do not pre-build a large number of empty directories when the user has not explained the material type.

• CLAUDE.md

  only serves as a thin entry for Claude Code; cross-host rules are maintained in

  AGENTS.md

  .

1. Roughly which fields the current materials are divided into;
2. Directory responsibilities that are already clear;
3. Candidate current versions and pending conflicts;
4. Entries recommended to be written into the knowledge base navigation;
5. Directories explicitly excluded.

SOURCE_OF_TRUTH.md

1. Confirm the status in one sentence, e.g., "Your knowledge base is ready to use."
2. Clearly tell users: There is no need to open or understand configuration files; continue to describe tasks in daily language.
3. Based on the materials actually scanned this time, generate 3~4 examples tailored to the current directory, covering at least three of "search", "store", "use", and "check".
4. Tell users they can directly copy a sentence or reply with the serial number to start.
5. Place the knowledge base navigation and Agent entry paths in "Technical Details"; keep it brief unless the user requests it.

1. {Clear current version rule}
2. When confirmation cannot be made, retain the conflict and ask the user.

• Update this navigation when adding key authoritative files, changing directory responsibilities, or discovering version conflicts.
• There is no need to update this navigation item by item for daily edits of ordinary files.

Only register information categories that are valuable for searching and judgment. For a large number of similar files, register the main directory, main index, or naming rules.

• Before searching for project materials, judging dynamic facts, confirming current versions, or creating new files, read

  SOURCE_OF_TRUTH.md

  first.
• Locate and read the original files required to complete the current task according to the knowledge base navigation.
• When multiple sources conflict, follow the version rules in the navigation; report the conflict if the rules are unclear.
• When answering knowledge base questions, explain the basis files, material timeliness, and missing information.

If equivalent rules already exist in the file, do not add duplicates.

• Existing

  CLAUDE.md

  : Retain the original text and confirm that it has imported or covered the above knowledge base rules.
• No

  CLAUDE.md

  : Create a thin entry

  @AGENTS.md

  .
• Do not copy the complete knowledge base navigation into

  CLAUDE.md

  .

• WorkBuddy can use

  AGENTS.md

  when

  CODEBUDDY.md

  is missing; by default, do not create additional duplicate files.
• When the project already has

  CODEBUDDY.md

  , retain the original text and import

  @AGENTS.md

  or add equivalent knowledge base rules.

1. Read the knowledge base navigation and the local

   README.md

   of the target directory.
2. Judge the material type, source, date, current status, and candidate attribution.
3. Check for duplicate-named files, similar versions, and existing current versions.
4. Provide the recommended target path and reasons.
5. When the file is outside the knowledge base, suggest copying it and retaining the original by default; move it only when the user explicitly requests it.
6. When the file is already in the knowledge base but in an inappropriate location, preview the moving plan and execute it after confirmation.
7. Do not overwrite when duplicate names occur; generate distinguishable names using dates, versions, or sources.
8. Update the knowledge base navigation only when new materials change the authoritative source, directory responsibilities, or version relationships.

00-To-Be-Organized/

1. Read

   SOURCE_OF_TRUTH.md

   .
2. Locate 1 or a small number of relevant directories and files according to the question.
3. Read the parts of the original files that are sufficient to answer the question.
4. Check the update time when discovering time-sensitive information.
5. When conflicts are found, report all sources and the handling rules in the navigation at the same time.
6. When evidence is insufficient, explain the gap; do not create local facts based on common sense.

{Direct answer to the user's question}

Basis Files:
- `{Path}`: {What judgment it supports}

Timeliness and Gaps: {When the materials were updated; what is missing; omit if none}

• Whether the paths in the knowledge base navigation exist;
• Whether the quick search table covers main material fields;
• Whether multiple "final version" or "latest version" appear without conflict rules;
• Whether directory responsibilities overlap;
• Whether there are long-unprocessed materials in

  00-To-Be-Organized/

  ;
• Whether a large number of unassigned files appear in the root directory;
• Whether the Agent entry can point to the knowledge base navigation;
• Whether historical versions, caches, or sensitive directories are mistakenly registered as current sources;
• Whether there are obvious duplicate files or dangling references.

• Immediate Handling: Agents may read incorrectly, paths are invalid, or current versions conflict.
• Recommended Handling: The structure starts to become messy but does not affect main usage temporarily.
• Keep As Is: Current rules are clear; no need to move files for the sake of neatness.

• /dbs-knowledge

  : Manages navigation, archiving, calling, version relationships, and health checks for general local materials.

• /dbs-content-system

  : Use when users want to process a large number of manuscripts, tweets, topics, cases, or course drafts into content units, topic maps, and topic assembly drafts.

• /dbs-agent-migration

  : Use when users want to organize the entire Agent workbench, rule source of truth, host naming, and cross-end migration.

• /dbs-bridge

  : Use when the knowledge base is already available and users only need to hang a certain Skill on multiple Agents.

• /dbs-decision

  : Use when users want to continuously record decisions, backfill results, and refine personal rules.

• Use intuitive terms such as "knowledge base", "knowledge base navigation", "currently valid version", "to be organized" externally.
• When generating

  SOURCE_OF_TRUTH.md

  for the first time, explain only once: This is the knowledge base navigation that guides AI.
• Only ask users to confirm one set of actions that will produce actual modifications at a time.
• Report specific paths, discovered quantities, and conflicts; do not stack technical terms.
• When users only want to search for materials, search directly; do not upgrade the query into a large-scale organization project.

• The knowledge base root directory is clear;
• Paths in

  SOURCE_OF_TRUTH.md

  have been checked for existence;
• Directory responsibilities and version rules are based on facts;
• The current Agent has an available call path;
• Users know how to add new materials and how to ask questions later.

• The location of new materials is clear;
• The handling method of the original file complies with user authorization;
• No duplicate files are overwritten;
• The navigation that needs to be updated has been updated.

• The answer reads the original file;
• Key judgments can be traced to paths;
• Timeliness, conflicts, and gaps have been explained.

• Risks are listed by priority;
• Modification suggestions are specific to paths;
• No moving, overwriting, or deletion is performed without confirmation.

You can continue to say "Put this material into the knowledge base", "Search the knowledge base for..." or "Check the knowledge base" here. If you need to handle business, content, or action issues outside the knowledge base next, enter

/dbs

, and I will continue to judge based on the current results.