@geminilight/mindos 0.5.11 → 0.5.13

package/skills/mindos/SKILL.md

@@ -110,172 +110,52 @@ Before any non-trivial write, confirm all checks:
 
 ## Execution Patterns
 
-### Capture or update notes
-
-1. Search existing docs.
-2. Read target docs and local rules.
-3. Apply minimal edit.
-4. Keep references consistent when paths change.
-
-### Distill cross-agent discussion
-
-1. Ask user to confirm key decisions and conclusions.
-2. Locate destination docs.
-3. Structure content as problem, decision, rationale, caveats, next actions.
-4. Write back with minimal invasive edits.
-
-Never imply access to private history from other agent sessions.
-
-### Conversation retrospective and adaptive updates
-
-1. Ask the user to confirm retrospective objective and scope for this conversation.
-2. Extract reusable artifacts: decisions, rationale, pitfalls, unresolved questions, and next actions.
-3. Route each artifact to the most appropriate existing file by searching and reading candidate docs.
-4. If a matching file exists, update minimally at section/line level; if not, create a well-scoped new file near related docs.
-5. Keep references/backlinks consistent and add a short trace note of what changed and why.
-6. If confidence in file routing is low, present 1-2 candidate destinations and ask user to choose before writing.
-
-### Execute or update workflow/SOP docs
-
-1. Read workflow doc fully.
-2. Execute stepwise and record outcomes.
-3. If outdated, update only affected section and include rationale.
-
-### CSV operations
-
-1. Read header.
-2. Validate field order, count, and type.
-3. Append one row.
-
-### Information collection and outreach
-
-1. Locate authoritative contact/list sources.
-2. Read relevant outreach/execution workflow docs.
-3. Generate personalized outputs per target using profile tags, domain, and tone.
-4. Write outcomes and next actions back for traceability.
-
-### Project bootstrap with personal/team standards
-
-1. Read preference/context docs such as stack, style, and constraints.
-2. Read startup/engineering workflow docs.
-3. Produce initial scaffold/configuration aligned with those standards.
-4. Record key decisions and setup status for future handoff.
-
-### Standards-aligned code review
-
-1. Read applicable review and engineering standards.
-2. Review naming, error handling, performance, security, and maintainability.
-3. Output actionable findings with concrete file-level suggestions.
-4. Keep tone and structure consistent with team review style.
-
-### Cross-agent handoff continuity
-
-1. Treat the shared knowledge base as handoff contract.
-2. Before continuing work, read task state, decisions, and pending items.
-3. Continue without re-discovery and preserve conventions/rationale.
-4. Write back progress so later sessions can resume immediately.
-
-### Relationship and follow-up management
-
-1. Extract factual updates, intent, and sentiment from user-provided conversation notes.
-2. Update relationship/contact records in structured form.
-3. Generate next-step strategy, todo items, and suggested follow-up timing.
-4. Store updates in reusable format for future session continuity.
-
-### Structure-aware multi-file routing
-
-A single unstructured input (chat export, meeting notes, voice transcript, braindump) often contains information that belongs in multiple places. MindOS knows the full directory tree and inter-document relationships from bootstrap, so it can decompose the input and route each piece to the right file — in one pass, without the user manually specifying destinations.
-
-1. Load structure context via `mindos_bootstrap` and `mindos_list_files` to understand the full knowledge topology.
-2. Parse the input into distinct semantic units (facts, decisions, ideas, action items, relationship updates, new concepts).
-3. For each unit, search and read candidate destination files to find the best match by topic, scope, and existing structure.
-4. **Before writing, present the routing plan to the user for approval.** Show a clear summary table: what will be written, to which file, at which location. Only proceed after user confirms.
-5. Apply minimal edits to each target file at the correct location (section, heading, or line level). Create new files only when no existing file is a reasonable fit.
-6. If routing confidence is low for any unit, present candidate destinations and ask the user to choose.
-7. After all writes, summarize what changed and where, so the user can audit the full update in one glance.
-
-This pattern is what makes MindOS fundamentally different from document-per-document tools: the structural prior means one input triggers coordinated updates across the knowledge base, and nothing falls through the cracks because the agent sees the whole graph.
-
-### Knowledge conflict resolution
-
-When a decision, preference, or fact changes (e.g., "we switched from Redis to Memcached"), all documents referencing the old information must be updated consistently.
-
-1. Search the entire knowledge base for references to the outdated information (use multiple search terms, including abbreviations and variants).
-2. List all affected files and the specific lines/sections that reference the old decision.
-3. Present the full change plan to the user: which files, what will change, and why.
-4. After approval, update each file with minimal targeted edits.
-5. Verify no inconsistent references remain after the update.
-
-### Distill experience into new SOP
-
-When the user has just completed a complex task and wants to capture the process for reuse, create a structured, reusable workflow document — not just a one-time record.
-
-1. Extract the procedure, decision points, prerequisites, and common pitfalls from the user's description.
-2. Generalize: remove one-off specifics, keep the reusable pattern.
-3. Find the appropriate location under Workflows/ or a similar directory. Check for existing SOP templates or sibling format.
-4. Create the SOP with clear sections: prerequisites, step-by-step procedure, troubleshooting/pitfalls, and references to related docs.
-5. Link the new SOP from relevant index files if applicable.
-
-### Periodic review and summary
-
-When the user asks for a weekly review, monthly recap, or progress summary:
-
-1. Use `mindos_get_recent` and/or `mindos_get_history` to identify files changed in the relevant time window.
-2. Read changed files to understand what happened.
-3. Categorize changes by area (projects, profile, workflows, etc.).
-4. Produce a structured summary: key decisions made, progress on active projects, open items, and things that need attention.
-5. Offer to write the summary back as a review note if the user wants to keep it.
-
-### Context-aware question answering
-
-When the user asks a question about themselves, their projects, preferences, or stored knowledge:
-
-1. Reason from the directory tree to identify which files likely contain the answer.
-2. Read the relevant files — do not guess or assume from general knowledge.
-3. Answer grounded in actual stored content, citing source files.
-4. If the information is incomplete or missing, say so explicitly rather than fabricating.
-
-### TODO and task list management
-
-When the user wants to add, complete, or modify tasks:
-
-1. Locate the TODO file or task list (search or navigate from directory structure).
-2. Read current content to understand existing format (checkboxes, priorities, categories).
-3. Make minimal targeted edits: mark items, add items, or update status.
-4. Preserve all other existing content and formatting.
-5. Follow the existing format conventions exactly — do not introduce a new task format.
-
-### Handoff document synthesis
-
-When the user needs to create a handoff or briefing document for someone else (new team member, collaborator, manager):
-
-1. Identify all relevant source files across the knowledge base for the topic (project docs, decisions, status, tech stack, open items).
-2. Read each source file to extract the relevant information.
-3. Synthesize into a single coherent handoff document with sections: background, key decisions and rationale, current status, open items, and further reading (with links to source files).
-4. Place the handoff document in the appropriate project directory, not the root.
-
-### Structural rename and move
-
-When renaming or moving files/directories:
-
-1. Use `mindos_get_backlinks` to find all files referencing the target path.
-2. Report the full impact scope to the user: how many files, which ones, what references.
-3. Ask for confirmation before proceeding.
-4. Execute the rename/move.
-5. Update all broken references in affected files.
-6. Verify no orphaned links remain.
-
-### Auto-sync READMEs after directory changes
-
-After any operation that affects directory structure (creating, deleting, moving, or renaming files or subdirectories):
-
-1. Identify affected directories: the directory where the file was (source), the directory where it now is (destination), and their parent directories.
-2. Read the README in each affected directory (if one exists).
-3. Update file listings, indexes, and navigation in each README to accurately reflect the current directory contents.
-4. If the README contains file descriptions or links, update paths and names accordingly.
-5. If a directory has no README but sibling directories generally do, consider creating one for the new directory.
-
-This step is an automatic follow-up to all structural change operations — it does not require a separate user request.
+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 — no separate user request needed.
+
+### 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
 
@@ -293,28 +173,12 @@ This step is an automatic follow-up to all structural change operations — it d
 - Never store secrets, tokens, or passwords.
 - Never delete or rewrite outside user intent.
 
-## Continuous Evaluation Loop
-
-For important workflows, run a fast iterate loop:
-
-1. Define 2-3 representative prompts for the current task type.
-2. Run the workflow with this skill guidance.
-3. Check result quality against user intent, local conventions, and safety rules.
-4. Identify the smallest instruction change that would prevent observed failure modes.
-5. Re-run prompts and keep only changes that improve consistency without overfitting.
-
 ## Quality Gates
 
-Before finishing, verify:
+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.
-
-## Style Rules
-
-- Follow repository-local style.
-- Keep language concise and execution-oriented.
-- Preserve useful structure like headings, checklists, tables, and references.

package/skills/mindos-zh/SKILL.md

@@ -108,172 +108,52 @@ description: >
 
 ## 执行模式
 
-### 记录或更新笔记
-
-1. 搜索现有文档。
-2. 读取目标文档与局部规则。
-3. 执行最小化修改。
-4. 路径变化时保持引用一致。
-
-### 沉淀跨 Agent 讨论
-
-1. 先请用户确认关键决策与结论。
-2. 定位目标文档。
-3. 按“问题、决策、理由、注意事项、后续动作”结构化。
-4. 用最小侵入方式写回。
-
-不要暗示你可访问其他 Agent 会话的私有历史。
-
-### 对话复盘与自适应更新
-
-1. 先让用户确认本次复盘目标与范围。
-2. 抽取可复用资产：关键决策、理由、踩坑、未决问题、下一步动作。
-3. 通过搜索并读取候选文档，将每类资产路由到最合适的现有文件。
-4. 若命中文档则按章节/行级最小化更新；若无合适文档，再在相邻主题下创建边界清晰的新文件。
-5. 维护引用与反链一致性，并补一条简短变更说明（改了什么、为什么改）。
-6. 若路由置信度低，先给出 1-2 个候选目标并请用户确认后再写入。
-
-### 执行或更新 SOP/工作流
-
-1. 完整读取流程文档。
-2. 分步执行并记录结果。
-3. 若流程过时，仅修改受影响章节并说明原因。
-
-### CSV 操作
-
-1. 读取表头。
-2. 校验字段顺序、数量、类型。
-3. 追加单行。
-
-### 信息收集与外联执行
-
-1. 定位权威联系人/名单来源。
-2. 读取外联或执行流程文档。
-3. 基于对象画像标签、领域和语气生成个性化输出。
-4. 将结果与下一步动作回写，确保可追踪。
-
-### 按个人与团队标准启动项目
-
-1. 读取偏好与上下文文档，例如技术栈、代码风格、约束。
-2. 读取启动或工程流程文档。
-3. 产出与标准一致的初始化脚手架和配置。
-4. 记录关键决策与初始化状态，便于后续接力。
-
-### 按标准执行代码审查
-
-1. 读取适用的审查与工程规范。
-2. 按命名、错误处理、性能、安全、可维护性进行审查。
-3. 输出可执行问题清单，并给出具体到文件的建议。
-4. 保持与团队既有审查风格一致的语气和结构。
-
-### 跨 Agent 接力连续性
-
-1. 将共享知识库视为交接契约。
-2. 接手前先读取任务状态、决策与待办。
-3. 无需重复探索，直接延续执行并保持约定与理由。
-4. 持续回写进度，确保后续会话可立即接手。
-
-### 关系维护与跟进推进
-
-1. 从用户提供的沟通纪要中抽取事实更新、意图与情绪信号。
-2. 结构化更新对应的人脉或关系记录。
-3. 生成下一步策略、待办与建议跟进时间。
-4. 以可复用格式沉淀，保证后续会话可继续执行。
-
-### 结构感知的多文件联动更新
-
-一段非结构化输入（聊天记录、会议纪要、语音转文字、随手 braindump）往往包含分属多个文件的信息。MindOS 在启动时即获取完整目录树与文档间引用关系，因此能将输入拆解后一次性路由到各个目标文件——用户无需手动指定去向。
-
-1. 通过 `mindos_bootstrap` 和 `mindos_list_files` 加载完整知识库结构与拓扑。
-2. 将输入解析为独立语义单元（事实、决策、想法、行动项、关系更新、新概念等）。
-3. 为每个单元搜索并读取候选目标文件，按主题、范围和已有结构匹配最佳归属。
-4. **写入前，先向用户展示路由计划并请求确认。** 用清晰的列表展示：每条信息将写入哪个文件、写在什么位置、为什么放在那里。确认后再执行。
-5. 在每个目标文件的正确位置（章节、标题或行级）执行最小化编辑；仅当没有合理匹配时才新建文件。
-6. 若某单元路由置信度低，先给出候选目标并请用户选择。
-7. 所有写入完成后，汇总"改了什么、在哪里"，便于用户一眼审计。
-
-这正是 MindOS 区别于"一次只能改一个文件"的工具的核心：结构先验意味着一次输入即触发跨知识库的协调更新，不遗漏、不错位。
-
-### 知识冲突联动更新
-
-当某个决策、偏好或事实发生变化（如"我们从 Redis 换成了 Memcached"），所有引用旧信息的文档都需一致更新。
-
-1. 搜索整个知识库中引用旧信息的位置（使用多种搜索词，包括缩写和变体）。
-2. 列出所有受影响文件及具体行/章节。
-3. 向用户展示完整变更计划：哪些文件、改什么、为什么。
-4. 用户确认后，逐一最小化更新。
-5. 更新完成后验证不再有不一致的旧引用。
-
-### 从经验提炼 SOP
-
-当用户刚完成一项复杂任务，想把过程沉淀为可复用的工作流时，创建结构化、通用的 SOP 文档——不只是一次性记录。
-
-1. 从用户描述中提取操作步骤、决策点、前置条件和常见坑。
-2. 泛化处理：去掉一次性细节，保留可复用模式。
-3. 在 Workflows/ 或类似目录下找合适位置，检查现有 SOP 模板或同级格式。
-4. 创建 SOP，包含：前置条件、分步操作、排障/踩坑、相关文档引用。
-5. 若适用，从相关索引文件链接到新 SOP。
-
-### 周期性回顾与总结
-
-当用户要求 weekly review、月度复盘或进度总结时：
-
-1. 用 `mindos_get_recent` 和/或 `mindos_get_history` 找出相关时间窗口内变动的文件。
-2. 读取变动文件理解发生了什么。
-3. 按领域分类（项目、Profile、工作流等）。
-4. 产出结构化总结：做了什么关键决策、活跃项目进展、待办事项、需关注的问题。
-5. 询问用户是否要将总结回写为一条 review 记录。
-
-### 基于上下文的问答
-
-当用户问自己的偏好、项目状态、存储的知识等问题时：
-
-1. 从目录树推断哪些文件可能包含答案。
-2. 读取相关文件——不凭通用知识猜测。
-3. 回答必须基于实际存储内容，并注明来源文件。
-4. 若信息不完整或缺失，明确告知，不编造。
-
-### TODO 与任务列表管理
-
-当用户要添加、完成或修改任务时：
-
-1. 定位 TODO 文件或任务列表（搜索或从目录结构导航）。
-2. 读取当前内容，理解现有格式（复选框、优先级、分类方式）。
-3. 做最小化定向修改：标记完成、添加新项、更新状态。
-4. 保留所有其他内容和格式不变。
-5. 严格遵循现有格式约定——不引入新的任务格式。
-
-### 交接文档合成
-
-当用户需要为他人（新同事、协作者、上级）生成交接或简报文档时：
-
-1. 跨知识库识别该主题的所有相关文件（项目文档、决策记录、状态、技术栈、待办）。
-2. 逐一读取提取相关信息。
-3. 合成为一份连贯的交接文档，包含：背景、关键决策与理由、当前状态、待办事项、延伸阅读（附源文件链接）。
-4. 将交接文档放在对应项目目录下，不放根目录。
-
-### 结构性重命名与移动
-
-重命名或移动文件/目录时：
-
-1. 用 `mindos_get_backlinks` 查找所有引用目标路径的文件。
-2. 向用户报告影响范围：多少文件受影响、是哪些、引用了什么。
-3. 确认后再执行。
-4. 执行重命名/移动。
-5. 更新所有受影响文件中的断裂引用。
-6. 验证无遗留的失效链接。
-
-### 目录变更后同步 README
-
-任何影响目录结构的操作（创建、删除、移动、重命名文件或子目录）完成后：
-
-1. 确定受影响的目录：文件原位置所在目录、新位置所在目录、以及它们的父目录。
-2. 读取每个受影响目录的 README（若存在）。
-3. 更新 README 中的文件列表/索引/导航，使其准确反映当前目录内容。
-4. 若 README 中有文件描述或链接，同步更新路径和名称。
-5. 若目录下没有 README 且同级目录普遍有 README，考虑为新目录创建一个。
-
-此步骤是所有结构变更操作的自动收尾动作，不需要用户单独请求。
+选择匹配的模式。所有模式共享统一纪律：搜索 → 读取 → 最小化编辑 → 验证 → 总结。
+
+### 核心模式（高频）
+
+#### 记录或更新笔记
+搜索 → 读取目标 + 局部规则 → 最小化修改 → 路径变化时保持引用一致。
+
+#### 基于上下文的问答
+从目录树推断 → 读取相关文件 → 基于存储内容回答并注明来源 → 信息缺失时明确告知。
+
+#### 结构感知的多文件联动更新
+处理非结构化输入（会议纪要、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 讨论 | 与用户确认决策 → 结构化为问题/决策/理由/下一步 → 最小化写回 |
 
 ## 交互规则
 
@@ -291,28 +171,12 @@ description: >
 - 不写入密钥、Token、密码。
 - 不执行超出用户意图的删除或覆写。
 
-## 持续评估迭代
-
-对重要工作流执行快速迭代闭环：
-
-1. 为当前任务类型定义 2-3 个代表性提示词。
-2. 依据本 Skill 运行流程。
-3. 按用户目标、局部约定与安全规则评估结果质量。
-4. 找到能避免失败模式的最小指令改动。
-5. 复跑并仅保留“提升稳定性且不过拟合”的改动。
-
 ## 质量闸门
 
-在结束前确认：
+在结束任何操作前确认：
 
 1. 结果直接回应用户意图。
 2. 新增或修改内容符合局部风格与结构。
 3. 结构调整后引用/链接仍有效。
 4. 未引入敏感信息。
 5. 给用户的总结足够具体，便于快速审计。
-
-## 风格规则
-
-- 遵循仓库局部风格。
-- 文本保持简洁、可执行。
-- 保留标题、清单、表格、引用等有效结构。