omni-context-cli 0.0.85 → 0.0.86

package/README.md

@@ -76,7 +76,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
 

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.