SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmindos-zh

mindos-zh

Office & productivity

View repository

Updated 10-15 21:50

About this skill

MindOS Skill

CLI Commands

Use mindos file <子命令> to complete all knowledge base operations. Add --json to get structured output.

Operation Command
List files mindos file list
Read file mindos file read <路径>
Write/overwrite mindos file write <路径> --content "..."
Create new file mindos file create <路径> --content "..."
Append content mindos file append <路径> --content "..."
Edit paragraph mindos file edit-section <路径> -H "## 标题" --content "..."
Insert after heading mindos file insert-heading <路径> -H "## 标题" --content "..."
Append CSV row mindos file append-csv <路径> --row "列1,列2,列3"
Delete file mindos file delete <路径>
Rename/move mindos file rename <旧> <新>
Search mindos search "关键词"
Backlinks mindos file backlinks <路径>
Recent files mindos file recent --limit 10
Git history mindos file history <路径>
List spaces mindos space list
Create space mindos space create "名称"

MCP users: If you only have MCP tools (mindos_*), use them directly—the tool schemas already include their descriptions. When the CLI is available, prefer the CLI (saves more tokens).

CLI Installation

npm install -g @geminilight/mindos
# 远程模式：mindos config set url http://<IP>:<端口> && mindos config set authToken <token>

Rules

  1. Understand the structure first — list the knowledge base directory tree, then search or write.
  2. Read-only by default. Write only when the user explicitly asks to save, record, organize, or edit.
  3. Rule priority(from high to low): the user's current instruction → .mindos/user-preferences.md → most recent directory INSTRUCTION.md → root INSTRUCTION.md → this skill's defaults.
  4. Propose a plan first for multi-file edits. Show the complete list of changes, and execute only after approval.
  5. After create/delete/move/rename → automatically sync related READMEs。
  6. Read before writing. Do not write based on assumptions.
  7. Close naturally. Your reply should only fulfill the user's request for this turn; after a complete lookup or write, do not add unnecessary follow-up questions.
  8. Respect source code boundaries. This skill only handles the MindOS knowledge base. When the user asks to modify application/project source code but there is no source file, code workspace, or code tool available, ask for the specific repository/file/code snippet; do not search or write knowledge base notes to pass off as code changes. For bare code requests, do not use the KB's list/search/read tools to find source code files.

Answer Closing

Before the task ends, output according to this contract:

  • Lookup / summary / citation: Give the conclusion first, attach stable file paths, and remain read-only. When the user names a specific local file path, the final answer must include this original path. When the user explicitly says not to modify or requests read-only handling, end with a short sentence in the user's language stating that no changes were made (in Chinese use 「未做任何修改。」; in English use "No changes were made."). Unless the user asks for a next step or the evidence is insufficient, do not end with "Should I save/record/update this?".
  • Save / update / append: Only after the write tool succeeds, report the real path and operation. Use stable wording:已保存到 <路径>、已更新 <路径>、已追加到 <路径>. Then add one extremely short summary.
  • Uploaded content writing: When the user asks to organize the uploaded content into notes and the target type is clear, use the uploaded content directly; do at most one lightweight structure/README check, then write the note. Do not stop at the directory listing.
  • Need clarification: Ask only when the missing information would change the target location, scope, cost, safety, or reversibility. Ask only one specific question at a time; when necessary, offer 2-3 possible directions.
  • No evidence or tool failure: Clearly state what was not found, which action failed, and how to recover next. For search tasks lacking evidence, do not proactively propose saving, recording, creating, or supplementing that idea unless the user asks to capture it. Do not reply with an empty response.
  • Language fidelity: Preserve the user's language and the key terminology in the original notes. For terminology in Chinese notes, prioritize saying it as originally written; do not casually translate it into English; put English explanations in parentheses only when helpful.
  • Read-only closure: When the user only wants a summary, meeting context, or next steps, answer and stop. Do not additionally ask "Do you want me to save/record/draft/write/supplement/adjust/export/continue executing?". The last sentence should be a declarative sentence, not end with a question. When answering according to an SOP or workflow, you must cite the SOP/workflow path relied upon. When the user only asks about the next step, do not ask back whether to execute it.

Retrieval strategy

When retrieving knowledge, take two paths, then filter first and deep-read afterward:

Path 1: Directory structure scan

First look at the knowledge base directory tree and file names. Titles and directory names often already expose the answer. For example, if the user asks about "authentication schemes", seeing Decisions/auth-jwt-vs-session.md is a strong candidate, and you can read it directly.

  • After Bootstrap, first scan paths and directory names related to the question topic.
  • Pay attention to directory semantics:Decisions/、Projects/、Workflows/、Resources/ and other directories represent different content types.
  • In a small knowledge base (fewer than 50 files), quickly scanning the tree is often more reliable than searching.

Path 2: Full-text search

When the file names do not reveal it, search the content.

  • Extract keywords from the user's own words. If the user says "that very slow interface", you can search "slow interface" or "performance API".
  • One precise search is usually better than 4 vague searches. Add a second search only when the first result has fewer than 3 items, or the topic clearly has Chinese/English/abbreviation variants.
  • Do not mechanically send 2-4 searches every time. Judge first, then retrieve precisely.

Filtering: look at the snippet first, then deep-read

Search results have snippets and BM25 scores. Use them to decide what to read:

  • High score + clearly relevant snippet → read the full text.
  • Medium score + partially relevant snippet → read only when there is no better candidate.
  • Low score or off-topic snippet → skip. Do not read every search result.
  • The goal is to deep-read 1-3 files, not to shallow-read 10 files.

Prohibitions (hard-learned lessons)

  • Do not write to the root directory of the knowledge base(unless explicitly requested). The root directory should only contain governance files; place new content in the most appropriate subdirectory.
  • Do not assume directory names. Infer from the actual directory tree—the knowledge base may use Chinese names or a flat structure.
  • Do not make small changes by overwriting the entire file. Use mindos file edit-section or mindos file insert-heading for precise modifications; overwriting the entire file breaks git diff.
  • Do not modify INSTRUCTION.md or README.md。 governance documents without confirmation—highly sensitive.
  • Do not create files without looking at neighbors. First read 1-2 files in the target directory to understand naming and style.
  • Do not leave orphaned references. After renaming/moving, check backlinks and update all references.
  • Do not skip confirmation for multi-file writes. The user's mental model may differ from yours.

MindOS Concepts

  • Space — a knowledge partition organized according to your way of thinking. Agents follow the same structure.
  • Instruction — INSTRUCTION.md, a rules file that all connected Agents follow.
  • Skill — teaches Agents how to read, write, and organize the knowledge base.
  • Inbox — Inbox/ directory is the quick capture area. When content has no clear home for the time being, put it here first, then organize it later—batched categorization manually by the user or with AI assistance.

A note can carry both instructions and skills at the same time—they are just Markdown files in the directory tree.

Decision Tree

用户请求
  │
  ├─ 查找 / 总结 / 引用？
  │   └─ [只读路径]：搜索 → 读取 → 带引用回答。不写入。
  │
  ├─ 保存 / 记录 / 更新 / 整理具体内容？
  │   ├─ 知道放哪 → [单文件编辑]
  │   ├─ 不知道放哪 → [收集箱路径] — 存到 Inbox/，之后再归类
  │   └─ 多文件或不确定 → [多文件路由] — 先出方案
  │
  ├─ 整理收集箱 / 归类收集内容？
  │   └─ [收集箱整理] — 读 Inbox/ 文件，提议目标位置，获批后移动
  │
  ├─ 结构变更（重命名 / 移动 / 删除 / 重组）？
  │   └─ [结构路径] — 变更前后检查反向链接
  │
  ├─ 流程性 / 可重复任务？
  │   └─ [SOP 路径] — 找到并执行现有 SOP，或创建新的
  │
  ├─ 复盘 / 提炼 / 交接？
  │   └─ [复盘路径]
  │
  ├─ 知识健康检查 / 检测冲突？
  │   └─ [健康检查路径] — 读取 references/knowledge-health.md
  │
  └─ 模糊？
      └─ 提问。基于知识库状态提出 2-3 个具体选项。

Judgment Heuristics

Save intent boundaries:

  • "Help me note this down" / "save" = write
  • "Search for it" / "summarize" = read-only
  • "Organize it" → ask first: display only, or write back to the knowledge base?
  • "Organize these things" but no files, current file, uploaded content, or target scope → ask first what to organize. At most one lightweight directory/tree check is allowed to give specific options such as Inbox/, a certain Space, the current file, etc.; before clarification, do not move, edit, or deeply read content.
  • "Tell me the next step" → read the SOP or workflow, answer the next step and the basis path, then stop. Unless the user asks to continue executing, do not ask whether to execute, draft, save, write, or continue now.

File location uncertain:

  • Cannot decide within 5 seconds → save to Inbox/, tell the user, and later propose categorization
  • "Put it anywhere" / "just leave it for now" → save to Inbox/
  • User drags in a file or pastes unstructured content but does not specify a location → Inbox/

Stable routing and file names:

  • If an obviously related file exists, prefer updating the existing file rather than creating a duplicate note.
  • If the user explicitly asks to record a fact and an obviously related file already carries it, update that file locally or explain that it is already recorded there. Do not ask whether to save a duplicate Inbox note.
  • Troubleshooting experience goes preferentially in Debugging/; handoffs go in Handoffs/; meeting notes go in Meetings/; quick captures with unclear ownership go in Inbox/。
  • When context handoff is explicitly requested, after reading the available local handoff notes, create or update a concise handoff note under Handoffs/ . Include the goal, related files, verification status, and remaining risks, and report the save path.
  • New file names are generated from the specific topic. Unless the directory already has another convention, use lowercase ASCII kebab-case by default. Preserve existing product terms and naming habits in the same directory, for example mindroot and mind-root should not be switched back and forth.
  • Filenames prioritize expressing reusable themes, not fancy summarization: for Agent benchmark MIND_ROOT troubleshooting experience, use agent-benchmark-mindroot...; for rapid capture of Skill optimization and query replay, filenames should try to preserve both skill-optimization and the core theme.
  • When the user says "current file", by default treat currentFile as the target, unless this would violate safety boundaries or local governance rules.

Scope creep:

  • Input routed to >5 files → pause for confirmation
  • "Update all" + spanning multiple themes → confirm in batches

Citation conventions: When citing knowledge base content, the file path must be included.

Post-task hooks

After write tasks (not simple reads), scan this table. At most 1 proposal; the highest priority takes precedence. First check .mindos/user-preferences.md suppression items.

Hook Priority Condition
Experience capture High Debugging, troubleshooting, or multi-round work
Consistency sync High The edited file has backlinks
SOP drift Medium Executed according to the SOP but actually deviated from the steps
Related updates Medium Changed CSV/TODO status and there are related documents
Structural classification Medium Created a file in a temporary location or inbox
Pattern extraction Low 3+ structurally similar operations in this session

When triggered → read references/post-task-hooks.md。

Preference capture

When the user expresses a persistent preference → read references/preference-capture.md, and follow the confirm-write process.

Future-behavior expressions like "from now on...", "next time...", "from now on..." are preference signals and do not equal automatic write permission. Unless the user explicitly says "save/record/write this preference", confirm first whether to save it.

SOP authoring

When creating/rewriting a workflow SOP → read references/sop-template.md。

Inbox

Inbox/ The directory is the knowledge base's rapid capture area and has its own INSTRUCTION.md constraining behavior.

When to use the Inbox:

  • The user says "just store it for now" / "put it in the inbox" / "put it anywhere", without specifying a concrete location
  • The content clearly does not belong to any existing space or directory
  • Batch importing multiple files that need to be classified one by one

How to store to the Inbox:

mindos file create "Inbox/<文件名>.md" --content "..."

How to organize the Inbox:

  1. List staged files:mindos file list Inbox/
  2. Read each file and understand its content
  3. Based on the knowledge base structure, propose the best target directory for each file
  4. Show the user the complete routing plan, and execute after approval. Explicitly use terms such as "routing plan", and list each source file path.
  5. Move files:mindos file rename "Inbox/<文件>" "<目标目录>/<文件>"
  6. After moving, check whether the target directory's README needs updating

Aging reminder: Files in the Inbox older than 7 days are considered "aging". If aging files are found during bootstrap, proactively remind: "The inbox has N files that have been sitting there for over a week. Would you like me to help organize them?"

Knowledge health check

When the user asks to check knowledge base health, detect conflicts, audit quality, or says "knowledge health check" / "detect conflicts" / "check knowledge health" → Read references/knowledge-health.md to get the full process.

Check dimensions overview:

  • Contradictions/conflicts: different files on the same topic contradict each other
  • Broken links: references to files that do not exist
  • Outdated content: files marked with an expiration date, or active topics not updated for more than 6 months
  • Duplicate content: two files cover the same topic and do not reference each other
  • Orphan files: zero backlinks, hard to discover
  • Structural issues: files in the wrong directory, missing README, aging files in the inbox

Failure recovery

When a file path named by the user does not exist:

  1. Clearly state that the requested path does not exist.
  2. Infer recovery search terms from the file name and the user's own words, do not search only for the literal missing。
  3. Search or scan for possible alternative records.
  4. If there are candidates, list the strongest alternative paths; if not, state that no related records were found and explain what was searched.

Error handling (CLI)

"command not found: mindos"  → npm install -g @geminilight/mindos
"Mind root not configured"   → mindos onboard
"401 Unauthorized"           → 检查 AUTH_TOKEN：在服务器运行 mindos token
"ECONNREFUSED"               → 在服务器启动：mindos start