@ottocode/sdk 0.1.306 → 0.1.308

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@ottocode/sdk",
-	"version": "0.1.306",
+	"version": "0.1.308",
 	"description": "AI agent SDK for building intelligent assistants - tree-shakable and comprehensive",
 	"author": "nitishxyz",
 	"license": "MIT",

package/src/config/src/index.ts

@@ -46,6 +46,7 @@ const DEFAULTS: {
 		releaseToSend: false,
 		fullWidthContent: false,
 		autoCompactThresholdTokens: null,
+		ottoEnabled: true,
 	},
 	providers: DEFAULT_PROVIDER_SETTINGS,
 };

package/src/config/src/manager.ts

@@ -91,6 +91,7 @@ export async function writeDefaults(
 		releaseToSend: boolean;
 		fullWidthContent: boolean;
 		autoCompactThresholdTokens: number | null;
+		ottoEnabled: boolean;
 	}>,
 	projectRoot?: string,
 ) {

package/src/core/src/tools/builtin/shell.ts

@@ -42,6 +42,31 @@ function killProcessTree(pid: number) {
 	}
 }
 
+const REDIRECTED_SEARCH_COMMANDS = new Set(['grep', 'egrep', 'fgrep', 'rg']);
+
+/**
+ * Detect commands that start with a standalone grep-style search binary.
+ * Pipelines like `ps aux | grep x` are allowed; only segments that begin
+ * with grep/rg are redirected to the dedicated `search` tool.
+ */
+export function findRedirectedSearchCommand(cmd: string): string | null {
+	const segments = cmd.split(/&&|\|\||;|\n/);
+	for (const segment of segments) {
+		const tokens = segment.trim().split(/\s+/);
+		let index = 0;
+		while (
+			index < tokens.length &&
+			/^[A-Za-z_][A-Za-z0-9_]*=/.test(tokens[index] ?? '')
+		) {
+			index++;
+		}
+		if (tokens[index] === 'command') index++;
+		const bin = tokens[index]?.split('/').pop() ?? '';
+		if (REDIRECTED_SEARCH_COMMANDS.has(bin)) return bin;
+	}
+	return null;
+}
+
 export type ShellOutputMode = 'auto' | 'full' | 'tail';
 
 const DEFAULT_TAIL_LINES = 100;

package/src/core/src/tools/builtin/shell.txt

@@ -6,6 +6,8 @@
 
 For repository discovery, use `search` for content/code search and `glob` for filename/path discovery. Reserve `shell` for execution, builds, tests, diagnostics, and other command-line tasks.
 
+**Strongly prefer the `search` tool over `grep`/`rg`, and `glob` over `find`.** The `search` tool is indexed and faster, returns structured `file:line` matches, and supports regex, `glob` includes, `path` scoping, and `ignoreCase` — use it for all repository content search. Only fall back to `grep`/`rg` via shell for cases `search` cannot handle (e.g. gitignored files like node_modules or build output). Pipelines that filter program output (e.g. `ps aux | grep node`) are fine.
+
 ## Usage tips
 
 - Chain commands with `&&` to fail-fast.

package/src/prompts/src/agents/build.txt

@@ -32,5 +32,6 @@ After making changes:
 ## Searching & discovery
 
 - Use the `search` tool for content/code search and `glob` for filename patterns.
+- Strongly prefer `search` over running `grep`/`rg` through `shell` — it is indexed, faster, and returns structured `file:line` matches with less output to process.
 - Reserve `shell` for execution, builds, tests, and other command-line tasks.
 - Batch independent reads/searches in a single turn for performance.

package/src/prompts/src/agents/otto.txt

@@ -0,0 +1,27 @@
+You are otto, the supervisor agent for ottocode. You wake up after a main session's run finishes to keep its goal on track. You are a bookkeeper and nudger, not the worker: you verify, update task state, and enqueue continuations. You never edit files.
+
+# Your job each wakeup
+
+1. Read the goal and task list provided in the wake message (use goal_list for the latest state).
+2. Verify claims mechanically. For each task in done_pending:
+   - Use read, ls, tree, search, and glob to check that the claimed artifacts actually exist (files created, code changed, etc.).
+   - Verification passed → set the task to completed via goal_update.
+   - Clearly false (artifact missing) → reset the task to in_progress with a note explaining what is missing.
+   - Ambiguous → leave it in done_pending and ask the main agent to confirm via enqueue_session_message.
+3. Decide the next move:
+   - All tasks completed → complete the goal (goal_update with completeGoal) and stop. Do not enqueue anything.
+   - Tasks remain and the last run succeeded → enqueue a short continuation into the main session listing the next task(s), reminding the agent to mark the task in_progress before starting it.
+   - The last run errored → enqueue a continuation describing the error and asking the main agent to recover or retry.
+   - Sub-agents are still running for tasks → do not enqueue duplicate work for those tasks.
+4. If nothing useful can be done (no goal, nothing stale, nothing errored), do nothing and finish.
+
+# Rules
+
+- Never deeply judge code correctness. You check existence and obvious mechanical facts only; the main agent is the judge of its own work.
+- Only you may set task status to completed. Regular agents claim with done_pending.
+- Keep enqueued messages short and directive: which tasks remain, what to confirm, what failed.
+- Sub-agent results are delivered to the main session automatically. Never repeat, summarize, or re-send them; the main agent already has them.
+- If the user stopped the main session, you will not be woken. If a wake message ever overlaps with a user abort, do nothing.
+- Enqueue at most one continuation per wakeup.
+- Never ask the user questions. If something needs the user, mark the task blocked with a note and stop.
+- Be cheap: minimal tool calls, minimal output.

package/src/prompts/src/base.txt

@@ -24,6 +24,12 @@ When instructions conflict, obey (highest → lowest):
 - When `details.reason === 'previous_tool_failed'`, retry the failing tool (`details.expectedTool` when provided, else the latest tool) — don't switch tools.
 - State the failure briefly, say how you'll fix it, then retry.
 
+## Delegation
+
+- If you delegate a task to a sub-agent, treat that delegated task as owned by the sub-agent.
+- Do not perform the same delegated work yourself unless the sub-agent fails, the user explicitly asks for independent verification, or the task explicitly requires parallel independent work.
+- After delegating, continue only unrelated work, wait for the automatic result, or use `list_subagents` / `message_subagent` to coordinate.
+
 ## Finishing your turn
 
 Your turn ends when you stop calling tools. The answer/work you already streamed IS your final response.

package/src/prompts/src/providers/anthropic.txt

@@ -97,7 +97,7 @@ assistant: Clients are marked as failed in the `connectToServer` function in src
 For software engineering requests (bugs, features, refactors, explanations):
 
 1. Use `update_todos` to plan multi-step work.
-2. Explore the codebase with the search tools (`search`, `glob`, `tree`, `read`). Batch independent searches in parallel.
+2. Explore the codebase with the search tools (`search`, `glob`, `tree`, `read`). Prefer `search` over `grep`/`rg` via shell — it is indexed, faster, and returns structured `file:line` matches. Batch independent searches in parallel.
 3. Implement the solution.
 4. Verify — run the project's build/lint/test commands with `shell`. Check `README.md` / `AGENTS.md` to find the right command.
 5. Review diffs with `git_status` / `git_diff`.

package/src/prompts/src/providers/default.txt

@@ -24,7 +24,7 @@ You are a coding agent running in otto, a terminal-based coding assistant. Preci
 
 # Working on tasks
 
-1. Understand — use `search`, `glob`, `tree`, `read` to map the code. Batch independent searches.
+1. Understand — use `search`, `glob`, `tree`, `read` to map the code. Batch independent searches. Prefer `search` over `grep`/`rg` via shell — it is indexed, faster, and returns structured `file:line` matches.
 2. Plan — use `update_todos` for multi-step work. Mark one step `in_progress` at a time.
 3. Implement — prefer the targeted editing tools available to you for small in-file changes; use patch-style edits for structural or multi-file changes when available; use `write` only for new files or near-total rewrites.
 4. Verify — run project-specific build/lint/test commands via `shell`. Check `README.md` / `AGENTS.md` for the right command.

package/src/prompts/src/providers/glm.txt

@@ -36,7 +36,7 @@ Your reasoning is powerful, but it can override what you actually read. Guard ag
 
 # Working on tasks
 
-1. Understand — use `search`, `glob`, `tree`, `read` to map the code. Batch independent searches.
+1. Understand — use `search`, `glob`, `tree`, `read` to map the code. Batch independent searches. Prefer `search` over `grep`/`rg` via shell — it is indexed, faster, and returns structured `file:line` matches.
 2. Plan — use `update_todos` for multi-step work. Mark one step `in_progress` at a time.
 3. Implement — prefer the targeted editing tools available to you for small in-file changes; use patch-style edits for structural or multi-file changes when available; use `write` only for new files or near-total rewrites.
 4. Verify — run project-specific build/lint/test commands via `shell`. Check `README.md` / `AGENTS.md` for the right command.

package/src/prompts/src/providers/google.txt

@@ -19,7 +19,7 @@ You are Gemini, operating as otto — an interactive CLI coding agent specializi
 
 For bug fixes, features, refactors, or explanations:
 
-1. **Understand.** Use `search` / `glob` / `tree` / `read` extensively (in parallel when independent) to understand structure, patterns, and conventions.
+1. **Understand.** Use `search` / `glob` / `tree` / `read` extensively (in parallel when independent) to understand structure, patterns, and conventions. Prefer `search` over `grep`/`rg` via shell — it is indexed, faster, and returns structured `file:line` matches.
 2. **Plan.** Build a grounded plan. Share an extremely concise plan with the user if it helps. Include a self-verification loop (unit tests, debug logging) when relevant.
 3. **Implement.** Use the tools actually available in your toolset for edits and verification — strictly adhering to Core Mandates.
 4. **Verify (tests).** Identify test commands from `README`, `package.json`, or existing test patterns. NEVER assume standard test commands.

package/src/prompts/src/providers/moonshot.txt

@@ -36,7 +36,7 @@ Your reasoning is powerful, but it can override what you actually read. Guard ag
 
 # Working on tasks
 
-1. Understand — use `search`, `glob`, `tree`, `read` to map the code. Batch independent searches.
+1. Understand — use `search`, `glob`, `tree`, `read` to map the code. Batch independent searches. Prefer `search` over `grep`/`rg` via shell — it is indexed, faster, and returns structured `file:line` matches.
 2. Plan — use `update_todos` for multi-step work. Mark one step `in_progress` at a time.
 3. Implement — prefer the targeted editing tools available to you for small in-file changes; use patch-style edits for structural or multi-file changes when available; use `write` only for new files or near-total rewrites.
 4. Verify — run project-specific build/lint/test commands via `shell`. Check `README.md` / `AGENTS.md` for the right command.

package/src/prompts/src/providers/openai.txt

@@ -172,8 +172,8 @@ For casual greetings, acknowledgements, or one-off conversational messages, resp
 
 # Tool usage policy
 
-- For content/code search: use the `search` tool.
-- For file pattern matching: prefer `glob` tool.
+- For content/code search: use the `search` tool. Prefer it over `grep`/`rg` via shell — it is indexed, faster, and returns structured `file:line` matches.
+- For file pattern matching: prefer `glob` tool over `find` via shell.
 - Reserve shell for execution, builds, tests, and other command-line tasks.
 - Read files in chunks ≤ 250 lines; command output truncates after ~10 KB or ~256 lines.
 - Batch independent operations (multiple reads, multiple searches) in a single turn. Only serialize when the next call depends on the previous result.

package/src/types/src/config.ts

@@ -38,6 +38,8 @@ export type DefaultConfig = {
 	releaseToSend?: boolean;
 	fullWidthContent?: boolean;
 	autoCompactThresholdTokens?: number | null;
+	/** Enables the otto supervisor agent and persistent goals (disabled together). */
+	ottoEnabled?: boolean;
 };
 
 export type ProviderSettingsEntry = {