Back to Details

mindos-zh

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

MindOS 知识库操作指南

MindOS Knowledge Base Operation Guide

用于在 MindOS 风格的本地知识库中进行安全、一致、可审计的操作。
For secure, consistent, and auditable operations in MindOS-style local knowledge bases.

核心原则

Core Principles

  • 以仓库当前状态为唯一依据。
  • bootstrap 加载的目录树是一等语义资产。 目录名、文件名及其层级结构编码了用户存了什么、如何组织思维。在调用搜索之前，先从这个结构推断内容位置——它往往不需要任何工具调用就能告诉你答案。
  • 写入前先读取。
  • 优先最小化、精确化修改。
  • 变更结果应易于审阅与追踪。
  • 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. 加载根级规则。
  • 优先调用 
    mindos_bootstrap
    。
  • 若不可用，直接读取根 
    INSTRUCTION.md
    与根 
    README.md
    。
  1. 动态发现当前结构。
  • 使用 
    mindos_list_files
    与按需 
    mindos_search_notes
    。
  • 不假设固定一级目录名。
  1. 加载目标路径附近的局部规则。
  • 若存在，读取就近 
    README.md
    / 
    INSTRUCTION.md
    。
  • 优先遵循局部约定，而非全局假设。
  1. 再执行编辑。
若关键上下文缺失，按最佳努力继续，并明确写出假设。
Execute the following process before substantial editing:
  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.
If critical context is missing, proceed with best efforts and explicitly state assumptions.

动态结构规则

Dynamic Structure Rules

  • 不硬编码”标准目录树”。
  • 创建或重写内容前，先从相邻文件推断约定。
  • 命名、标题结构、CSV 字段顺序、引用格式均优先复用现有模式。
  • 新建文件优先跟随同级风格，不引入新标准。
  • 除非用户明确要求，不在根目录下创建文件或子目录。 根目录仅保留顶层治理文件（README、INSTRUCTION、CONFIG）。新内容应放在语义最匹配的现有子目录下，从上下文中的目录树推断合适位置。
  • 创建新文件或目录时，先根据现有结构确定最佳父目录。若没有明显匹配的目录，提出 1-2 个候选位置并询问用户后再创建。
  • 文件增删/移动/重命名后，必须同步更新受影响的 README 文件。 README 是目录的索引与导航入口，任何改变目录内容的操作（创建、删除、移动、重命名文件或子目录）都应自动检查并更新对应目录及其父目录的 README，使其准确反映当前结构。这不需要用户提醒——属于结构一致性的基本纪律。
  • 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

在任何非 trivial 写入前，确认以下检查项：
  1. 目标文件或路径已确认，且存在或应当创建。
  2. 目标位置在合适的子目录下，而非根目录。 若不确定哪个目录最合适，先提出候选并询问用户。
  3. 现有内容已读取，或已明确确认不存在。
  4. 已考虑目标路径附近的治理文档。
  5. 修改范围最小化，且与用户意图一致。
  6. 路径变更带来的引用/反链影响已评估。
Before any non-trivial writing, confirm the following:
  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
    ：加载启动上下文。
  • mindos_list_files
    ：查看文件树。
  • mindos_search_notes
    ：按关键词/范围/类型/日期定位文件。搜索时，第一次就应并行发起多个关键词搜索——同义词、缩写、中英文变体、更宽/更窄的表述。单一关键词很脆弱，一开始就撒网能避免多轮空搜。
  • mindos_get_recent
    ：查看近期活动。
  • mindos_get_backlinks
    ：重命名/移动/删除前评估影响。
  • 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
    ：读取文件内容。
  • mindos_write_file
    ：仅在确需整文件替换时使用。
  • mindos_create_file
    ：创建 
    .md
    /
    .csv
    文件。
  • mindos_delete_file
    ：仅在用户明确意图下删除。
  • mindos_rename_file
    、
    mindos_move_file
    ：结构变更后补做引用检查。
  • 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
    ：定位精确行。
  • mindos_insert_lines
    ：按索引插入。
  • mindos_update_lines
    ：替换指定行区间。
  • mindos_append_to_file
    ：文件末尾追加。
  • mindos_insert_after_heading
    ：标题后插入。
  • mindos_update_section
    ：替换单个 Markdown 章节。
  • 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
    ：追踪/回溯历史。
  • mindos_append_csv
    ：读表头校验后追加单行。
  • 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

  • 若部分 
    mindos_*
    工具不可用，使用可用等效工具，但保持同样安全纪律。
  • 若 
    mindos_bootstrap
    不可用，改为手动读取启动文件。
  • 若缺少行级/章节级工具，用”读取 + 受限重写”方式模拟最小化修改。
  • 若 
    mindos_search_notes
    无结果，不要放弃。bootstrap 时加载的目录树已经在你的上下文中——目录名、文件名及其层级结构本身就有丰富的语义，往往足以推断内容可能在哪里。逐步升级：
    1. 先回顾上下文中已有的目录结构，根据命名、层级与主题相关性推断哪些目录和文件最可能相关。
    2. 直接读取最可能的候选文件确认内容。
    3. 若候选不明确，对特定子目录调用 
      mindos_list_files
      获取 bootstrap 未覆盖的更细粒度结构。
    4. 同时尝试替代关键词（同义词、更宽/更窄范围、中英文变体）作为并行策略。
  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. 搜索现有文档。
  2. 读取目标文档与局部规则。
  3. 执行最小化修改。
  4. 路径变化时保持引用一致。
  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.
Do not imply that you can access private history of other Agent sessions.

沉淀跨 Agent 讨论

Conversation Retrospective & Adaptive Update

  1. 先请用户确认关键决策与结论。
  2. 定位目标文档。
  3. 按“问题、决策、理由、注意事项、后续动作”结构化。
  4. 用最小侵入方式写回。
不要暗示你可访问其他 Agent 会话的私有历史。
  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. 先让用户确认本次复盘目标与范围。
  2. 抽取可复用资产：关键决策、理由、踩坑、未决问题、下一步动作。
  3. 通过搜索并读取候选文档，将每类资产路由到最合适的现有文件。
  4. 若命中文档则按章节/行级最小化更新；若无合适文档，再在相邻主题下创建边界清晰的新文件。
  5. 维护引用与反链一致性，并补一条简短变更说明（改了什么、为什么改）。
  6. 若路由置信度低，先给出 1-2 个候选目标并请用户确认后再写入。
  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.

执行或更新 SOP/工作流

CSV Operations

  1. 完整读取流程文档。
  2. 分步执行并记录结果。
  3. 若流程过时，仅修改受影响章节并说明原因。
  1. Read the header.
  2. Validate field order, quantity, and type.
  3. Append a single line.

CSV 操作

Information Collection & External Execution

  1. 读取表头。
  2. 校验字段顺序、数量、类型。
  3. 追加单行。
  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. 定位权威联系人/名单来源。
  2. 读取外联或执行流程文档。
  3. 基于对象画像标签、领域和语气生成个性化输出。
  4. 将结果与下一步动作回写，确保可追踪。
  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. 读取偏好与上下文文档，例如技术栈、代码风格、约束。
  2. 读取启动或工程流程文档。
  3. 产出与标准一致的初始化脚手架和配置。
  4. 记录关键决策与初始化状态，便于后续接力。
  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. 读取适用的审查与工程规范。
  2. 按命名、错误处理、性能、安全、可维护性进行审查。
  3. 输出可执行问题清单，并给出具体到文件的建议。
  4. 保持与团队既有审查风格一致的语气和结构。
  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.

跨 Agent 接力连续性

Relationship Maintenance & Follow-up Promotion

  1. 将共享知识库视为交接契约。
  2. 接手前先读取任务状态、决策与待办。
  3. 无需重复探索，直接延续执行并保持约定与理由。
  4. 持续回写进度，确保后续会话可立即接手。
  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. 从用户提供的沟通纪要中抽取事实更新、意图与情绪信号。
  2. 结构化更新对应的人脉或关系记录。
  3. 生成下一步策略、待办与建议跟进时间。
  4. 以可复用格式沉淀，保证后续会话可继续执行。
A piece of unstructured input (chat records, meeting minutes, speech-to-text, quick braindump) often contains information that belongs to multiple files. Since MindOS obtains the complete directory tree and inter-document reference relationships at startup, it can parse the input and route it to each target file in one go—users do not need to manually specify destinations.
  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.
This is the core difference between MindOS and tools that "can only modify one file at a time": structural prior knowledge enables coordinated updates across the knowledge base triggered by a single input, with no omissions or misplacements.

结构感知的多文件联动更新

Knowledge Conflict Linked Updates

一段非结构化输入（聊天记录、会议纪要、语音转文字、随手 braindump）往往包含分属多个文件的信息。MindOS 在启动时即获取完整目录树与文档间引用关系，因此能将输入拆解后一次性路由到各个目标文件——用户无需手动指定去向。
  1. 通过 
    mindos_bootstrap
    和 
    mindos_list_files
    加载完整知识库结构与拓扑。
  2. 将输入解析为独立语义单元（事实、决策、想法、行动项、关系更新、新概念等）。
  3. 为每个单元搜索并读取候选目标文件，按主题、范围和已有结构匹配最佳归属。
  4. 写入前，先向用户展示路由计划并请求确认。 用清晰的列表展示：每条信息将写入哪个文件、写在什么位置、为什么放在那里。确认后再执行。
  5. 在每个目标文件的正确位置（章节、标题或行级）执行最小化编辑；仅当没有合理匹配时才新建文件。
  6. 若某单元路由置信度低，先给出候选目标并请用户选择。
  7. 所有写入完成后，汇总"改了什么、在哪里"，便于用户一眼审计。
这正是 MindOS 区别于"一次只能改一个文件"的工具的核心：结构先验意味着一次输入即触发跨知识库的协调更新，不遗漏、不错位。
When a decision, preference, or fact changes (e.g., "We switched from Redis to Memcached"), all documents referencing the old information need to be updated consistently.
  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

当某个决策、偏好或事实发生变化（如"我们从 Redis 换成了 Memcached"），所有引用旧信息的文档都需一致更新。
  1. 搜索整个知识库中引用旧信息的位置（使用多种搜索词，包括缩写和变体）。
  2. 列出所有受影响文件及具体行/章节。
  3. 向用户展示完整变更计划：哪些文件、改什么、为什么。
  4. 用户确认后，逐一最小化更新。
  5. 更新完成后验证不再有不一致的旧引用。
When the user has just completed a complex task and wants to precipitate the process into a reusable workflow, create a structured, general-purpose SOP document—not just a one-time record.
  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.

从经验提炼 SOP

Periodic Review & Summary

当用户刚完成一项复杂任务，想把过程沉淀为可复用的工作流时，创建结构化、通用的 SOP 文档——不只是一次性记录。
  1. 从用户描述中提取操作步骤、决策点、前置条件和常见坑。
  2. 泛化处理：去掉一次性细节，保留可复用模式。
  3. 在 Workflows/ 或类似目录下找合适位置，检查现有 SOP 模板或同级格式。
  4. 创建 SOP，包含：前置条件、分步操作、排障/踩坑、相关文档引用。
  5. 若适用，从相关索引文件链接到新 SOP。
When the user requests a weekly review, monthly retrospective, or progress 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

当用户要求 weekly review、月度复盘或进度总结时：
  1. 用 
    mindos_get_recent
    和/或 
    mindos_get_history
    找出相关时间窗口内变动的文件。
  2. 读取变动文件理解发生了什么。
  3. 按领域分类（项目、Profile、工作流等）。
  4. 产出结构化总结：做了什么关键决策、活跃项目进展、待办事项、需关注的问题。
  5. 询问用户是否要将总结回写为一条 review 记录。
When the user asks questions about their preferences, project status, stored knowledge, etc.:
  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. 从目录树推断哪些文件可能包含答案。
  2. 读取相关文件——不凭通用知识猜测。
  3. 回答必须基于实际存储内容，并注明来源文件。
  4. 若信息不完整或缺失，明确告知，不编造。
When the user wants to add, complete, or modify tasks:
  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.

TODO 与任务列表管理

Handover Document Synthesis

当用户要添加、完成或修改任务时：
  1. 定位 TODO 文件或任务列表（搜索或从目录结构导航）。
  2. 读取当前内容，理解现有格式（复选框、优先级、分类方式）。
  3. 做最小化定向修改：标记完成、添加新项、更新状态。
  4. 保留所有其他内容和格式不变。
  5. 严格遵循现有格式约定——不引入新的任务格式。
When the user needs to generate a handover or briefing document for others (new colleagues, collaborators, supervisors):
  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. 跨知识库识别该主题的所有相关文件（项目文档、决策记录、状态、技术栈、待办）。
  2. 逐一读取提取相关信息。
  3. 合成为一份连贯的交接文档，包含：背景、关键决策与理由、当前状态、待办事项、延伸阅读（附源文件链接）。
  4. 将交接文档放在对应项目目录下，不放根目录。
When renaming or moving a file/directory:
  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. 用 
    mindos_get_backlinks
    查找所有引用目标路径的文件。
  2. 向用户报告影响范围：多少文件受影响、是哪些、引用了什么。
  3. 确认后再执行。
  4. 执行重命名/移动。
  5. 更新所有受影响文件中的断裂引用。
  6. 验证无遗留的失效链接。
After any operation that affects directory structure (creating, deleting, moving, renaming files or subdirectories):
  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.
This step is an automatic follow-up to all structural change operations and does not require a separate user request.

目录变更后同步 README

Interaction Rules

任何影响目录结构的操作（创建、删除、移动、重命名文件或子目录）完成后：
  1. 确定受影响的目录：文件原位置所在目录、新位置所在目录、以及它们的父目录。
  2. 读取每个受影响目录的 README（若存在）。
  3. 更新 README 中的文件列表/索引/导航，使其准确反映当前目录内容。
  4. 若 README 中有文件描述或链接，同步更新路径和名称。
  5. 若目录下没有 README 且同级目录普遍有 README，考虑为新目录创建一个。
此步骤是所有结构变更操作的自动收尾动作，不需要用户单独请求。
  • 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

  • 默认将根级 
    INSTRUCTION.md
    、根级 
    README.md
    和其他目录下的 
    INSTRUCTION.md
    治理文档视为高敏感，先确认再改。
  • 修改高敏感治理文件前先确认。
  • 执行高影响动作前先确认。
  • 高影响动作包括批量删除、大规模重命名/移动、目录大重构、跨文件批量重写。
  • 当操作涉及多个文件时，必须先向用户展示完整的变更计划。 列出每个目标文件、将做什么修改、为什么。等用户确认后再执行。多文件更新在执行前必须可见、可控。
  • 不写入密钥、Token、密码。
  • 不执行超出用户意图的删除或覆写。
Execute a rapid iterative loop for important workflows:
  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. 为当前任务类型定义 2-3 个代表性提示词。
  2. 依据本 Skill 运行流程。
  3. 按用户目标、局部约定与安全规则评估结果质量。
  4. 找到能避免失败模式的最小指令改动。
  5. 复跑并仅保留“提升稳定性且不过拟合”的改动。
Before concluding, confirm:
  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

在结束前确认：
  1. 结果直接回应用户意图。
  2. 新增或修改内容符合局部风格与结构。
  3. 结构调整后引用/链接仍有效。
  4. 未引入敏感信息。
  5. 给用户的总结足够具体，便于快速审计。
  • Follow the local style of the repository.
  • Keep text concise and actionable.
  • Retain effective structures such as headings, lists, tables, and citations.

风格规则

—
  • 遵循仓库局部风格。
  • 文本保持简洁、可执行。
  • 保留标题、清单、表格、引用等有效结构。
—