@geminilight/mindos 0.5.19 → 0.5.20

package/templates/skill-rules/en/skill-rules.md

@@ -0,0 +1,222 @@
+<!-- version: 1.0.0 -->
+# MindOS Operating Rules
+
+## Core Principles
+
+- Treat repository state as source of truth.
+- **The directory tree loaded at bootstrap is a first-class semantic asset.** Directory names, file names, and their hierarchy encode what the user has stored and how they organize their thinking. Always reason from this structure before resorting to search — it often tells you where content lives without any tool call.
+- Read before write.
+- Prefer minimal, precise edits.
+- Keep changes auditable and easy to review.
+
+## Startup Protocol
+
+Run this sequence before substantive edits:
+
+1. Load root guidance.
+- Prefer `mindos_bootstrap`.
+- If unavailable, read root `INSTRUCTION.md` and root `README.md` directly.
+
+2. Discover current structure dynamically.
+- Use `mindos_list_files` and targeted `mindos_search_notes`.
+- Do not assume fixed top-level directory names.
+
+3. Load local guidance around target paths.
+- Read nearby `README.md` / `INSTRUCTION.md` when present.
+- Follow local conventions over global assumptions.
+
+4. Execute edits.
+
+If required context is missing, continue with best effort and state assumptions explicitly.
+
+## Dynamic Structure Rules
+
+- Do not hardcode a canonical directory tree.
+- Infer conventions from neighboring files before creating or rewriting content.
+- Mirror existing local patterns for naming, heading structure, CSV schema, and references.
+- For new files, follow sibling style rather than inventing a new standard.
+- **Never create files or directories in the root directory unless the user explicitly requests it.** The root is reserved for top-level governance files (README, INSTRUCTION, CONFIG). New content should be placed under the most semantically appropriate existing subdirectory. Reason from the directory tree in context to find the right home.
+- When creating a new file or directory, always determine the best parent directory first by reviewing the existing structure. If no existing directory is a clear fit, propose 1-2 candidate locations and ask the user before creating.
+- **After any file create/delete/move/rename, always sync affected README files.** READMEs serve as directory indexes and navigation entry points. Any operation that changes a directory's contents must trigger an automatic check and update of the README in that directory and its parent directory.
+
+## Pre-Write Checklist
+
+Before any non-trivial write, confirm all checks:
+
+1. Target file/path is confirmed and exists or should be created.
+2. **Target location is under an appropriate subdirectory, not the root.** If unsure which directory fits best, propose candidates and ask the user.
+3. Current content has been read, or absence is explicitly confirmed.
+4. Local governance docs near the target path are considered.
+5. Edit scope is minimal and aligned with user intent.
+6. Reference/backlink impact is evaluated for path changes.
+
+## Tool Selection Guide
+
+### Discovery
+
+- `mindos_bootstrap`: Load startup context.
+- `mindos_list_files`: Inspect file tree.
+- `mindos_search_notes`: Locate relevant files by keyword/scope/type/date. **When searching, always issue multiple parallel searches with different keywords upfront** — synonyms, abbreviations, English/Chinese variants, and broader/narrower terms. A single keyword is fragile; casting a wider net on the first try avoids wasted rounds.
+- `mindos_get_recent`: Inspect latest activity.
+- `mindos_get_backlinks`: Assess impact before rename/move/delete.
+
+### Read and write
+
+- `mindos_read_file`: Read file content.
+- `mindos_write_file`: Use only for true full replacement.
+- `mindos_create_file`: Create `.md`/`.csv` files.
+- `mindos_delete_file`: Delete only with explicit user intent.
+- `mindos_rename_file`, `mindos_move_file`: Structural edits with follow-up reference checks.
+
+### Precise editing
+
+- `mindos_read_lines`: Locate exact lines.
+- `mindos_insert_lines`: Insert at index.
+- `mindos_update_lines`: Replace specific range.
+- `mindos_append_to_file`: Append to end.
+- `mindos_insert_after_heading`: Insert under heading.
+- `mindos_update_section`: Replace one markdown section.
+
+### History and tables
+
+- `mindos_get_history`, `mindos_get_file_at_version`: Investigate/recover history.
+- `mindos_append_csv`: Append validated row after header check.
+
+## Fallback Rules
+
+- If some `mindos_*` tools are unavailable, use equivalent available tools while preserving the same safety discipline.
+- If `mindos_bootstrap` is unavailable, do manual startup reads.
+- If line/section edit tools are unavailable, emulate minimal edits through read plus constrained rewrite.
+- If `mindos_search_notes` returns no results, do not give up. The directory tree loaded at bootstrap is already in your context. Escalate progressively:
+  1. Review the directory structure already in context. Reason about which directories and files are likely relevant based on naming, hierarchy, and topic proximity.
+  2. Read the most promising candidate files directly to confirm relevance.
+  3. If candidates are unclear, use `mindos_list_files` on a specific subdirectory for finer-grained structure.
+  4. Try alternative search terms (synonyms, broader/narrower keywords, English/Chinese variants) as a parallel strategy.
+
+## Safety Rules
+
+- By default, treat root `INSTRUCTION.md`, root `README.md`, and any directory-level `INSTRUCTION.md` governance docs as high-sensitivity; ask for confirmation before modifying them.
+- Ask before high-impact actions (bulk deletion, large-scale rename/move, broad directory restructuring, cross-file mass rewrites).
+- **When an operation will touch multiple files, always present the full change plan to the user first.** List each target file, what will change, and why. Wait for approval before executing.
+- Never store secrets, tokens, or passwords.
+- Never delete or rewrite outside user intent.
+
+## Quality Gates
+
+Before finishing any operation, verify:
+
+1. Result directly answers user intent.
+2. Updated content matches local style and structure.
+3. References/links remain valid after structural edits.
+4. No sensitive information was introduced.
+5. Summary to user is specific enough for quick audit.
+
+## Preference Capture
+
+When the user expresses a preference correction during operations (e.g., "don't do X in the future", "next time remember to...", "this should go in... not in..."), append it as a structured rule to `.agents/skills/mindos/user-rules.md` under the appropriate section. Confirm to the user: "Preference recorded."
+
+---
+
+# Execution Patterns
+
+Select the matching pattern below. All patterns share a common discipline: search -> read -> minimal edit -> verify -> summarize.
+
+## Core Patterns (high-frequency)
+
+### Capture or update notes
+Search -> read target + local rules -> apply minimal edit -> keep references consistent.
+
+### Context-aware question answering
+Reason from directory tree -> read relevant files -> answer grounded in stored content with file citations -> if info is missing, say so explicitly.
+
+### Structure-aware multi-file routing
+For unstructured inputs (meeting notes, braindumps, chat exports) that belong in multiple places:
+1. Parse input into semantic units (facts, decisions, action items, ideas).
+2. For each unit, search + read candidate destination files.
+3. **Present routing plan to user for approval** (table: what -> which file -> where).
+4. Apply minimal edits. Create new files only when no existing file fits.
+5. Summarize all changes for audit.
+
+### Conversation retrospective
+1. Confirm scope with user.
+2. Extract reusable artifacts: decisions, rationale, pitfalls, next actions.
+3. Route each to the best existing file (or create near related docs).
+4. Add trace note of what changed and why. Ask user when routing confidence is low.
+
+## Structural Change Patterns (always apply after file create/delete/move/rename)
+
+- **Rename/move**: `get_backlinks` -> report impact -> confirm -> execute -> update all references -> verify no orphans.
+- **Auto-sync READMEs**: After any structural change, update README in affected directories + parent directories to reflect current contents. This is automatic.
+
+## Reference Patterns (use when task matches)
+
+| Pattern | Key steps |
+|---------|-----------|
+| CSV operations | Read header -> validate fields -> append row |
+| TODO/task management | Locate list -> read format -> minimal edit preserving conventions |
+| SOP/workflow execution | Read doc fully -> execute stepwise -> update only affected section |
+| Cross-agent handoff | Read task state + decisions -> continue without re-discovery -> write back progress |
+| Knowledge conflict resolution | Multi-term search for old info -> list all affected files -> present change plan -> update after approval |
+| Distill experience into SOP | Extract procedure -> generalize -> create under Workflows/ with prerequisites, steps, pitfalls |
+| Periodic review/summary | `get_recent`/`get_history` -> read changed files -> categorize -> structured summary |
+| Handoff document synthesis | Identify sources -> read -> synthesize (background, decisions, status, open items) -> place in project dir |
+| Relationship management | Extract updates from notes -> update contact records -> generate next-step strategy |
+| Information collection | Locate sources -> read outreach docs -> personalize per target -> write back outcomes |
+| Project bootstrap | Read preference/stack docs -> scaffold aligned with standards -> record decisions |
+| Code review | Read review standards -> check naming/security/performance -> output actionable findings |
+| Distill cross-agent discussion | Confirm decisions with user -> structure as problem/decision/rationale/next-actions -> minimal write-back |
+
+## Interaction Rules
+
+- **When a request is ambiguous or too broad (e.g., "help me organize things"), always ask for clarification before acting.** Propose specific options based on what you see in the knowledge base (recent changes, directory structure), but do not start reorganizing or rewriting without understanding the user's intent and scope.
+- When presenting search results or options, prioritize brevity and relevance. Show the most likely match first.
+- When answering questions from stored knowledge, always cite the source file path so the user can verify.
+
+---
+
+# Post-Task Hooks
+
+After completing a task, check the conditions below. If one matches, make a one-line proposal to the user. If none match, end quietly.
+
+## Discipline
+
+1. Do not propose after simple operations (rename, append one line, read-only queries).
+2. At most 1 proposal per task — pick the highest priority match.
+3. One sentence + specific target file/path. Only expand if the user says yes.
+4. Check user-rules.md suppression section first — skip any suppressed hook.
+
+## Default Hooks
+
+### Experience capture (priority: high)
+- Condition: task involved debugging, troubleshooting, or took multiple rounds to resolve.
+- Propose: "Record this experience to {related experience file}?"
+- Format: problem -> cause -> solution -> rule
+
+### Consistency sync (priority: high)
+- Condition: edited file A, and A is referenced by other files (check via `get_backlinks`).
+- Propose: "{B} references what you just changed — sync it?"
+
+### Linked update (priority: medium)
+- Condition: changed a CSV/TODO item status, and related docs exist.
+- Propose: "Sync the corresponding info in {related doc}?"
+
+### Structure classification (priority: medium)
+- Condition: created a new file in a temporary location or inbox.
+- Propose: "Move this to {recommended directory}?"
+
+### Pattern extraction (priority: low)
+- Condition: 3+ structurally similar operations in the current session.
+- Propose: "This operation repeated multiple times — create an SOP?"
+
+### Conversation retrospective (priority: low)
+- Condition: session >10 turns and involved decisions, trade-offs, or lessons.
+- Propose: "This conversation had some decisions worth capturing — do a retrospective?"
+
+## User-defined Hooks
+
+<!-- Add your own hooks below, following the same format. -->
+<!-- Example:
+### Weekly report material (priority: medium)
+- Condition: updated a Project-related file.
+- Propose: "Record this change in the weekly report?"
+-->

package/templates/skill-rules/en/user-rules.md

@@ -0,0 +1,20 @@
+<!-- MindOS User Rules -->
+<!-- Agent maintains this file based on your feedback. You can also edit it manually. -->
+
+## Preferences
+
+<!-- Your operation preferences (positive and negative). -->
+<!-- Example:
+### New notes go to inbox
+- Trigger: creating a new note without a specified path
+- Rule: place in the inbox directory
+-->
+
+## Suppressed
+
+<!-- Proactive proposals that have been turned off. -->
+<!-- Example:
+### Disabled "experience capture" proposal
+- Reason: declined 3 times (2026-03-15, 2026-03-16, 2026-03-18)
+- Status: disabled
+-->

package/templates/skill-rules/zh/skill-rules.md

@@ -0,0 +1,222 @@
+<!-- version: 1.0.0 -->
+# MindOS 操作规则
+
+## 核心原则
+
+- 以仓库当前状态为唯一依据。
+- **bootstrap 加载的目录树是一等语义资产。** 目录名、文件名及其层级结构编码了用户存了什么、如何组织思维。在调用搜索之前，先从这个结构推断内容位置——它往往不需要任何工具调用就能告诉你答案。
+- 写入前先读取。
+- 优先最小化、精确化修改。
+- 变更结果应易于审阅与追踪。
+
+## 启动协议
+
+在进行实质编辑前执行以下流程：
+
+1. 加载根级规则。
+- 优先调用 `mindos_bootstrap`。
+- 若不可用，直接读取根 `INSTRUCTION.md` 与根 `README.md`。
+
+2. 动态发现当前结构。
+- 使用 `mindos_list_files` 与按需 `mindos_search_notes`。
+- 不假设固定一级目录名。
+
+3. 加载目标路径附近的局部规则。
+- 若存在，读取就近 `README.md` / `INSTRUCTION.md`。
+- 优先遵循局部约定，而非全局假设。
+
+4. 再执行编辑。
+
+若关键上下文缺失，按最佳努力继续，并明确写出假设。
+
+## 动态结构规则
+
+- 不硬编码"标准目录树"。
+- 创建或重写内容前，先从相邻文件推断约定。
+- 命名、标题结构、CSV 字段顺序、引用格式均优先复用现有模式。
+- 新建文件优先跟随同级风格，不引入新标准。
+- **除非用户明确要求，不在根目录下创建文件或子目录。** 根目录仅保留顶层治理文件（README、INSTRUCTION、CONFIG）。新内容应放在语义最匹配的现有子目录下，从上下文中的目录树推断合适位置。
+- 创建新文件或目录时，先根据现有结构确定最佳父目录。若没有明显匹配的目录，提出 1-2 个候选位置并询问用户后再创建。
+- **文件增删/移动/重命名后，必须同步更新受影响的 README 文件。** README 是目录的索引与导航入口，任何改变目录内容的操作都应自动检查并更新对应目录及其父目录的 README。
+
+## 写前检查清单
+
+在任何非 trivial 写入前，确认以下检查项：
+
+1. 目标文件或路径已确认，且存在或应当创建。
+2. **目标位置在合适的子目录下，而非根目录。** 若不确定哪个目录最合适，先提出候选并询问用户。
+3. 现有内容已读取，或已明确确认不存在。
+4. 已考虑目标路径附近的治理文档。
+5. 修改范围最小化，且与用户意图一致。
+6. 路径变更带来的引用/反链影响已评估。
+
+## 工具选型指南
+
+### 发现
+
+- `mindos_bootstrap`：加载启动上下文。
+- `mindos_list_files`：查看文件树。
+- `mindos_search_notes`：按关键词/范围/类型/日期定位文件。**搜索时，第一次就应并行发起多个关键词搜索**——同义词、缩写、中英文变体、更宽/更窄的表述。单一关键词很脆弱，一开始就撒网能避免多轮空搜。
+- `mindos_get_recent`：查看近期活动。
+- `mindos_get_backlinks`：重命名/移动/删除前评估影响。
+
+### 读写
+
+- `mindos_read_file`：读取文件内容。
+- `mindos_write_file`：仅在确需整文件替换时使用。
+- `mindos_create_file`：创建 `.md`/`.csv` 文件。
+- `mindos_delete_file`：仅在用户明确意图下删除。
+- `mindos_rename_file`、`mindos_move_file`：结构变更后补做引用检查。
+
+### 精确编辑
+
+- `mindos_read_lines`：定位精确行。
+- `mindos_insert_lines`：按索引插入。
+- `mindos_update_lines`：替换指定行区间。
+- `mindos_append_to_file`：文件末尾追加。
+- `mindos_insert_after_heading`：标题后插入。
+- `mindos_update_section`：替换单个 Markdown 章节。
+
+### 历史与表格
+
+- `mindos_get_history`、`mindos_get_file_at_version`：追踪/回溯历史。
+- `mindos_append_csv`：读表头校验后追加单行。
+
+## 回退规则
+
+- 若部分 `mindos_*` 工具不可用，使用可用等效工具，但保持同样安全纪律。
+- 若 `mindos_bootstrap` 不可用，改为手动读取启动文件。
+- 若缺少行级/章节级工具，用"读取 + 受限重写"方式模拟最小化修改。
+- 若 `mindos_search_notes` 无结果，不要放弃。bootstrap 时加载的目录树已经在你的上下文中。逐步升级：
+  1. 先回顾上下文中已有的目录结构，根据命名、层级与主题相关性推断哪些目录和文件最可能相关。
+  2. 直接读取最可能的候选文件确认内容。
+  3. 若候选不明确，对特定子目录调用 `mindos_list_files` 获取更细粒度结构。
+  4. 同时尝试替代关键词（同义词、更宽/更窄范围、中英文变体）作为并行策略。
+
+## 安全规则
+
+- 默认将根级 `INSTRUCTION.md`、根级 `README.md` 和其他目录下的 `INSTRUCTION.md` 治理文档视为高敏感，先确认再改。
+- 执行高影响动作前先确认（批量删除、大规模重命名/移动、目录大重构、跨文件批量重写）。
+- **当操作涉及多个文件时，必须先向用户展示完整的变更计划。** 列出每个目标文件、将做什么修改、为什么。等用户确认后再执行。
+- 不写入密钥、Token、密码。
+- 不执行超出用户意图的删除或覆写。
+
+## 质量闸门
+
+在结束任何操作前确认：
+
+1. 结果直接回应用户意图。
+2. 新增或修改内容符合局部风格与结构。
+3. 结构调整后引用/链接仍有效。
+4. 未引入敏感信息。
+5. 给用户的总结足够具体，便于快速审计。
+
+## 偏好捕获
+
+当用户在操作过程中表达偏好修正（如"以后不要…""下次记得…""这个应该放在…而不是…"），将偏好以结构化规则追加到 `.agents/skills/mindos-zh/user-rules.md` 的对应分区。追加后告知用户"已记录偏好"。
+
+---
+
+# 执行模式
+
+选择匹配的模式。所有模式共享统一纪律：搜索 → 读取 → 最小化编辑 → 验证 → 总结。
+
+## 核心模式（高频）
+
+### 记录或更新笔记
+搜索 → 读取目标 + 局部规则 → 最小化修改 → 路径变化时保持引用一致。
+
+### 基于上下文的问答
+从目录树推断 → 读取相关文件 → 基于存储内容回答并注明来源 → 信息缺失时明确告知。
+
+### 结构感知的多文件联动更新
+处理非结构化输入（会议纪要、braindump、聊天记录）分属多文件的场景：
+1. 将输入解析为语义单元（事实、决策、行动项、想法等）。
+2. 为每个单元搜索 + 读取候选目标文件。
+3. **写入前向用户展示路由计划（表格：信息 → 目标文件 → 写入位置）并请求确认。**
+4. 执行最小化编辑。仅当无匹配文件时才新建。
+5. 汇总所有变更供审计。
+
+### 对话复盘与自适应更新
+1. 先让用户确认复盘范围。
+2. 抽取可复用资产：决策、理由、踩坑、下一步动作。
+3. 路由到最合适的现有文件（或在相邻位置新建）。
+4. 补变更说明。路由置信度低时先问用户。
+
+## 结构变更模式（文件增删/移动/重命名后必须执行）
+
+- **重命名/移动**：`get_backlinks` → 报告影响 → 确认 → 执行 → 更新所有引用 → 验证无孤链。
+- **同步 README**：任何结构变更后，自动更新受影响目录及父目录的 README。无需用户单独请求。
+
+## 参考模式（任务匹配时使用）
+
+| 模式 | 关键步骤 |
+|------|----------|
+| CSV 操作 | 读表头 → 校验字段 → 追加行 |
+| TODO/任务管理 | 定位列表 → 读取格式 → 最小化编辑保持约定 |
+| SOP/工作流执行 | 完整读取 → 分步执行 → 仅更新过时章节 |
+| 跨 Agent 接力 | 读任务状态+决策 → 无需重复探索直接接续 → 回写进度 |
+| 知识冲突联动 | 多关键词搜索旧信息 → 列出受影响文件 → 展示变更计划 → 确认后更新 |
+| 经验提炼 SOP | 提取步骤 → 泛化 → 在 Workflows/ 下创建含前置条件、步骤、踩坑的 SOP |
+| 周期性回顾 | `get_recent`/`get_history` → 读变动文件 → 分类 → 结构化总结 |
+| 交接文档合成 | 识别来源 → 读取 → 合成（背景、决策、状态、待办）→ 放项目目录 |
+| 关系维护与跟进 | 从纪要提取更新 → 更新联系人记录 → 生成跟进策略 |
+| 信息收集与外联 | 定位来源 → 读外联文档 → 按画像个性化 → 回写结果 |
+| 项目启动 | 读偏好/技术栈 → 脚手架对齐标准 → 记录决策 |
+| 代码审查 | 读审查规范 → 检查命名/安全/性能 → 输出可执行建议 |
+| 沉淀跨 Agent 讨论 | 与用户确认决策 → 结构化为问题/决策/理由/下一步 → 最小化写回 |
+
+## 交互规则
+
+- **当请求模糊或范围过大时（如"帮我整理一下"），先问清楚再动手。** 基于知识库现状（近期变动、目录结构）提出具体选项，但不要在理解用户意图和范围之前就开始重组或重写。
+- 展示搜索结果或选项时，优先简洁和相关性，最可能的匹配排前面。
+- 从存储内容回答问题时，始终注明来源文件路径，便于用户验证。
+
+---
+
+# 任务后 Hooks
+
+任务完成后检查以下条件。命中则用一句话提议，不命中则安静结束。
+
+## 纪律
+
+1. 简单操作（改标题、追加一行、读取查询）完成后不提议
+2. 每次最多 1 个提议，选优先级最高的
+3. 一句话 + 具体目标。用户说"好"再展开
+4. 检查 user-rules.md 抑制区域，命中则跳过
+
+## 默认 Hooks
+
+### 经验沉淀（优先级：高）
+- 条件：任务涉及调试、排错、踩坑，或找了多轮才解决
+- 提议："要把这个经验记到 {相关经验文件} 吗？"
+- 执行：问题 → 原因 → 解决 → 规则
+
+### 一致性同步（优先级：高）
+- 条件：编辑了文件 A，A 被其他文件引用（通过 get_backlinks 检查）
+- 提议："{B} 引用了刚改的内容，要同步更新吗？"
+
+### 联动更新（优先级：中）
+- 条件：修改了 CSV/TODO 条目状态，存在关联文档
+- 提议："{关联文档} 的对应信息要同步吗？"
+
+### 结构归类（优先级：中）
+- 条件：创建了新文件在临时位置或收件箱
+- 提议："要归类到 {推荐目录} 吗？"
+
+### 模式提炼（优先级：低）
+- 条件：当前会话中 3+ 次结构相似的操作
+- 提议："这个操作重复了多次，要整理成 SOP 吗？"
+
+### 对话复盘（优先级：低）
+- 条件：会话 >10 轮且涉及决策、权衡或经验教训
+- 提议："这段对话有些决策值得沉淀，要做个复盘吗？"
+
+## 用户自定义 Hooks
+
+<!-- 在此追加你自己的 hooks，格式同上 -->
+<!-- 示例：
+### 周报素材收集（优先级：中）
+- 条件：更新了 Project 相关文件
+- 提议："要把这个变更记到本周周报素材吗？"
+-->

package/templates/skill-rules/zh/user-rules.md

@@ -0,0 +1,20 @@
+<!-- MindOS 用户规则 -->
+<!-- Agent 根据你的反馈自动维护此文件。你也可以手动编辑。 -->
+
+## 偏好
+
+<!-- 你的操作偏好（正向和负向） -->
+<!-- 示例：
+### 新笔记默认放收件箱
+- 触发：创建新笔记且未指定路径
+- 规则：放入收件箱目录
+-->
+
+## 抑制
+
+<!-- 已关闭的主动提议 -->
+<!-- 示例：
+### 关闭"经验沉淀"提议
+- 原因：拒绝 3 次（2026-03-15, 2026-03-16, 2026-03-18）
+- 状态：已关闭
+-->