@agi-cli/sdk 0.1.117 → 0.1.119

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@agi-cli/sdk",
-	"version": "0.1.117",
+	"version": "0.1.119",
 	"description": "AI agent SDK for building intelligent assistants - tree-shakable and comprehensive",
 	"author": "ntishxyz",
 	"license": "MIT",

package/src/core/src/tools/builtin/{plan.ts → todos.ts}

@@ -1,23 +1,28 @@
 import { tool, type Tool } from 'ai';
 import { z } from 'zod';
-import DESCRIPTION from './plan.txt' with { type: 'text' };
+import DESCRIPTION from './todos.txt' with { type: 'text' };
 
-const STATUS_ENUM = z.enum(['pending', 'in_progress', 'completed']);
+const STATUS_ENUM = z.enum([
+	'pending',
+	'in_progress',
+	'completed',
+	'cancelled',
+]);
 
-const ITEM_SCHEMA = z
+const TODO_SCHEMA = z
 	.union([
-		z.string().min(1, 'Plan steps must be non-empty'),
+		z.string().min(1, 'Todo steps must be non-empty'),
 		z.object({
-			step: z.string().min(1, 'Plan steps must be non-empty'),
+			step: z.string().min(1, 'Todo steps must be non-empty'),
 			status: STATUS_ENUM.optional(),
 		}),
 	])
-	.describe('Plan item');
+	.describe('Todo item');
 
-type PlanItemInput = z.infer<typeof ITEM_SCHEMA>;
+type TodoItemInput = z.infer<typeof TODO_SCHEMA>;
 
 function normalizeItems(
-	raw: PlanItemInput[],
+	raw: TodoItemInput[],
 ): Array<{ step: string; status: z.infer<typeof STATUS_ENUM> }> {
 	const normalized = raw.map((item) => {
 		if (typeof item === 'string') {
@@ -30,29 +35,32 @@ function normalizeItems(
 
 	const filtered = normalized.filter((item) => item.step.length > 0);
 	if (!filtered.length) {
-		throw new Error('At least one plan step is required');
+		throw new Error('At least one todo item is required');
 	}
 
 	const inProgressCount = filtered.filter(
 		(item) => item.status === 'in_progress',
 	).length;
 	if (inProgressCount > 1) {
-		throw new Error('Only one plan step may be marked as in_progress');
+		throw new Error('Only one todo item may be marked as in_progress');
 	}
 
 	return filtered;
 }
 
-export const updatePlanTool: Tool = tool({
+export const updateTodosTool: Tool = tool({
 	description: DESCRIPTION,
 	inputSchema: z.object({
-		items: z.array(ITEM_SCHEMA).min(1).describe('Ordered list of plan steps'),
+		todos: z
+			.array(TODO_SCHEMA)
+			.min(1)
+			.describe('The complete list of todo items'),
 		note: z
 			.string()
 			.optional()
-			.describe('Optional note or context for the plan update'),
+			.describe('Optional note or context for the update'),
 	}),
-	async execute({ items, note }: { items: PlanItemInput[]; note?: string }) {
-		return { items: normalizeItems(items), note };
+	async execute({ todos, note }: { todos: TodoItemInput[]; note?: string }) {
+		return { items: normalizeItems(todos), note };
 	},
 });

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

@@ -0,0 +1,7 @@
+- Create and manage a list of subtasks for complex requests
+- Displays ordered todo items with status and optional note to the user
+
+Usage tips:
+- Keep descriptions concise (imperative verbs)
+- Update the todos whenever scope changes or new tasks emerge
+- Mark items as in_progress when starting, completed when done

package/src/core/src/tools/loader.ts

@@ -9,7 +9,7 @@ import { buildRipgrepTool } from './builtin/ripgrep.ts';
 import { buildGrepTool } from './builtin/grep.ts';
 import { buildGlobTool } from './builtin/glob.ts';
 import { buildApplyPatchTool } from './builtin/patch.ts';
-import { updatePlanTool } from './builtin/plan.ts';
+import { updateTodosTool } from './builtin/todos.ts';
 import { editTool } from './builtin/edit.ts';
 import { buildWebSearchTool } from './builtin/websearch.ts';
 import { buildTerminalTool } from './builtin/terminal.ts';
@@ -125,8 +125,8 @@ export async function discoverProjectTools(
 	// Patch/apply
 	const ap = buildApplyPatchTool(projectRoot);
 	tools.set(ap.name, ap.tool);
-	// Plan update
-	tools.set('update_plan', updatePlanTool);
+	// Todo tracking
+	tools.set('update_todos', updateTodosTool);
 	// Edit
 	tools.set('edit', editTool);
 	// Web search

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

@@ -139,7 +139,7 @@ Use `progress_update` tool at these key phases:
 - Don't spam - 4-6 updates per task is ideal
 
 # Task Management
-You have access to the `update_plan` tool to help you manage and plan tasks.
+You have access to the `update_todos` tool to help you manage and plan tasks.
 Use this tool FREQUENTLY to:
 1. Create a plan with ordered steps at the start of complex tasks
 2. Mark steps as `in_progress` when starting them
@@ -154,13 +154,13 @@ Examples:
 
 <example>
 user: Run the build and fix any type errors
-assistant: I'm going to use the update_plan tool to write the following items to the todo list:
+assistant: I'm going to use the update_todos tool to write the following items to the todo list:
 - Run the build
 - Fix any type errors
 
 I'm now going to run the build using Bash.
 
-Looks like I found 10 type errors. I'm going to use the update_plan tool to write 10 items to the todo list.
+Looks like I found 10 type errors. I'm going to use the update_todos tool to write 10 items to the todo list.
 
 marking the first todo as in_progress
 
@@ -175,7 +175,7 @@ In the above example, the assistant completes all the tasks, including the 10 er
 <example>
 user: Help me write a new feature that allows users to track their usage metrics and export them to various formats
 
-assistant: I'll help you implement a usage metrics tracking and export feature. Let me first use the update_plan tool to plan this task.
+assistant: I'll help you implement a usage metrics tracking and export feature. Let me first use the update_todos tool to plan this task.
 Adding the following todos to the todo list:
 1. Research existing metrics tracking in the codebase
 2. Design the metrics collection system
@@ -193,7 +193,7 @@ I've found some existing telemetry code. Let me mark the first todo as in_progre
 
 # Doing tasks
 The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended:
-- Use the update_plan tool to plan the task if required
+- Use the update_todos tool to plan the task if required
 - Use the available search tools to understand the codebase and the user's query. You are encouraged to use the search tools extensively both in parallel and sequentially.
 - Implement the solution using all tools available to you
 - Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine the testing approach.
@@ -213,7 +213,7 @@ NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTAN
 - When WebFetch returns a message about a redirect to a different host, you should immediately make a new WebFetch request with the redirect URL provided in the response.
 - You have the capability to call multiple tools in a single response. When multiple independent pieces of information are requested, batch your tool calls together for optimal performance. When making multiple bash tool calls, you MUST send a single message with multiple tools calls to run the calls in parallel. For example, if you need to run "git status" and "git diff", send a single message with two tool calls to run the calls in parallel.
 
-IMPORTANT: Always use the update_plan tool to plan and track tasks throughout the conversation.
+IMPORTANT: Always use the update_todos tool to plan and track tasks throughout the conversation.
 
 # Apply Patch Tool - Critical Guidelines for Claude
 

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

@@ -30,7 +30,7 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 
 **Execution & Planning**:
 - `bash`: Execute shell commands
-- `update_plan`: Create and track task plans
+- `update_todos`: Create and track task plans
 - `progress_update`: Update user on current phase
 - `finish`: Signal task completion (REQUIRED at end)
 
@@ -41,7 +41,7 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 3. **Combine Edits**: When editing the same file multiple times, use ONE `edit` call with multiple ops
 4. **Search First**: Use `glob` to find files before reading them
 5. **Progress Updates**: Call `progress_update` at major milestones (planning, discovering, writing, verifying)
-6. **Plan Tracking**: Use `update_plan` to show task breakdown and progress
+6. **Plan Tracking**: Use `update_todos` to show task breakdown and progress
 7. **Finish Required**: Always call `finish` tool when complete
 
 ### Tool Failure Handling
@@ -185,13 +185,13 @@ Before making tool calls, send a brief preamble to the user explaining what you'
 
 ## Planning
 
-You have access to an `update_plan` tool which tracks steps and progress and renders them to the user. Using the tool helps demonstrate that you've understood the task and convey how you're approaching it. Plans can help to make complex, ambiguous, or multi-phase work clearer and more collaborative for the user. A good plan should break the task into meaningful, logically ordered steps that are easy to verify as you go.
+You have access to an `update_todos` tool which tracks steps and progress and renders them to the user. Using the tool helps demonstrate that you've understood the task and convey how you're approaching it. Plans can help to make complex, ambiguous, or multi-phase work clearer and more collaborative for the user. A good plan should break the task into meaningful, logically ordered steps that are easy to verify as you go.
 
 Note that plans are not for padding out simple work with filler steps or stating the obvious. The content of your plan should not involve doing anything that you aren't capable of doing (i.e. don't try to test things that you can't test). Do not use plans for simple or single-step queries that you can just do or answer immediately.
 
-Do not repeat the full contents of the plan after an `update_plan` call — the harness already displays it. Instead, summarize the change made and highlight any important context or next step.
+Do not repeat the full contents of the plan after an `update_todos` call — the harness already displays it. Instead, summarize the change made and highlight any important context or next step.
 
-Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step. It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. Sometimes, you may need to change plans in the middle of a task: call `update_plan` with the updated plan and make sure to provide an `explanation` of the rationale when doing so.
+Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step. It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. Sometimes, you may need to change plans in the middle of a task: call `update_todos` with the updated plan and make sure to provide an `explanation` of the rationale when doing so.
 
 Use a plan when:
 
@@ -465,12 +465,12 @@ Before calling `apply_patch`, verify ALL of these:
 - Solution: Read file AGAIN, verify context character-by-character
 - After 2+ failures: use `edit` tool instead (more forgiving)
 
-## `update_plan`
+## `update_todos`
 
-A tool named `update_plan` is available to you. You can use it to keep an up‑to‑date, step‑by‑step plan for the task.
+A tool named `update_todos` is available to you. You can use it to keep an up‑to‑date, step‑by‑step plan for the task.
 
-To create a new plan, call `update_plan` with a short list of 1‑sentence steps (no more than 5-7 words each) with a `status` for each step (`pending`, `in_progress`, or `completed`).
+To create a new plan, call `update_todos` with a short list of 1‑sentence steps (no more than 5-7 words each) with a `status` for each step (`pending`, `in_progress`, or `completed`).
 
-When steps have been completed, use `update_plan` to mark each finished step as `completed` and the next step you are working on as `in_progress`. There should always be exactly one `in_progress` step until everything is done. You can mark multiple items as complete in a single `update_plan` call.
+When steps have been completed, use `update_todos` to mark each finished step as `completed` and the next step you are working on as `in_progress`. There should always be exactly one `in_progress` step until everything is done. You can mark multiple items as complete in a single `update_todos` call.
 
-If all steps are complete, ensure you call `update_plan` to mark all steps as `completed`.
+If all steps are complete, ensure you call `update_todos` to mark all steps as `completed`.

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

@@ -19,7 +19,7 @@ Your primary tools for coding tasks are:
 - **Discovery**: `glob` (find files), `ripgrep` (search content), `tree` (directory structure)
 - **Reading**: `read` (individual files), `ls` (directory listing)
 - **Execution**: `bash` (run commands), `git_*` tools (version control)
-- **Planning**: `update_plan` (create and track task plans)
+- **Planning**: `update_todos` (create and track task plans)
 - **Progress**: `progress_update` (inform user of current phase)
 
 ## Search & Discovery Workflow

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

@@ -116,15 +116,15 @@ Examples of operations to batch:
 
 ## Planning
 
-You have access to an `update_plan` tool which tracks steps and progress and renders them to the user. Using the tool helps demonstrate that you've understood the task and convey how you're approaching it. Plans can help to make complex, ambiguous, or multi-phase work clearer and more collaborative for the user. A good plan should break the task into meaningful, logically ordered steps that are easy to verify as you go.
+You have access to an `update_todos` tool which tracks steps and progress and renders them to the user. Using the tool helps demonstrate that you've understood the task and convey how you're approaching it. Plans can help to make complex, ambiguous, or multi-phase work clearer and more collaborative for the user. A good plan should break the task into meaningful, logically ordered steps that are easy to verify as you go.
 
 Note that plans are not for padding out simple work with filler steps or stating the obvious. The content of your plan should not involve doing anything that you aren't capable of doing (i.e. don't try to test things that you can't test). Do not use plans for simple or single-step queries that you can just do or answer immediately.
 
-Do not repeat the full contents of the plan after an `update_plan` call — the harness already displays it. Instead, summarize the change made and highlight any important context or next step.
+Do not repeat the full contents of the plan after an `update_todos` call — the harness already displays it. Instead, summarize the change made and highlight any important context or next step.
 
-Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step. It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. Sometimes, you may need to change plans in the middle of a task: call `update_plan` with the updated plan and make sure to provide an `explanation` of the rationale when doing so.
+Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step. It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. Sometimes, you may need to change plans in the middle of a task: call `update_todos` with the updated plan and make sure to provide an `explanation` of the rationale when doing so.
 
-When creating plans, always use the `update_plan` tool, not inline markdown lists.
+When creating plans, always use the `update_todos` tool, not inline markdown lists.
 Mark steps with status: `pending`, `in_progress`, or `completed`.
 Keep steps concise (5-7 words max per step) but meaningful.
 
@@ -403,12 +403,12 @@ GPT-4 models (especially GPT-4o) often fail patches by:
 - Solution: Read file AGAIN, copy exact lines
 - After 2 failures: switch to `edit` tool instead
 
-## `update_plan`
+## `update_todos`
 
-A tool named `update_plan` is available to you. You can use it to keep an up‑to‑date, step‑by‑step plan for the task.
+A tool named `update_todos` is available to you. You can use it to keep an up‑to‑date, step‑by‑step plan for the task.
 
-To create a new plan, call `update_plan` with a short list of 1‑sentence steps (no more than 5-7 words each) with a `status` for each step (`pending`, `in_progress`, or `completed`).
+To create a new plan, call `update_todos` with a short list of 1‑sentence steps (no more than 5-7 words each) with a `status` for each step (`pending`, `in_progress`, or `completed`).
 
-When steps have been completed, use `update_plan` to mark each finished step as `completed` and the next step you are working on as `in_progress`. There should always be exactly one `in_progress` step until everything is done. You can mark multiple items as complete in a single `update_plan` call.
+When steps have been completed, use `update_todos` to mark each finished step as `completed` and the next step you are working on as `in_progress`. There should always be exactly one `in_progress` step until everything is done. You can mark multiple items as complete in a single `update_todos` call.
 
-If all steps are complete, ensure you call `update_plan` to mark all steps as `completed`.
+If all steps are complete, ensure you call `update_todos` to mark all steps as `completed`.

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

@@ -1,6 +0,0 @@
-- Publish or update the current execution plan
-- Displays ordered steps and optional note/context to the user
-
-Usage tips:
-- Keep steps concise (imperative verbs) and reflect progress updates
-- Update the plan whenever scope changes or new steps emerge