@geminilight/mindos 0.6.57 → 0.6.58

package/bin/lib/mcp-agents.js

@@ -217,6 +217,15 @@ export const MCP_AGENTS = {
     presenceCli: 'codex',
     presenceDirs: ['~/.codex/'],
   },
+  'antigravity': {
+    name: 'Antigravity',
+    project: '.antigravity/mcp_config.json',
+    global: '~/.gemini/antigravity/mcp_config.json',
+    key: 'mcpServers',
+    preferredTransport: 'stdio',
+    presenceCli: 'agy',
+    presenceDirs: ['~/.gemini/antigravity/'],
+  },
 };
 
 /**
@@ -243,6 +252,7 @@ export const SKILL_AGENT_REGISTRY = {
   'roo': { mode: 'additional', skillAgentName: 'roo' },
   'github-copilot': { mode: 'universal' },
   'codex': { mode: 'universal' },
+  'antigravity': { mode: 'additional', skillAgentName: 'antigravity' },
 };
 
 export function detectAgentPresence(agentKey) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@geminilight/mindos",
-  "version": "0.6.57",
+  "version": "0.6.58",
   "description": "MindOS — Human-Agent Collaborative Mind System. Local-first knowledge base that syncs your mind to all AI Agents via MCP.",
   "keywords": [
     "mindos",

package/skills/mindos/SKILL.md

@@ -4,12 +4,18 @@ description: >
   Operate a MindOS knowledge base: update notes, search, organize files, execute SOPs/workflows,
   retrospective, append CSV, cross-agent handoff, route unstructured input to the right files,
   distill experience, sync related docs.
-  Use when the task targets files inside the user's MindOS KB (mindRoot).
+  更新笔记, 搜索知识库, 整理文件, 执行SOP/工作流, 复盘, 追加CSV, 跨Agent交接,
+  路由非结构化输入到对应文件, 提炼经验, 同步关联文档.
   NOT for editing app source, project docs, or paths outside the KB.
   Core concepts: Space, Instruction (INSTRUCTION.md), Skill (SKILL.md); notes can embody both.
-  Trigger when user asks to: save or record a note, search their knowledge base, update or edit
-  a file, organize notes, run a workflow or SOP, capture decisions from a session, append rows
-  to a table or CSV, hand off context to another agent.
+  Trigger when user asks to: save or record anything, search for prior notes or context, update or
+  edit a file, organize notes, run a workflow or SOP, capture decisions from a session, append rows
+  to a table or CSV, hand off context to another agent, check if something was discussed before,
+  look up a past decision, distill lessons learned, prepare context for a meeting.
+  Also trigger on Chinese: 帮我记下来, 搜一下笔记, 更新知识库, 整理文件, 复盘, 提炼经验,
+  保存, 记录, 交接, 查一下之前的, 有没有相关笔记, 把这个存起来.
+  When the user's question implies stored context may exist (past decisions, previous discussions,
+  meeting records), consider searching MindOS even if they don't explicitly mention it.
 ---
 
 # MindOS Skill

package/skills/mindos-max/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: mindos-max
+description: >
+  The user's second brain — a persistent, shared knowledge base that ALL agents read from and write to.
+  MindOS is the global memory layer: decisions, meeting notes, SOPs, debugging lessons, architecture
+  choices, research findings, preferences, and conversation summaries all live here.
+
+  PROACTIVE USE — do not wait for the user to say "save to knowledge base":
+  (1) Before answering any question about past decisions, discussions, or context → search MindOS first.
+  (2) After any valuable output (decision made, bug fixed, lesson learned, meeting summarized) → offer to save it.
+  (3) When handing off to another agent or ending a session → persist key context to MindOS.
+
+  Trigger on ALL of these, even without explicit "MindOS" mention: save/record anything,
+  search prior notes, update files, organize/restructure, run SOPs or workflows, retrospective,
+  append CSV/table data, cross-agent handoff, distill experience, sync related docs, check if
+  something was discussed before, look up a past decision, find a template, prepare meeting context,
+  daily logging, track goals. Also trigger on Chinese equivalents: 帮我记下来, 搜一下笔记,
+  更新知识库, 整理文件, 复盘, 提炼经验, 保存, 记录, 交接.
+
+  When in doubt whether MindOS applies — it probably does. Check anyway.
+  NOT for editing app source code or project repos outside the KB.
+  Core concepts: Space, Instruction (INSTRUCTION.md), Skill (SKILL.md).
+---
+
+# MindOS Skill
+
+<!-- version: 3.1.0-max — aggressive global memory mode -->
+
+> **You are the user's memory.** Every agent shares MindOS. If something is worth remembering, save it.
+> If you need context, check MindOS first. Be proactive — don't wait to be asked.
+
+## Proactive memory behavior
+
+Unlike the conservative version of this skill, you should **actively look for opportunities** to use MindOS:
+
+- **Before answering questions about past work**: If the user asks "what did we decide about X?" or "how did we handle Y?", search MindOS before guessing. Even if they don't mention MindOS, their question implies stored context exists.
+- **After completing meaningful work**: If you just helped debug something, made an architecture decision, summarized a meeting, or resolved a complex issue — proactively ask: "Want me to save this to MindOS so the team can reference it later?"
+- **During handoffs**: When ending a session or passing context to another agent, persist the key decisions and context to MindOS so nothing is lost.
+- **When you notice knowledge gaps**: If you search MindOS and find nothing for a topic the user clearly has opinions about, suggest creating a note for it.
+
+The goal: the user should never have to remember to use MindOS. You remember for them.
+
+---
+
+## CLI commands
+
+Use `mindos file <subcommand>` for all knowledge base operations. Add `--json` for structured output.
+
+| Operation | Command |
+|-----------|---------|
+| List files | `mindos file list` |
+| Read file | `mindos file read <path>` |
+| Write/overwrite | `mindos file write <path> --content "..."` |
+| Create new file | `mindos file create <path> --content "..."` |
+| Append to file | `mindos file append <path> --content "..."` |
+| Edit section | `mindos file edit-section <path> -H "## Heading" --content "..."` |
+| Insert after heading | `mindos file insert-heading <path> -H "## Heading" --content "..."` |
+| Append CSV row | `mindos file append-csv <path> --row "col1,col2,col3"` |
+| Delete file | `mindos file delete <path>` |
+| Rename/move | `mindos file rename <old> <new>` |
+| Search | `mindos search "query"` |
+| Backlinks | `mindos file backlinks <path>` |
+| Recent files | `mindos file recent --limit 10` |
+| Git history | `mindos file history <path>` |
+| List spaces | `mindos space list` |
+| Create space | `mindos space create "name"` |
+
+> **MCP users:** If you only have MCP tools (`mindos_*`), use them directly — they are self-describing via their schemas. Prefer CLI when available (lower token cost).
+
+### CLI setup
+
+```bash
+npm install -g @geminilight/mindos
+# Remote mode: mindos config set url http://<IP>:<PORT> && mindos config set authToken <token>
+```
+
+---
+
+## Rules
+
+1. **Bootstrap first** — list the KB tree to understand structure before searching or writing.
+2. **Default to read-only.** Only write when the user explicitly asks to save, record, organize, or edit. Lookup / summarize / quote = no writes.
+3. **Rule precedence** (highest wins): user's current-turn instruction > `.mindos/user-preferences.md` > nearest directory `INSTRUCTION.md` > root `INSTRUCTION.md` > this SKILL's defaults.
+4. **Multi-file edits require a plan first.** Present the full change list; execute only after approval.
+5. After create/delete/move/rename > **sync affected READMEs** automatically.
+6. **Read before write.** Always read a file before overwriting it. Never write based on assumptions.
+
+---
+
+## NEVER do (hard-won pitfalls)
+
+- **NEVER write to the KB root** unless explicitly told. Root is for governance files only. New content goes under the most fitting subdirectory.
+- **NEVER assume directory names.** Infer from the actual bootstrap tree — the KB may use Chinese names or flat layout.
+- **NEVER use full-file overwrite for a small edit.** Use `mindos file edit-section` or `mindos file insert-heading` for targeted changes. Full rewrites destroy git diffs.
+- **NEVER search with a single keyword.** Fire 2-4 parallel searches (synonyms, abbreviations, Chinese/English variants).
+- **NEVER modify `INSTRUCTION.md` or `README.md` without confirmation.** Governance docs — treat as high-sensitivity.
+- **NEVER create a file without checking siblings.** Read 1-2 files in the target directory to learn local style.
+- **NEVER leave orphan references.** After rename/move, check backlinks and update every referring file.
+- **NEVER skip routing confirmation for multi-file writes.** The user's mental model may differ from yours.
+
+---
+
+## MindOS concepts
+
+- **Space** — Knowledge partitions organized the way you think. Agents follow the same structure.
+- **Instruction** — A rules file (`INSTRUCTION.md`) all connected agents obey.
+- **Skill** — Teaches agents how to read, write, and organize the KB.
+
+Notes can embody both Instruction and Skill — they're just Markdown files in the tree.
+
+---
+
+## Decision tree
+
+```
+User request
+  |
+  |- Lookup / summarize / quote?
+  |   -> [Read-only]: search -> read -> answer with citations. No writes.
+  |
+  |- Save / record / update / organize specific content?
+  |   |- Single file -> [Single-file edit]
+  |   -> Multiple files or unclear -> [Multi-file routing] -- plan first
+  |
+  |- Structural change (rename / move / delete / reorganize)?
+  |   -> [Structural path] -- check backlinks before and after
+  |
+  |- Procedural / repeatable task?
+  |   -> [SOP path] -- find and follow existing SOP, or create one
+  |
+  |- Retrospective / distill / handoff?
+  |   -> [Retrospective path]
+  |
+  -> Ambiguous?
+      -> ASK. Propose 2-3 specific options based on KB state.
+```
+
+---
+
+## Judgment heuristics
+
+**Save intent boundary:**
+- "save this" / "record" / "write down" = write
+- "search" / "summarize" / "look up" = read-only
+- "organize" -> ask: display only, or write back?
+
+**File location uncertainty:**
+- Can't decide in 5 seconds -> use nearest existing directory, inform user
+- "Just put it somewhere" -> inbox, propose classification after
+
+**Scope creep:**
+- Input routes to >5 files -> pause, confirm scope
+- "Update all of these" spanning multiple topics -> split into batches
+
+**Citation:** KB-cited facts must include the file path.
+
+---
+
+## Post-task hooks
+
+After write tasks (not simple reads), scan this table. At most 1 proposal; highest priority wins. Check `.mindos/user-preferences.md` suppression first.
+
+| Hook | Priority | Condition |
+|------|----------|-----------|
+| Experience capture | high | Debugging, troubleshooting, or multi-round work |
+| Consistency sync | high | Edited file with backlinks |
+| SOP drift | medium | Followed SOP but diverged |
+| Linked update | medium | Changed CSV/TODO status with related docs |
+| Structure classification | medium | Created file in inbox/temp location |
+| Pattern extraction | low | 3+ similar operations this session |
+
+If a hook triggers -> read [references/post-task-hooks.md](../mindos/references/post-task-hooks.md).
+
+## Preference capture
+
+When user expresses a standing preference -> read [references/preference-capture.md](../mindos/references/preference-capture.md) and follow confirm-then-write flow.
+
+## SOP authoring
+
+When creating/rewriting an SOP -> read [references/sop-template.md](../mindos/references/sop-template.md).
+
+---
+
+## Error handling (CLI)
+
+```bash
+"command not found: mindos"  -> npm install -g @geminilight/mindos
+"Mind root not configured"   -> mindos onboard
+"401 Unauthorized"           -> Check AUTH_TOKEN: mindos token (on server)
+"ECONNREFUSED"               -> Start server: mindos start
+```

package/skills/mindos-max-workspace/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "mindos-max",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "我昨天跟产品经理开会讨论了一个新的用户反馈系统的方案，他们建议用NPS打分加上开放式评论，我觉得挺好的。帮我把这个决策记下来，以后其他同事问起来可以查到。",
+      "expected_output": "Agent should recognize this as a 'save decision from meeting' task, use MindOS to store the meeting note with proper structure (date, attendees implied, decision, rationale), and place it in an appropriate directory in the KB.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "上周我记得我们讨论过API限流的方案，具体是怎么定的来着？好像是每分钟100次还是200次？我找不到了。",
+      "expected_output": "Agent should recognize this as a 'search for past decision' task, use MindOS search to find the API rate limiting discussion, and return the relevant content with file path citation.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "I just finished debugging a really tricky race condition in our payment service - turns out the mutex wasn't being released properly in the error path. Took me 3 hours to figure out. I want to make sure the team doesn't hit this again.",
+      "expected_output": "Agent should recognize this as 'capture debugging experience/lessons learned', use MindOS to save a structured troubleshooting note with problem description, root cause, solution, and prevention tips.",
+      "files": []
+    }
+  ]
+}

package/skills/mindos-max-workspace/iteration-1/capture-debugging-experience-en/eval_metadata.json

@@ -0,0 +1,11 @@
+{
+  "eval_id": 3,
+  "eval_name": "capture-debugging-experience-en",
+  "prompt": "I just finished debugging a really tricky race condition in our payment service - turns out the mutex wasn't being released properly in the error path. Took me 3 hours to figure out. I want to make sure the team doesn't hit this again.",
+  "assertions": [
+    {"text": "Uses mindos CLI to save debugging experience note", "type": "behavioral"},
+    {"text": "Structured note includes: problem description, root cause, solution, prevention tips", "type": "content"},
+    {"text": "Bootstraps KB tree before writing", "type": "behavioral"},
+    {"text": "Recognizes this as experience capture / lessons learned scenario", "type": "behavioral"}
+  ]
+}

package/skills/mindos-max-workspace/iteration-1/capture-debugging-experience-en/old_skill/grading.json

@@ -0,0 +1,28 @@
+{
+  "eval_id": 3,
+  "eval_name": "capture-debugging-experience-en",
+  "run_type": "old_skill",
+  "skill": "mindos-original",
+  "expectations": [
+    {
+      "text": "Uses mindos CLI to save debugging experience note",
+      "passed": true,
+      "evidence": "Uses `mindos file insert-heading \"engineering/debugging-experiences.md\"` in Step 5 — chose to append to existing file rather than create new."
+    },
+    {
+      "text": "Structured note includes: problem description, root cause, solution, prevention tips",
+      "passed": true,
+      "evidence": "Content has Problem, Root Cause, Solution, Rule (with code review checklist), Debugging Approach, Tags sections."
+    },
+    {
+      "text": "Bootstraps KB tree before writing",
+      "passed": true,
+      "evidence": "Step 1 runs `mindos file list`."
+    },
+    {
+      "text": "Recognizes this as experience capture / lessons learned scenario",
+      "passed": true,
+      "evidence": "Decision tree analysis identifies 'save / record' path and Experience capture hook (high priority)."
+    }
+  ]
+}

package/skills/mindos-max-workspace/iteration-1/capture-debugging-experience-en/old_skill/outputs/transcript.md

@@ -0,0 +1,203 @@
+# Transcript: Capturing Debugging Experience — Payment Service Race Condition
+
+## User Input
+
+> I just finished debugging a really tricky race condition in our payment service - turns out the mutex wasn't being released properly in the error path. Took me 3 hours to figure out. I want to make sure the team doesn't hit this again.
+
+---
+
+## Skill Analysis
+
+### Decision Tree Path
+
+Following the SKILL.md decision tree:
+
+- **Is this a lookup / summarize / quote?** → No.
+- **Is this a save / record / update / organize?** → **Yes.** The user explicitly says "I want to make sure the team doesn't hit this again" — this is a request to record/save experience.
+- This is a **single-file edit** (or creation) — the debugging experience needs to be captured somewhere in the KB.
+
+### Post-Task Hook Triggered
+
+The "Experience capture" hook (priority: high) applies because this is **debugging / troubleshooting** work. Per the hook template:
+
+> "Record this experience to {related experience file}?" — Format: problem → cause → solution → rule
+
+---
+
+## Simulated Execution Plan
+
+### Step 1: Bootstrap — List the KB tree
+
+```bash
+mindos file list
+```
+
+**Purpose:** Understand the KB structure before deciding where to save. Per Rule 1: "Bootstrap first — list the KB tree to understand structure before searching or writing."
+
+**Expected output (hypothetical):**
+
+```
+/
+├── projects/
+│   ├── payment-service/
+│   │   ├── README.md
+│   │   ├── architecture.md
+│   │   └── troubleshooting.md
+│   └── ...
+├── engineering/
+│   ├── debugging-experiences.md
+│   ├── best-practices.md
+│   └── ...
+├── inbox/
+└── INSTRUCTION.md
+```
+
+### Step 2: Search for related files
+
+Per the NEVER rule: "NEVER search with a single keyword. Fire 2-4 parallel searches."
+
+```bash
+mindos search "race condition"
+mindos search "mutex debugging"
+mindos search "payment service"
+mindos search "concurrency bug"
+```
+
+**Purpose:** Find if there's already a debugging experience file, a payment service section, or an existing concurrency-related note to append to rather than creating a duplicate.
+
+### Step 3: Read existing files in the target directory
+
+Per the NEVER rule: "NEVER create a file without checking siblings. Read 1-2 files in the target directory to learn local style."
+
+Assuming the search found a relevant directory (e.g., `engineering/` or `projects/payment-service/`), read sibling files:
+
+```bash
+mindos file read "engineering/debugging-experiences.md"
+```
+
+**Purpose:** Learn the local style and format so the new entry matches existing conventions.
+
+### Step 4: Determine save location
+
+**If** a file like `engineering/debugging-experiences.md` or `projects/payment-service/troubleshooting.md` already exists:
+→ Append to it using `insert-heading` or `append`.
+
+**If** no suitable file exists:
+→ Create a new file in the most fitting subdirectory.
+
+For this simulation, I'll assume an existing `engineering/debugging-experiences.md` exists and already has entries.
+
+### Step 5: Write the experience entry
+
+Using the experience capture format from the post-task hook: **problem → cause → solution → rule**.
+
+```bash
+mindos file insert-heading "engineering/debugging-experiences.md" \
+  -H "## Experiences" \
+  --content "### Payment Service Race Condition — Mutex Not Released in Error Path
+
+**Date:** 2026-04-07
+**Time spent:** ~3 hours
+**Severity:** High (potential payment inconsistency)
+
+#### Problem
+The payment service intermittently hung under concurrent requests. Transactions would stall and eventually time out, but only under load — never reproducible with a single request.
+
+#### Root Cause
+The mutex guarding the payment transaction critical section was acquired at the start of the handler but was **not released in the error path**. When an error occurred (e.g., validation failure, downstream timeout), the function returned early without calling \`mutex.Unlock()\` (or equivalent release). Subsequent requests waiting on the same mutex would block indefinitely.
+
+Specifically:
+- The happy path correctly released the mutex via \`defer\` or explicit unlock at the end.
+- An early-return error branch added later bypassed the unlock.
+- Under normal load, errors were rare enough that the mutex was eventually released by other mechanisms (process restart, timeout). Under high load, the probability of hitting the error path increased, causing cascading stalls.
+
+#### Solution
+1. Ensured the mutex release is handled via \`defer mutex.Unlock()\` immediately after acquisition — guaranteeing release regardless of which code path executes.
+2. Audited all other critical sections in the payment service for the same pattern.
+3. Added a unit test that forces an error after mutex acquisition and verifies the mutex is released.
+
+#### Rule (for the team)
+> **Always use defer (or try-finally / RAII) to release locks immediately after acquisition.** Never rely on explicit unlock calls scattered across multiple return paths. If your language supports it, the lock-release pair should be on adjacent lines:
+>
+> \`\`\`go
+> mu.Lock()
+> defer mu.Unlock()
+> \`\`\`
+>
+> **Code review checklist item:** When reviewing any function that acquires a lock, verify that every return path (including error returns and panics) releases it. Search for early returns between Lock() and Unlock().
+
+#### Debugging Approach (what made it hard)
+- The bug was intermittent — only triggered under concurrent load when an error happened.
+- Initial investigation focused on network timeouts (wrong direction).
+- Breakthrough: added lock-acquisition logging with timestamps, which showed a lock was held for >30s — way beyond any normal transaction time.
+- Narrowed to the specific error path by correlating the held-lock timestamp with error logs.
+
+**Tags:** #concurrency #mutex #race-condition #payment-service #debugging"
+```
+
+### Step 6: Verify the write
+
+```bash
+mindos file read "engineering/debugging-experiences.md"
+```
+
+**Purpose:** Confirm the entry was appended correctly and the file is well-formed.
+
+### Step 7: Check backlinks and related files
+
+```bash
+mindos file backlinks "engineering/debugging-experiences.md"
+```
+
+If the payment service has its own troubleshooting doc, consider adding a cross-reference:
+
+```bash
+mindos file insert-heading "projects/payment-service/troubleshooting.md" \
+  -H "## Known Issues" \
+  --content "- **Mutex release in error paths** — See [[engineering/debugging-experiences.md#Payment Service Race Condition]] for full write-up. Rule: always use defer/finally for lock release."
+```
+
+### Step 8: Post-task hook evaluation
+
+After the write, scan the post-task hooks table:
+
+| Hook | Triggered? | Action |
+|------|-----------|--------|
+| Experience capture | ✅ Already handled | This was the primary task |
+| Consistency sync | Maybe | If backlinks exist to the edited file, propose sync |
+| SOP drift | No | No SOP was followed |
+| Linked update | Maybe | If a concurrency best-practices doc exists, propose update |
+| Structure classification | No | File was placed in an existing directory |
+| Pattern extraction | No | Single operation |
+
+**Proposal to user (if applicable):**
+
+> "Your engineering/best-practices.md has a concurrency section — add this mutex rule there too?"
+
+---
+
+## Summary of Commands (in order)
+
+| # | Command | Purpose |
+|---|---------|---------|
+| 1 | `mindos file list` | Bootstrap: understand KB structure |
+| 2 | `mindos search "race condition"` | Find related files (search 1/4) |
+| 3 | `mindos search "mutex debugging"` | Find related files (search 2/4) |
+| 4 | `mindos search "payment service"` | Find related files (search 3/4) |
+| 5 | `mindos search "concurrency bug"` | Find related files (search 4/4) |
+| 6 | `mindos file read "engineering/debugging-experiences.md"` | Read target file to learn style |
+| 7 | `mindos file insert-heading "engineering/debugging-experiences.md" -H "## Experiences" --content "..."` | Write the experience entry |
+| 8 | `mindos file read "engineering/debugging-experiences.md"` | Verify write succeeded |
+| 9 | `mindos file backlinks "engineering/debugging-experiences.md"` | Check for files that reference this one |
+| 10 | `mindos file insert-heading "projects/payment-service/troubleshooting.md" -H "## Known Issues" --content "..."` | Cross-reference in project-specific doc |
+
+## Content Written
+
+The experience entry follows the **problem → cause → solution → rule** format prescribed by the post-task hook, and includes:
+
+- **Problem**: Observable symptoms (intermittent hangs under load)
+- **Root Cause**: Mutex not released in error path due to early return
+- **Solution**: Use `defer` for lock release + audit + add test
+- **Rule**: Actionable team guideline with code review checklist item
+- **Debugging Approach**: What made it hard and what the breakthrough was (useful for future investigators)
+- **Tags**: For searchability within the KB

package/skills/mindos-max-workspace/iteration-1/capture-debugging-experience-en/with_skill/grading.json

@@ -0,0 +1,28 @@
+{
+  "eval_id": 3,
+  "eval_name": "capture-debugging-experience-en",
+  "run_type": "with_skill",
+  "skill": "mindos-max",
+  "expectations": [
+    {
+      "text": "Uses mindos CLI to save debugging experience note",
+      "passed": true,
+      "evidence": "Uses `mindos file create \"engineering/debugging/payment-service-mutex-race-condition.md\"` in Step 5."
+    },
+    {
+      "text": "Structured note includes: problem description, root cause, solution, prevention tips",
+      "passed": true,
+      "evidence": "Content has Problem, Symptoms, Root Cause, Solution, Prevention Rules (4 rules), Debugging Approach, Related Patterns, Tags sections."
+    },
+    {
+      "text": "Bootstraps KB tree before writing",
+      "passed": true,
+      "evidence": "Step 2 runs `mindos file list`."
+    },
+    {
+      "text": "Recognizes this as experience capture / lessons learned scenario",
+      "passed": true,
+      "evidence": "Step 1 maps to 'Retrospective / distill' in decision tree and identifies Experience capture post-task hook."
+    }
+  ]
+}