@geminilight/mindos 0.5.41 → 0.5.42

package/skills/mindos/SKILL.md

@@ -20,7 +20,7 @@ context automatically when present. User rules override default rules on conflic
 
 ---
 
-<!-- version: 1.0.0 -->
+<!-- version: 1.1.0 -->
 # MindOS Operating Rules
 
 ## Core Principles
@@ -47,7 +47,13 @@ Run this sequence before substantive edits:
 - Read nearby `README.md` / `INSTRUCTION.md` when present.
 - Follow local conventions over global assumptions.
 
-4. Execute edits.
+4. Match existing SOPs.
+- If the task is procedural (multi-step, repeatable, or matches a known workflow category):
+  search Workflows/ directory with `mindos_search_notes(scope: "Workflows/")` using task keywords.
+- If a matching SOP is found, read it and follow its steps (adapting as needed).
+- If the SOP's steps diverge from actual execution, propose updating the SOP after task completion.
+
+5. Execute edits.
 
 If required context is missing, continue with best effort and state assumptions explicitly.
 
@@ -135,7 +141,39 @@ Before finishing any operation, verify:
 
 ## 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 `user-skill-rules.md` in the knowledge base root under the appropriate section. Confirm to the user: "Preference recorded."
+### When to capture
+The user expresses a preference correction (e.g., "don't do X", "next time remember to...", "this should go in... not in...").
+
+### Confirm-then-write flow
+1. **First occurrence of a new preference**: propose the rule and target file before writing.
+   - "Record this preference to `user-skill-rules.md`? Rule: _{summary}_"
+   - Write only after user confirms.
+2. **Repeated confirmation on similar category**: after the user confirms the same category of preference 3+ times, auto-write future rules in that category without asking. Add an `auto-confirm: true` flag to the category header in `user-skill-rules.md`.
+3. **User explicitly grants blanket permission** (e.g., "just record preferences directly"): set a top-level `auto-confirm-all: true` flag and skip confirmation for all future captures.
+
+### File location
+- Target: `user-skill-rules.md` in the knowledge base root (read by `mindos_bootstrap` automatically).
+- If the file does not exist, create it with the template below on first confirmed write.
+
+### File template
+```markdown
+# User Skill Rules
+<!-- auto-confirm-all: false -->
+
+## Preferences
+<!-- Group by category. Mark auto-confirm: true on categories confirmed 3+ times. -->
+
+## Suppressed Hooks
+<!-- List post-task hooks the user has opted out of. -->
+```
+
+### Rule format
+Each rule is a bullet under its category:
+```markdown
+### {Category}
+<!-- auto-confirm: false -->
+- {Rule description} — _{date captured}_
+```
 
 ---
 
@@ -179,7 +217,7 @@ For unstructured inputs (meeting notes, braindumps, chat exports) that belong in
 | 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 |
+| Distill experience into SOP | Extract procedure → generalize → create under Workflows/ using the **SOP template** (see below) with keywords metadata, scenarios, branching steps, exit conditions, and 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 |
@@ -188,6 +226,37 @@ For unstructured inputs (meeting notes, braindumps, chat exports) that belong in
 | 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 |
 
+### SOP Template
+
+When creating a new SOP via "Distill experience into SOP", the file **must** follow this structure:
+
+```markdown
+# SOP: {Title}
+<!-- keywords: {3-5 trigger keywords, English and Chinese} -->
+<!-- last-used: {ISO date} -->
+<!-- created: {ISO date} -->
+
+## Applicable Scenarios
+When to use this SOP. List trigger conditions and prerequisites.
+
+## Steps
+Each step includes:
+1. **Action** — concrete operation
+2. **Branch** — if X do A, if Y do B (mark "none" if no branching)
+3. **Failure handling** — what can go wrong and how to respond
+
+## Exit Conditions
+When is the task complete. When to abort or escalate.
+
+## Pitfall Log
+Known edge cases and lessons learned. Append new entries each time the SOP is executed and a new issue is encountered.
+```
+
+Metadata rules:
+- `keywords` — used by SOP recall search in Startup Protocol step 4. Include both English and Chinese terms.
+- `last-used` — update to today's date each time the SOP is followed.
+- `created` — set once at creation time.
+
 ## 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.
@@ -230,6 +299,11 @@ After completing a task, check the conditions below. If one matches, make a one-
 - Condition: 3+ structurally similar operations in the current session.
 - Propose: "This operation repeated multiple times — create an SOP?"
 
+### SOP drift (priority: medium)
+- Condition: task was executed following an existing SOP, but actual steps diverged from documented steps.
+- Propose: "Execution diverged from {SOP file} — update the SOP?"
+- Action: update divergent steps, append new pitfalls, set `<!-- last-used: -->` to today.
+
 ### 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?"

package/skills/mindos-zh/SKILL.md

@@ -18,7 +18,7 @@ description: >
 
 ---
 
-<!-- version: 1.0.0 -->
+<!-- version: 1.1.0 -->
 # MindOS 操作规则
 
 ## 核心原则
@@ -45,7 +45,13 @@ description: >
 - 若存在，读取就近 `README.md` / `INSTRUCTION.md`。
 - 优先遵循局部约定，而非全局假设。
 
-4. 再执行编辑。
+4. 匹配已有 SOP。
+- 若任务是流程性的（多步骤、可重复、或匹配已知工作流类别）：
+  用任务关键词搜索 Workflows/ 目录 `mindos_search_notes(scope: "Workflows/")`。
+- 若找到匹配的 SOP，读取并按其步骤执行（按需调整）。
+- 若 SOP 步骤与实际执行产生偏差，任务完成后提议更新该 SOP。
+
+5. 再执行编辑。
 
 若关键上下文缺失，按最佳努力继续，并明确写出假设。
 
@@ -133,7 +139,39 @@ description: >
 
 ## 偏好捕获
 
-当用户在操作过程中表达偏好修正（如"以后不要…""下次记得…""这个应该放在…而不是…"），将偏好以结构化规则追加到知识库根目录的 `user-skill-rules.md` 的对应分区。追加后告知用户"已记录偏好"。
+### 何时捕获
+用户在操作过程中表达偏好修正（如"以后不要…""下次记得…""这个应该放在…而不是…"）。
+
+### 确认后写入流程
+1. **某类偏好首次出现**：先提议，用户确认后再写入。
+   - "记录此偏好到 `user-skill-rules.md`？规则：_{摘要}_"
+   - 仅在用户确认后写入。
+2. **同类偏好确认 3 次以上**：该类别标记 `auto-confirm: true`，后续同类偏好自动写入，不再询问。
+3. **用户明确授权**（如"偏好直接记就行"）：设置顶层 `auto-confirm-all: true`，所有偏好跳过确认直接写入。
+
+### 文件位置
+- 目标：知识库根目录的 `user-skill-rules.md`（`mindos_bootstrap` 启动时自动读取）。
+- 若文件不存在，在首次确认写入时按以下模板创建。
+
+### 文件模板
+```markdown
+# User Skill Rules
+<!-- auto-confirm-all: false -->
+
+## Preferences
+<!-- 按类别分组。确认 3 次以上的类别标记 auto-confirm: true。 -->
+
+## Suppressed Hooks
+<!-- 列出用户已关闭的 Post-Task Hooks。 -->
+```
+
+### 规则格式
+每条规则以列表项写在对应类别下：
+```markdown
+### {类别名}
+<!-- auto-confirm: false -->
+- {规则描述} — _{记录日期}_
+```
 
 ---
 
@@ -177,7 +215,7 @@ description: >
 | SOP/工作流执行 | 完整读取 → 分步执行 → 仅更新过时章节 |
 | 跨 Agent 接力 | 读任务状态+决策 → 无需重复探索直接接续 → 回写进度 |
 | 知识冲突联动 | 多关键词搜索旧信息 → 列出受影响文件 → 展示变更计划 → 确认后更新 |
-| 经验提炼 SOP | 提取步骤 → 泛化 → 在 Workflows/ 下创建含前置条件、步骤、踩坑的 SOP |
+| 经验提炼 SOP | 提取步骤 → 泛化 → 在 Workflows/ 下按 **SOP 模板**（见下方）创建，包含关键词元数据、适用场景、分支步骤、退出条件和踩坑记录 |
 | 周期性回顾 | `get_recent`/`get_history` → 读变动文件 → 分类 → 结构化总结 |
 | 交接文档合成 | 识别来源 → 读取 → 合成（背景、决策、状态、待办）→ 放项目目录 |
 | 关系维护与跟进 | 从纪要提取更新 → 更新联系人记录 → 生成跟进策略 |
@@ -186,6 +224,37 @@ description: >
 | 代码审查 | 读审查规范 → 检查命名/安全/性能 → 输出可执行建议 |
 | 沉淀跨 Agent 讨论 | 与用户确认决策 → 结构化为问题/决策/理由/下一步 → 最小化写回 |
 
+### SOP 模板
+
+通过"经验提炼 SOP"创建新 SOP 时，文件**必须**遵循以下结构：
+
+```markdown
+# SOP: {标题}
+<!-- keywords: {3-5 个触发关键词，中英文} -->
+<!-- last-used: {ISO date} -->
+<!-- created: {ISO date} -->
+
+## 适用场景
+什么情况下该用这个 SOP。列出触发条件和前置依赖。
+
+## 步骤
+每步包含：
+1. **做什么** — 具体操作
+2. **判断分支** — 遇到 X 走 A，遇到 Y 走 B（无分支则标注"无"）
+3. **失败处理** — 这步可能失败的情况和应对
+
+## 退出条件
+什么时候算完成，什么时候该放弃或升级。
+
+## 踩坑记录
+已知的边界 case 和教训。每次执行遇到新坑时追加。
+```
+
+元数据规则：
+- `keywords` — 供启动协议步骤 4 的 SOP 召回搜索使用。同时包含中英文关键词。
+- `last-used` — 每次按 SOP 执行后更新为当天日期。
+- `created` — 创建时设置一次。
+
 ## 交互规则
 
 - **当请求模糊或范围过大时（如"帮我整理一下"），先问清楚再动手。** 基于知识库现状（近期变动、目录结构）提出具体选项，但不要在理解用户意图和范围之前就开始重组或重写。
@@ -228,6 +297,11 @@ description: >
 - 条件：当前会话中 3+ 次结构相似的操作
 - 提议："这个操作重复了多次，要整理成 SOP 吗？"
 
+### SOP 偏差（优先级：中）
+- 条件：任务按已有 SOP 执行，但实际步骤与文档步骤产生偏差
+- 提议："执行过程与 {SOP 文件} 有偏差，要更新这个 SOP 吗？"
+- 动作：更新偏差步骤、追加新踩坑记录、将 `<!-- last-used: -->` 设为今天。
+
 ### 对话复盘（优先级：低）
 - 条件：会话 >10 轮且涉及决策、权衡或经验教训
 - 提议："这段对话有些决策值得沉淀，要做个复盘吗？"

package/templates/en//360/237/223/235 Notes/Drafts/README.md"

@@ -0,0 +1,8 @@
+# Drafts
+
+Work-in-progress notes that are not ready to share or publish.
+
+## Usage
+
+- Store unfinished writing, incomplete ideas, or content pending revision.
+- When ready, move to the appropriate folder or finalize for sharing.

package/templates/en//360/237/223/235 Notes/README.md"

@@ -9,6 +9,7 @@ Quick capture and lightweight notes.
 ├── README.md
 ├── INSTRUCTION.md
 ├── Inbox/
+├── Drafts/
 ├── Waiting/
 ├── Meetings/
 └── Ideas/
@@ -17,6 +18,7 @@ Quick capture and lightweight notes.
 ## Usage
 
 - `Inbox/`: quick capture for unprocessed notes.
+- `Drafts/`: work-in-progress content not yet ready to share or publish.
 - `Waiting/`: items blocked by external dependency or feedback.
 - `Meetings/`: meeting notes, decisions, and action items.
 - `Ideas/`: idea pool for product concepts, topics, and experiments.

package/templates/zh//360/237/223/235 /347/254/224/350/256/260/README.md"

@@ -9,6 +9,7 @@
 ├── README.md
 ├── INSTRUCTION.md
 ├── 收件箱/
+├── 草稿/
 ├── 待反馈/
 ├── 会议/
 └── 想法/
@@ -17,6 +18,7 @@
 ## 💡 使用说明
 
 - `收件箱/`：临时速记入口，未整理内容先落这里。
+- `草稿/`：未完成、尚未准备好分享或发布的内容。
 - `待反馈/`：需要他人反馈或外部依赖的事项。
 - `会议/`：会议纪要、决策点与行动项。
 - `想法/`：灵感池，沉淀产品点子、选题与实验想法。

package/templates/zh//360/237/223/235 /347/254/224/350/256/260//350/215/211/347/250/277/README.md"

@@ -0,0 +1,8 @@
+# 草稿
+
+存放未完成、尚未准备好分享或发布的内容。
+
+## 使用说明
+
+- 用于保存未写完的文章、不成熟的想法或待修改的内容。
+- 完稿后迁移到对应目录，或整理后对外分享。