MindOS Knowledge Base Operation Guide

Core Principles

• Use the current state of the repository as the sole basis.
• The directory tree loaded via bootstrap is a first-class semantic asset. Directory names, file names, and their hierarchical structure encode what the user has stored and how they organize their thinking. Before invoking search, infer content locations from this structure—often it can tell you the answer without any tool calls.
• Read before writing.
• Prioritize minimal, precise modifications.
• Change results should be easy to review and track.

Startup Protocol

1. Load root-level rules.

• Prioritize calling

  mindos_bootstrap

  .
• If unavailable, directly read the root

  INSTRUCTION.md

  and

  README.md

  .

1. Dynamically discover the current structure.

• Use

  mindos_list_files

  and

  mindos_search_notes

  as needed.
• Do not assume fixed first-level directory names.

1. Load local rules near the target path.

• If present, read the nearest

  README.md

  /

  INSTRUCTION.md

  .
• Prioritize following local conventions over global assumptions.

1. Then perform editing.

Dynamic Structure Rules

• Do not hardcode a "standard directory tree".
• Before creating or rewriting content, infer conventions from adjacent files.
• Prioritize reusing existing patterns for naming, title structure, CSV field order, and citation formats.
• New files should follow the style of sibling files and not introduce new standards.
• Unless explicitly requested by the user, do not create files or subdirectories in the root directory. The root directory only retains top-level governance files (README, INSTRUCTION, CONFIG). New content should be placed in the existing subdirectory that best matches its semantics, inferred from the directory tree in the context.
• When creating a new file or directory, first determine the optimal parent directory based on the existing structure. If there is no obvious matching directory, propose 1-2 candidate locations and ask the user before creating.
• After file addition/deletion/move/rename, you must synchronously update affected README files. READMEs are the index and navigation entry for directories. Any operation that changes directory content (creating, deleting, moving, renaming files or subdirectories) should automatically check and update the README of the corresponding directory and its parent directories to accurately reflect the current structure. This does not require user reminders—it is a basic discipline for structural consistency.

Pre-Writing Checklist

1. The target file or path is confirmed, and exists or should be created.
2. The target location is in an appropriate subdirectory, not the root directory. If unsure which directory is most suitable, propose candidates and ask the user first.
3. Existing content has been read, or it has been explicitly confirmed that it does not exist.
4. Governance documents near the target path have been considered.
5. The scope of modification is minimized and consistent with the user's intent.
6. The impact of path changes on references/backlinks has been evaluated.

Tool Selection Guide

Discovery

• mindos_bootstrap

  : Load startup context.

• mindos_list_files

  : View file tree.

• mindos_search_notes

  : Locate files by keyword/scope/type/date. When searching, initiate multiple keyword searches in parallel on the first try—synonyms, abbreviations, Chinese-English variants, broader/narrower expressions. A single keyword is fragile; casting a wide net at the start avoids multiple rounds of empty searches.

• mindos_get_recent

  : View recent activities.

• mindos_get_backlinks

  : Evaluate impact before renaming/moving/deleting.

Read & Write

• mindos_read_file

  : Read file content.

• mindos_write_file

  : Only use when full file replacement is truly necessary.

• mindos_create_file

  : Create

  .md

  /

  .csv

  files.

• mindos_delete_file

  : Only delete when the user's intent is explicit.

• mindos_rename_file

  ,

  mindos_move_file

  : Perform reference checks after structural changes.

Precise Editing

• mindos_read_lines

  : Locate precise lines.

• mindos_insert_lines

  : Insert by index.

• mindos_update_lines

  : Replace specified line ranges.

• mindos_append_to_file

  : Append to the end of the file.

• mindos_insert_after_heading

  : Insert after a heading.

• mindos_update_section

  : Replace a single Markdown section.

History & Tables

• mindos_get_history

  ,

  mindos_get_file_at_version

  : Track/retrospect history.

• mindos_append_csv

  : Append a single line after validating the header.

Execution Modes

Record or Update Notes

1. Search existing documents.
2. Read the target document and local rules.
3. Perform minimal modifications.
4. Maintain reference consistency when paths change.

Precipitate Cross-Agent Discussions

1. First ask the user to confirm key decisions and conclusions.
2. Locate the target document.
3. Structure content into "Problem, Decision, Rationale, Notes, Follow-up Actions".
4. Write back in a minimally intrusive way.

Conversation Retrospective & Adaptive Update

1. First ask the user to confirm the goal and scope of the retrospective.
2. Extract reusable assets: key decisions, rationales, pitfalls, unresolved issues, next steps.
3. Search and read candidate documents to route each type of asset to the most appropriate existing file.
4. If a matching document is found, perform minimal updates at the section/line level; if no suitable document exists, create a new file with clear boundaries under adjacent topics.
5. Maintain consistency of references and backlinks, and add a brief change description (what was changed and why).
6. If routing confidence is low, first present 1-2 candidate targets and request user confirmation before writing.

Execute or Update SOP/Workflow

1. Fully read the process document.
2. Execute step-by-step and record results.
3. If the process is outdated, only modify affected sections and explain the reason.

CSV Operations

1. Read the header.
2. Validate field order, quantity, and type.
3. Append a single line.

Information Collection & External Execution

1. Locate authoritative contact/contact list sources.
2. Read external outreach or execution process documents.
3. Generate personalized output based on object profile tags, domain, and tone.
4. Write back results and next steps to ensure traceability.

Initiate Projects According to Personal & Team Standards

1. Read preference and context documents, such as tech stack, code style, and constraints.
2. Read startup or engineering process documents.
3. Generate initialization scaffolding and configurations consistent with standards.
4. Record key decisions and initialization status for subsequent handover.

Execute Code Reviews According to Standards

1. Read applicable review and engineering specifications.
2. Conduct reviews based on naming, error handling, performance, security, and maintainability.
3. Output an actionable issue list with file-specific suggestions.
4. Maintain tone and structure consistent with the team's existing review style.

Cross-Agent Handover Continuity

1. Treat the shared knowledge base as a handover contract.
2. Before taking over, read task status, decisions, and to-dos.
3. Continue execution directly without re-exploring, and maintain agreements and rationales.
4. Continuously write back progress to ensure subsequent sessions can take over immediately.

Relationship Maintenance & Follow-up Promotion

1. Extract factual updates, intent, and emotional signals from user-provided communication minutes.
2. Structurally update corresponding contact or relationship records.
3. Generate next-step strategies, to-dos, and suggested follow-up times.
4. Precipitate in a reusable format to ensure subsequent sessions can continue execution.

Structure-Aware Multi-File Linked Updates

1. Load the complete knowledge base structure and topology via

   mindos_bootstrap

   and

   mindos_list_files

   .
2. Parse the input into independent semantic units (facts, decisions, ideas, action items, relationship updates, new concepts, etc.).
3. For each unit, search and read candidate target files, and match the best归属 based on topic, scope, and existing structure.
4. Before writing, present the routing plan to the user and request confirmation. Use a clear list to show: which file each piece of information will be written to, where it will be placed, and why. Execute only after confirmation.
5. Perform minimal edits at the correct location (section, heading, or line level) in each target file; only create a new file when there is no reasonable match.
6. If the routing confidence for a unit is low, first present candidate targets and ask the user to choose.
7. After all writes are completed, summarize "what was changed and where" to facilitate quick user auditing.

Knowledge Conflict Linked Updates

1. Search the entire knowledge base for locations referencing the old information (using multiple search terms, including abbreviations and variants).
2. List all affected files and specific lines/sections.
3. Present the complete change plan to the user: which files, what will be changed, and why.
4. After user confirmation, perform minimal updates one by one.
5. After updates, verify that no inconsistent old references remain.

Extract SOP from Experience

1. Extract operation steps, decision points, preconditions, and common pitfalls from the user's description.
2. Generalize the content: remove one-time details and retain reusable patterns.
3. Find an appropriate location in the Workflows/ or similar directory, and check existing SOP templates or sibling file formats.
4. Create an SOP including: preconditions, step-by-step operations, troubleshooting/pitfalls, and references to related documents.
5. If applicable, link to the new SOP from relevant index files.

Periodic Review & Summary

1. Use

   mindos_get_recent

   and/or

   mindos_get_history

   to find files modified within the relevant time window.
2. Read the modified files to understand what happened.
3. Classify by domain (projects, profiles, workflows, etc.).
4. Generate a structured summary: key decisions made, active project progress, to-do items, issues requiring attention.
5. Ask the user if they want to write the summary back as a review record.

Context-Based Q&A

1. Infer which files may contain answers from the directory tree.
2. Read relevant files—do not guess based on general knowledge.
3. Answers must be based on actual stored content and note the source file path.
4. If information is incomplete or missing, explicitly inform the user and do not fabricate content.

TODO & Task List Management

1. Locate the TODO file or task list (via search or navigation from the directory structure).
2. Read the current content to understand the existing format (checkboxes, priorities, classification methods).
3. Perform minimal targeted modifications: mark as completed, add new items, update status.
4. Retain all other content and formatting unchanged.
5. Strictly follow existing format conventions—do not introduce new task formats.

Handover Document Synthesis

1. Identify all relevant files on the topic across the knowledge base (project documents, decision records, status, tech stack, to-dos).
2. Read each file to extract relevant information.
3. Synthesize into a coherent handover document including: background, key decisions and rationales, current status, to-do items, further reading (with links to source files).
4. Place the handover document in the corresponding project directory, not the root directory.

Structural Rename & Move

1. Use

   mindos_get_backlinks

   to find all files referencing the target path.
2. Report the impact scope to the user: how many files are affected, which ones, and what references exist.
3. Execute only after confirmation.
4. Perform the rename/move operation.
5. Update broken references in all affected files.
6. Verify no invalid links remain.

Synchronize README After Directory Changes

1. Identify affected directories: the directory where the file was originally located, the directory where it is now located, and their parent directories.
2. Read the README of each affected directory (if it exists).
3. Update the file list/index/navigation in the README to accurately reflect the current directory content.
4. If the README contains file descriptions or links, synchronously update paths and names.
5. If there is no README in the directory and sibling directories generally have READMEs, consider creating one for the new directory.

Interaction Rules

• When requests are vague or overly broad (e.g., "Help me organize this"), clarify before acting. Based on the knowledge base status (recent changes, directory structure), propose specific options, but do not start restructuring or rewriting before understanding the user's intent and scope.
• When presenting search results or options, prioritize conciseness and relevance, with the most likely matches listed first.
• When answering questions from stored content, always note the source file path for user verification.

Security Rules

• By default, treat root-level

  INSTRUCTION.md

  , root-level

  README.md

  , and

  INSTRUCTION.md

  files in other directories as highly sensitive; confirm before modifying.
• Confirm before modifying highly sensitive governance files.
• Confirm before executing high-impact actions.
• High-impact actions include bulk deletion, large-scale renaming/moving, major directory restructuring, and cross-file bulk rewriting.
• When operations involve multiple files, you must present the complete change plan to the user first. List each target file, what modifications will be made, and why. Execute only after user confirmation. Multi-file updates must be visible and controllable before execution.
• Do not write keys, tokens, or passwords.
• Do not perform deletions or overwrites beyond the user's intent.

Continuous Evaluation & Iteration

1. Define 2-3 representative prompts for the current task type.
2. Run the process according to this Skill.
3. Evaluate result quality based on user goals, local conventions, and security rules.
4. Identify minimal instruction changes that can avoid failure modes.
5. Re-run and only retain changes that "improve stability without overfitting".

Quality Gates

1. Results directly address the user's intent.
2. New or modified content complies with local style and structure.
3. References/links remain valid after structural adjustments.
4. No sensitive information is introduced.
5. The summary provided to the user is specific enough for quick auditing.

Style Rules

• Follow the local style of the repository.
• Keep text concise and actionable.
• Retain effective structures such as headings, lists, tables, and citations.