omni-context-cli 0.0.85 → 0.0.87

package/README.md

@@ -14,13 +14,14 @@ Every token matters. OmniContext CLI is engineered from the ground up to squeeze
 
 ## Workflow System
 
-A workflow controls everything about how OmniContext CLI behaves: the system prompt, which tools are available, and how the assistant interacts with you. Four workflows ship built-in:
+A workflow controls everything about how OmniContext CLI behaves: the system prompt, which tools are available, and how the assistant interacts with you. Five workflows ship built-in:
 
 | Preset | Use Case | Description |
 |--------|----------|-------------|
 | **Programming** (default) | Terminal, VS Code | Coding assistant with base tools, agent tools, and MCP integration. Concise output, minimal overhead. |
 | **General** | Office, desktop | Personal assistant for documents, spreadsheets, and presentations. Proactive with tools, conversational tone. |
 | **Analytics** | Usage analysis | Query the local request analytics database to explore token usage, costs, latency, and model comparison. |
+| **Memory** | Key point management | Browse, edit, and clean up cross-session key points stored in the project memory. |
 | **Recall** | Session search | Search and review past chat sessions for decisions, context, and discussion history. |
 
 The desktop app also installs a **Browser** workflow for the Chrome sidebar, with tab, page content, bookmark, history, screenshot, and script execution access. It also installs a **Memo** workflow for reminders and notifications.
@@ -76,7 +77,7 @@ Memory extraction runs automatically when a conversation is compacted. The model
 | Neutral | -1 |
 | Harmful | -6 |
 
-Points that drop below -10 are pruned. This means good insights accumulate weight over multiple sessions while bad advice is flushed quickly and stale knowledge decays on its own. Every project keeps its memory in `~/.omx/projects/<project-id>/memory.json`. Edit it directly for full control.
+Points that reach -10 or lower are pruned. This means good insights accumulate weight over multiple sessions while bad advice is flushed quickly and stale knowledge decays on its own. Every project keeps its memory in `~/.omx/projects/<project-id>/memory.json`. Edit it directly for full control.
 
 ## Desktop & Integrations
 
@@ -86,7 +87,6 @@ Terminal is home base, but OmniContext CLI extends into every tool you use. The
 - **VS Code Extension** - IDE integration with file context, diagnostics, and diff views
 - **Chrome Extension** - sidebar on any webpage for summarization, data extraction, and browser automation
 - **Office Add-in** - AI panel inside Word, Excel, and PowerPoint
-- **ACP Clients** - external agent integration via Agent Client Protocol over stdio
 - **Web Client** - browser UI with LaTeX, Mermaid diagrams, file attachments, and drag-and-drop
 - **Mobile Access** - run `omx --serve` and connect from your phone
 

package/README.zh-CN.md

@@ -14,13 +14,14 @@
 
 ## 工作流系统
 
-工作流控制 OmniContext CLI 行为的方方面面：系统提示词、可用工具列表、助手交互方式。内置四套工作流：
+工作流控制 OmniContext CLI 行为的方方面面：系统提示词、可用工具列表、助手交互方式。内置五套工作流：
 
 | 预设 | 使用场景 | 说明 |
 |------|----------|------|
 | **Programming**（默认） | 终端、VS Code | 编程助手，包含基础工具、Agent 工具和 MCP 集成。简洁输出，最小开销。 |
 | **General** | Office、桌面端 | 多功能个人助理，处理文档、表格和演示文稿。主动使用工具，匹配对话语气。 |
 | **Analytics** | 使用分析 | 查询本地请求分析数据库，探索 token 用量、成本、延迟和模型对比。 |
+| **Memory** | 要点管理 | 浏览、编辑和清理项目记忆中的跨会话关键要点。 |
 | **Recall** | 会话搜索 | 搜索和回顾过去的聊天会话，查找决策、上下文和讨论历史。 |
 
 桌面应用还会安装 **Browser** 工作流供 Chrome 侧边栏使用，可访问标签页、页面内容、书签、历史记录、截图和脚本执行能力。它也会安装 **Memo** 工作流用于提醒和通知。
@@ -86,7 +87,6 @@ omx --remove-provider openrouter
 - **VS Code 扩展** - IDE 集成，感知打开文件、诊断信息和 diff 视图
 - **Chrome 扩展** - 任意网页上的侧边栏，支持摘要、数据提取和浏览器自动化
 - **Office 插件** - Word、Excel 和 PowerPoint 内的 AI 面板
-- **ACP 客户端** - 通过 Agent Client Protocol over stdio 作为外部代理接入
 - **Web 客户端** - 浏览器 UI，支持 LaTeX、Mermaid 图表、文件附件和拖拽
 - **移动端访问** - 运行 `omx --serve` 后从手机连接
 

package/dist/agents/deduce.md

@@ -14,13 +14,9 @@ parameters:
   required: [question]
 ---
 
-Investigate this question: {{question}}
+Investigate this question: {{question}}. {{#if hints}}Use these hints as starting clues: {{hints}}.{{/if}}
 
-{{#if hints}}Known hints: {{hints}}.{{/if}}
-
-Do not modify any files. Bash is allowed for read-only commands like ls, cat, git log, git diff, git blame.
-
-Spend multiple rounds reading, searching, and tracing. Form hypotheses, gather evidence, rule out alternatives, and land on a root cause. Cite file:line for every claim. If something cannot be proven, say where the trail went cold.
+Do not modify files. Use read-only exploration only. Bash is allowed for read-only inspection such as `ls`, `cat`, `git log`, `git diff`, and `git blame`. Work in multiple rounds. Form hypotheses, trace code paths, gather evidence, and rule out alternatives before landing on a conclusion. Cite file:line for every material claim. If something cannot be proven from the code or available evidence, say where the trail went cold instead of overstating confidence.
 
 Return the results in this format:
 

package/dist/agents/explore.md

@@ -10,30 +10,25 @@ parameters:
       description: Directory to explore. If not provided, explores the entire project.
 ---
 
-Survey the project structure.
+Survey the project or directory at a high level. {{#if directory}}Keep the exploration inside this directory: {{directory}}.{{/if}}
 
-{{#if directory}}Limit the exploration to this directory: {{directory}}.{{/if}}
-
-Use glob to map out the directory tree. Start broad, then selectively read key files (READMEs, configs, entry points) to understand their roles.
-
-Focus on the big picture: what directories exist, how the project is organized, where different concerns are separated. Don't dive deep into implementation details.
+Start broad. Use Glob to map the tree, then read a small set of anchor files such as READMEs, package files, configs, and obvious entry points. Focus on what exists, how the project is organized, and where the main concerns live. Do not drift into detailed implementation analysis. If the structure is large, prefer representative directories and key files over exhaustive reading. Use Bash only when the other tools would be awkward for a simple read-only inspection.
 
 Return the results in this format:
 
 ```
-Overview: One-paragraph summary of the project and its tech stack.
+Overview: One short paragraph summarizing the project, stack, and overall shape.
 
 Directory Structure:
-  src/          - Source code, organized by feature
-  tests/        - Test suites
-  scripts/      - Build and deployment scripts
+  path/  - What lives here
+  path/  - What lives here
 
 Key Files:
-  package.json  - Dependencies and scripts
-  src/index.ts  - Application entry point
+  path/to/file - Why it matters
+  path/to/file - Why it matters
 
 Architecture:
-  How the codebase is organized (features, layers, modules, patterns).
+  One short section explaining how the main pieces fit together.
 ```
 
 Do not include explanations beyond the result format. Keep responses concise and structured.

package/dist/agents/glance.md

@@ -19,26 +19,18 @@ parameters:
   required: [paths]
 ---
 
-Preview these files and directories: {{paths}}
+Preview these files and directories: {{paths}}. {{#if recursive}}Scan directories recursively.{{else}}Only inspect the top level inside any directory.{{/if}} Respect the max file budget: {{#if maxFiles}}{{maxFiles}}{{else}}20{{/if}}.
 
-{{#if recursive}}Recursively scan directories.{{else}}Only scan the top level of directories.{{/if}}
-
-Maximum files to process: {{#if maxFiles}}{{maxFiles}}{{else}}20 (default){{/if}}.
-
-First, expand any directories into file lists using glob. Then read each file and write a brief summary (under 100 words) describing what the file does, its main exports, or key contents.
-
-For large files, focus on the top-level structure rather than reading everything.
+Expand directories with Glob before reading. For each file, read just enough to understand its role. For large files, skim the top-level structure and the most informative sections instead of reading everything. Keep each summary under 100 words. If a path cannot be read, note that briefly and move on.
 
 Return the results in this format:
 
 ```
 path/to/file.ts
-  Brief summary of what this file does, its purpose, main functions or exports.
+  Short summary of the file's purpose, main exports, or important contents.
 
 path/to/config.json
-  Brief summary of the configuration or data structure.
+  Short summary of the configuration or data stored here.
 ```
 
-If a file can't be read (binary, missing, etc.), note it briefly and move on.
-
 Do not include explanations beyond the result format. Keep responses concise and structured.

package/dist/agents/recall.md

@@ -17,17 +17,9 @@ parameters:
   required: [question]
 ---
 
-Recall what happened in past sessions about: {{question}}
+Recall what past sessions say about this topic: {{question}}. Summarize at most {{#if limit}}{{limit}}{{else}}3{{/if}} sessions.{{#if days}} Only search the last {{days}} days.{{/if}}
 
-Summarize at most {{#if limit}}{{limit}}{{else}}3{{/if}} relevant sessions.{{#if days}} Only look at the last {{days}} days.{{/if}}
-
-Use RecallSearch to find matching sessions.{{#if days}} Pass days={{days}} to limit the time range.{{/if}}
-
-RecallSearch is keyword-based, not semantic. It only matches exact words in the text. Search for words that would literally appear in the conversation, not abstract category labels.
-
-If no results, rethink what words the conversation would actually contain and retry. Try up to 3 rounds before giving up.
-
-When you find relevant hits, use RecallRead to get the surrounding conversation. Pass the sessionId and messageIndex from the hit. Use contextBefore and contextAfter to control the reading window (defaults to 2 before, 5 after).
+Start with RecallSearch. It is literal full-text search, not semantic recall, so search for names, file paths, error strings, commands, or short phrases that would actually appear in the conversation. If the first query is weak or returns nothing, try better keyword variations. Make up to three search attempts before giving up. When you find promising hits, use RecallRead with the sessionId and messageIndex from RecallSearch. Read enough surrounding context to understand the key decision, bug, or task. Use contextBefore and contextAfter to widen the window only when needed. Pay attention to totalMatchedSessions so you notice when search results were truncated.
 
 Return the results in this format:
 

package/dist/agents/review.md

@@ -10,18 +10,9 @@ parameters:
       description: Optional angle to prioritize during the review, such as security, performance, tests, readability, or error handling.
 ---
 
-Review the work just completed with fresh eyes.
+Review the recent work in this conversation with fresh eyes. {{#if focus}}Prioritize {{focus}}.{{/if}} Do not modify files. Read the changed files and verify the actual code before judging it. Do not assume the implementation matches what was described in the conversation.
 
-{{#if focus}}Prioritize this angle: {{focus}}.{{/if}}
-
-Do not modify any files. Read the changed files to verify the claims made. Do not assume what was described is what was really written.
-
-Check for:
-- Correctness bugs, unhandled edge cases, missing validation
-- Inconsistency with surrounding code style
-- Unclear naming or logic that will confuse later readers
-- Over-engineering or unneeded complexity
-- Gaps between what was requested and what was delivered
+Look for real problems first: correctness bugs, edge cases, missing validation, broken assumptions, gaps between the request and the implementation, and complexity that was not needed. Also note important inconsistencies with surrounding code, confusing naming or logic, and smaller nits that are safe to skip. If the work is clean, say so plainly. Do not invent issues just to fill the format.
 
 Return the results in this format:
 
@@ -41,6 +32,4 @@ Missed:
 - Anything the work should have covered but did not.
 ```
 
-If nothing needs changing, say so plainly. Do not invent problems.
-
 Do not include explanations beyond the result format. Keep responses concise and structured.

package/dist/agents/search.md

@@ -14,19 +14,11 @@ parameters:
   required: [question]
 ---
 
-Find and extract code that answers this question: {{question}}
+Find code that answers this question: {{question}}. {{#if directory}}Keep the search inside this directory: {{directory}}.{{/if}}
 
-{{#if directory}}Limit the search to this directory: {{directory}}.{{/if}}
+Start by running Grep with keywords drawn from the question. Follow function calls, imports, and references until you reach the code that actually answers it. Use Glob to narrow the file set when Grep reveals likely locations. Read only the files and sections that matter. For single-file answers, return the most relevant section. For multi-file flows, include the key segments from each file so the caller can see how the pieces connect. Use line ranges when you are excerpting, and full file contents only when the file is small and the whole thing is relevant.
 
-Use grep to search for keywords related to the question. Trace function calls, imports, and references.
-
-Use glob to identify relevant files based on your grep findings.
-
-Read the files that contain the answer to the question. Focus on the specific code sections that address what's being asked.
-
-For complex flows, read multiple files to understand the complete picture.
-
-Return the results in this format. Use line ranges when only a section is relevant, complete contents for small files:
+Return the results in this format:
 
 ```
 File: path/to/file.ts
@@ -37,6 +29,4 @@ File: path/to/another.ts
 <complete file contents>
 ```
 
-If the code references other parts that explain the answer, include those too.
-
 Do not include explanations beyond the result format. Keep responses concise and structured.