feat: Replace 'open' package with 'opn' for external link handling

The 'open' package has been replaced with 'opn' to handle opening external links. This change addresses potential issues with the 'open' package and ensures consistent behavior across different environments. The 'opn' package is a more stable and widely used alternative for this functionality.

.changeset/fix-contributing-proto-step.md

@@ -0,0 +1,6 @@
+---
+"claude-dev": patch
+---
+
+Docs: Add missing proto generation step in CONTRIBUTING.md and new `npm run dev` script for easier terminal workflow (fixes #7335)
+

.changeset/free-ducks-camp.md

@@ -0,0 +1,5 @@
+---
+"claude-dev": patch
+---
+
+Created model-family breakouts for deep-planning prompting, and laid groundwork for similar changes for other slash commands.

.changeset/free-nights-notice.md

@@ -0,0 +1,5 @@
+---
+"claude-dev": patch
+---
+
+Use HTTP proxies in more places

.changeset/swift-seas-work.md

@@ -0,0 +1,5 @@
+---
+"claude-dev": patch
+---
+
+Adjusted prompting around focus chain, particularly for next-get/native tool calling models.

CONTRIBUTING.md

@@ -46,7 +46,11 @@ We also welcome contributions to our [documentation](https://github.com/cline/cl
     ```bash
     npm run install:all
     ```
-4. Launch by pressing `F5` (or `Run`->`Start Debugging`) to open a new VSCode window with the extension loaded. (You may need to install the [esbuild problem matchers extension](https://marketplace.visualstudio.com/items?itemName=connor4312.esbuild-problem-matchers) if you run into issues building the project.)
+4. Generate Protocol Buffer files (required before first build):
+    ```bash
+    npm run protos
+    ```
+5. Launch by pressing `F5` (or `Run`->`Start Debugging`) to open a new VSCode window with the extension loaded. (You may need to install the [esbuild problem matchers extension](https://marketplace.visualstudio.com/items?itemName=connor4312.esbuild-problem-matchers) if you run into issues building the project.)
 
 
 
@@ -85,8 +89,10 @@ We also welcome contributions to our [documentation](https://github.com/cline/cl
 
 2. **Local Development**
     - Run `npm run install:all` to install dependencies
+    - Run `npm run protos` to generate Protocol Buffer files (required before first build)
     - Run `npm run test` to run tests locally
     - Run → Start Debugging or `>Debug: Select and Start Debugging` and wait for a new VS Code instance to open
+    - **Terminal Workflow**: Use `npm run dev` (generates protos + runs watch mode) or `npm run watch` (if protos already generated)
     - Before submitting PR, run `npm run format:fix` to format your code
 
 3. **Linux-specific Setup**

package-lock.json

@@ -1,12 +1,12 @@
 {
 	"name": "claude-dev",
-	"version": "3.36.0",
+	"version": "3.36.1",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "claude-dev",
-			"version": "3.36.0",
+			"version": "3.36.1",
 			"license": "Apache-2.0",
 			"dependencies": {
 				"@anthropic-ai/sdk": "^0.37.0",
@@ -46,6 +46,7 @@
 				"@sentry/browser": "^9.12.0",
 				"@streamparser/json": "^0.0.22",
 				"@tailwindcss/vite": "^4.1.14",
+				"@types/opn": "^5.1.0",
 				"@types/uuid": "^10.0.0",
 				"@vscode/codicons": "^0.0.36",
 				"archiver": "^7.0.1",
@@ -76,9 +77,9 @@
 				"nice-grpc": "^2.1.12",
 				"node-machine-id": "^1.1.12",
 				"ollama": "^0.5.13",
-				"open": "^10.1.2",
 				"open-graph-scraper": "^6.9.0",
 				"openai": "^4.83.0",
+				"opn": "^5.5.0",
 				"os-name": "^6.0.0",
 				"p-mutex": "^1.0.0",
 				"p-timeout": "^6.1.4",
@@ -6494,6 +6495,15 @@
 			"dev": true,
 			"license": "MIT"
 		},
+		"node_modules/@types/opn": {
+			"version": "5.1.0",
+			"resolved": "https://registry.npmjs.org/@types/opn/-/opn-5.1.0.tgz",
+			"integrity": "sha512-TNPrB7Y1xl06zDI0aGyqkgxjhIev3oJ+cdqlZ52MTAHauWpEL/gIUdHebIfRHFZk9IqSBpE2ci1DT48iZH81yg==",
+			"license": "MIT",
+			"dependencies": {
+				"@types/node": "*"
+			}
+		},
 		"node_modules/@types/pdf-parse": {
 			"version": "1.1.4",
 			"dev": true,
@@ -7841,6 +7851,7 @@
 		},
 		"node_modules/bundle-name": {
 			"version": "4.1.0",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"run-applescript": "^7.0.0"
@@ -8807,6 +8818,7 @@
 		},
 		"node_modules/default-browser": {
 			"version": "5.2.1",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"bundle-name": "^4.1.0",
@@ -8821,6 +8833,7 @@
 		},
 		"node_modules/default-browser-id": {
 			"version": "5.0.0",
+			"dev": true,
 			"license": "MIT",
 			"engines": {
 				"node": ">=18"
@@ -8883,6 +8896,7 @@
 		},
 		"node_modules/define-lazy-prop": {
 			"version": "3.0.0",
+			"dev": true,
 			"license": "MIT",
 			"engines": {
 				"node": ">=12"
@@ -11428,6 +11442,7 @@
 		},
 		"node_modules/is-inside-container": {
 			"version": "1.0.0",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"is-docker": "^3.0.0"
@@ -11444,6 +11459,7 @@
 		},
 		"node_modules/is-inside-container/node_modules/is-docker": {
 			"version": "3.0.0",
+			"dev": true,
 			"license": "MIT",
 			"bin": {
 				"is-docker": "cli.js"
@@ -14294,6 +14310,7 @@
 		},
 		"node_modules/open": {
 			"version": "10.1.2",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"default-browser": "^5.2.1",
@@ -14332,6 +14349,7 @@
 		},
 		"node_modules/open/node_modules/is-wsl": {
 			"version": "3.1.0",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"is-inside-container": "^1.0.0"
@@ -14378,6 +14396,27 @@
 				"undici-types": "~5.26.4"
 			}
 		},
+		"node_modules/opn": {
+			"version": "5.5.0",
+			"resolved": "https://registry.npmjs.org/opn/-/opn-5.5.0.tgz",
+			"integrity": "sha512-PqHpggC9bLV0VeWcdKhkpxY+3JTzetLSqTCWL/z/tFIbI6G8JCjondXklT1JinczLz2Xib62sSp0T/gKT4KksA==",
+			"license": "MIT",
+			"dependencies": {
+				"is-wsl": "^1.1.0"
+			},
+			"engines": {
+				"node": ">=4"
+			}
+		},
+		"node_modules/opn/node_modules/is-wsl": {
+			"version": "1.1.0",
+			"resolved": "https://registry.npmjs.org/is-wsl/-/is-wsl-1.1.0.tgz",
+			"integrity": "sha512-gfygJYZ2gLTDlmbWMI0CE2MwnFzSN/2SZfkMlItC4K/JBlsWVDB0bO6XhqcY13YXE7iMcAJnzTCJjPiTeJJ0Mw==",
+			"license": "MIT",
+			"engines": {
+				"node": ">=4"
+			}
+		},
 		"node_modules/opossum": {
 			"version": "9.0.0",
 			"license": "Apache-2.0",
@@ -15842,6 +15881,7 @@
 		},
 		"node_modules/run-applescript": {
 			"version": "7.0.0",
+			"dev": true,
 			"license": "MIT",
 			"engines": {
 				"node": ">=18"

package.json

@@ -304,6 +304,7 @@
 		"dev:cli:watch": "node scripts/dev-cli-watch.mjs",
 		"postcompile-standalone": "node scripts/package-standalone.mjs",
 		"postcompile-standalone-npm": "node scripts/package-standalone.mjs --target=npm",
+		"dev": "npm run protos && npm run watch",
 		"watch": "npm-run-all -p watch:*",
 		"watch:esbuild": "node esbuild.mjs --watch",
 		"watch:tsc": "tsc --noEmit --watch --project tsconfig.json",
@@ -440,6 +441,7 @@
 		"@sentry/browser": "^9.12.0",
 		"@streamparser/json": "^0.0.22",
 		"@tailwindcss/vite": "^4.1.14",
+		"@types/opn": "^5.1.0",
 		"@types/uuid": "^10.0.0",
 		"@vscode/codicons": "^0.0.36",
 		"archiver": "^7.0.1",
@@ -470,9 +472,9 @@
 		"nice-grpc": "^2.1.12",
 		"node-machine-id": "^1.1.12",
 		"ollama": "^0.5.13",
-		"open": "^10.1.2",
 		"open-graph-scraper": "^6.9.0",
 		"openai": "^4.83.0",
+		"opn": "^5.5.0",
 		"os-name": "^6.0.0",
 		"p-mutex": "^1.0.0",
 		"p-timeout": "^6.1.4",

proto/cline/models.proto

@@ -321,7 +321,7 @@ message UpdateApiConfigurationRequestNew {
   // - "options.openAiHeaders" (for options fields)
   // - "secrets.apiKey" (for secrets fields)
   // - "secrets.openRouterApiKey" (for secrets fields)
-  google.protobuf.FieldMask update_mask = 3;
+  repeated string update_mask = 3;
 }
 
 // Request for partially updating API configuration using FieldMask

src/core/controller/index.ts

@@ -33,6 +33,7 @@ import { LogoutReason } from "@/services/auth/types"
 import { featureFlagsService } from "@/services/feature-flags"
 import { getDistinctId } from "@/services/logging/distinctId"
 import { telemetryService } from "@/services/telemetry"
+import { getAxiosSettings } from "@/shared/net"
 import { ShowMessageType } from "@/shared/proto/host/window"
 import { AuthState } from "@/shared/proto/index.cline"
 import { getLatestAnnouncementId } from "@/utils/announcements"
@@ -651,6 +652,7 @@ export class Controller {
 				"Content-Type": "application/json",
 				"User-Agent": "cline-vscode-extension",
 			},
+			...getAxiosSettings(),
 		})
 
 		if (!response.data) {
@@ -698,7 +700,7 @@ export class Controller {
 	async handleOpenRouterCallback(code: string) {
 		let apiKey: string
 		try {
-			const response = await axios.post("https://openrouter.ai/api/v1/auth/keys", { code })
+			const response = await axios.post("https://openrouter.ai/api/v1/auth/keys", { code }, getAxiosSettings())
 			if (response.data && response.data.key) {
 				apiKey = response.data.key
 			} else {

src/core/controller/mcp/downloadMcp.ts

@@ -3,6 +3,7 @@ import { StringRequest } from "@shared/proto/cline/common"
 import { McpDownloadResponse } from "@shared/proto/cline/mcp"
 import axios from "axios"
 import { ClineEnv } from "@/config"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 import { sendChatButtonClickedEvent } from "../ui/subscribeToChatButtonClicked"
 
@@ -36,6 +37,7 @@ export async function downloadMcp(controller: Controller, request: StringRequest
 			{
 				headers: { "Content-Type": "application/json" },
 				timeout: 10000,
+				...getAxiosSettings(),
 			},
 		)
 

src/core/controller/models/getAihubmixModels.ts

@@ -1,6 +1,7 @@
 import { EmptyRequest } from "@shared/proto/cline/common"
 import { OpenRouterCompatibleModelInfo, OpenRouterModelInfo } from "@shared/proto/cline/models"
 import axios from "axios"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 
 /**
@@ -11,7 +12,7 @@ import { Controller } from ".."
  */
 export async function getAihubmixModels(_controller: Controller, _request: EmptyRequest): Promise<OpenRouterCompatibleModelInfo> {
 	try {
-		const response = await axios.get("https://aihubmix.com/call/mdl_info_platform?tag=coding")
+		const response = await axios.get("https://aihubmix.com/call/mdl_info_platform?tag=coding", getAxiosSettings())
 
 		if (!response.data?.success || !Array.isArray(response.data?.data)) {
 			console.error("Invalid response from AIhubmix API:", response.data)

src/core/controller/models/getOllamaModels.ts

@@ -1,5 +1,6 @@
 import { StringArray, StringRequest } from "@shared/proto/cline/common"
 import axios from "axios"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 
 /**
@@ -16,7 +17,7 @@ export async function getOllamaModels(_controller: Controller, request: StringRe
 			return StringArray.create({ values: [] })
 		}
 
-		const response = await axios.get(`${baseUrl}/api/tags`)
+		const response = await axios.get(`${baseUrl}/api/tags`, getAxiosSettings())
 		const modelsArray = response.data?.models?.map((model: any) => model.name) || []
 		const models = [...new Set<string>(modelsArray)].sort()
 

src/core/controller/models/getSapAiCoreModels.ts

@@ -1,4 +1,5 @@
 import axios from "axios"
+import { getAxiosSettings } from "@/shared/net"
 import { SapAiCoreModelDeployment, SapAiCoreModelsRequest, SapAiCoreModelsResponse } from "@/shared/proto/cline/models"
 import { Controller } from ".."
 
@@ -33,6 +34,7 @@ async function getToken(clientId: string, clientSecret: string, tokenUrl: string
 	const url = tokenUrl.replace(/\/+$/, "") + "/oauth/token"
 	const response = await axios.post(url, payload, {
 		headers: { "Content-Type": "application/x-www-form-urlencoded" },
+		...getAxiosSettings(),
 	})
 	const token = response.data as Token
 	token.expires_at = Date.now() + token.expires_in * 1000
@@ -65,7 +67,7 @@ async function fetchAiCoreDeploymentsAndOrchestration(
 	const url = `${baseUrl}/v2/lm/deployments?$top=10000&$skip=0`
 
 	try {
-		const response = await axios.get(url, { headers })
+		const response = await axios.get(url, { headers, ...getAxiosSettings() })
 		const allDeployments = response.data.resources
 
 		// Filter running deployments

src/core/controller/models/refreshBasetenModels.ts

@@ -5,6 +5,7 @@ import { parsePrice } from "@utils/model-utils"
 import axios from "axios"
 import fs from "fs/promises"
 import path from "path"
+import { getAxiosSettings } from "@/shared/net"
 import { basetenModels } from "../../../shared/api"
 import { Controller } from ".."
 
@@ -50,6 +51,7 @@ export async function refreshBasetenModels(controller: Controller): Promise<Reco
 					"User-Agent": "Cline-VSCode-Extension",
 				},
 				timeout: 10000, // 10 second timeout
+				...getAxiosSettings(),
 			})
 
 			if (response.data?.data) {

src/core/controller/models/refreshGroqModels.ts

@@ -5,6 +5,7 @@ import axios from "axios"
 import fs from "fs/promises"
 import path from "path"
 import { telemetryService } from "@/services/telemetry"
+import { getAxiosSettings } from "@/shared/net"
 import { groqModels } from "../../../shared/api"
 import { Controller } from ".."
 
@@ -52,6 +53,7 @@ export async function refreshGroqModels(controller: Controller): Promise<Record<
 					"User-Agent": "Cline-VSCode-Extension",
 				},
 				timeout: 10000, // 10 second timeout
+				...getAxiosSettings(),
 			})
 
 			if (response.data?.data) {

src/core/controller/models/refreshHicapModels.ts

@@ -5,6 +5,7 @@ import { fileExistsAtPath } from "@utils/fs"
 import axios from "axios"
 import fs from "fs/promises"
 import path from "path"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 
 /**
@@ -33,6 +34,7 @@ export async function refreshHicapModels(controller: Controller, _request: Empty
 			headers: {
 				"api-key": hicapApiKey,
 			},
+			...getAxiosSettings(),
 		})
 
 		if (response.data?.data) {

src/core/controller/models/refreshHuggingFaceModels.ts

@@ -6,6 +6,7 @@ import axios from "axios"
 import fs from "fs/promises"
 import path from "path"
 import { ensureCacheDirectoryExists } from "@/core/storage/disk"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 
 /**
@@ -26,6 +27,7 @@ export async function refreshHuggingFaceModels(
 		// Fetch models from Hugging Face API
 		const response = await axios.get("https://router.huggingface.co/v1/models", {
 			timeout: 10000,
+			...getAxiosSettings(),
 		})
 
 		if (response.data?.data) {

src/core/controller/models/refreshOpenAiModels.ts

@@ -2,6 +2,7 @@ import { StringArray } from "@shared/proto/cline/common"
 import { OpenAiModelsRequest } from "@shared/proto/cline/models"
 import type { AxiosRequestConfig } from "axios"
 import axios from "axios"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 
 /**
@@ -25,7 +26,7 @@ export async function refreshOpenAiModels(_controller: Controller, request: Open
 			config["headers"] = { Authorization: `Bearer ${request.apiKey}` }
 		}
 
-		const response = await axios.get(`${request.baseUrl}/models`, config)
+		const response = await axios.get(`${request.baseUrl}/models`, { ...config, ...getAxiosSettings() })
 		const modelsArray = response.data?.data?.map((model: any) => model.id) || []
 		const models = [...new Set<string>(modelsArray)]
 

src/core/controller/models/refreshOpenRouterModels.ts

@@ -10,6 +10,7 @@ import {
 	openRouterClaudeSonnet41mModelId,
 	openRouterClaudeSonnet451mModelId,
 } from "@/shared/api"
+import { getAxiosSettings } from "@/shared/net"
 import type { Controller } from ".."
 
 type OpenRouterSupportedParams =
@@ -79,7 +80,7 @@ export async function refreshOpenRouterModels(controller: Controller): Promise<R
 
 	const models: Record<string, ModelInfo> = {}
 	try {
-		const response = await axios.get("https://openrouter.ai/api/v1/models")
+		const response = await axios.get("https://openrouter.ai/api/v1/models", getAxiosSettings())
 
 		if (response.data?.data) {
 			const rawModels = response.data.data

src/core/controller/models/refreshRequestyModels.ts

@@ -1,6 +1,7 @@
 import { EmptyRequest } from "@shared/proto/cline/common"
 import { OpenRouterCompatibleModelInfo, OpenRouterModelInfo } from "@shared/proto/cline/models"
 import axios from "axios"
+import { getAxiosSettings } from "@/shared/net"
 import { toRequestyServiceUrl } from "@/shared/clients/requesty"
 import { Controller } from ".."
 
@@ -33,7 +34,7 @@ export async function refreshRequestyModels(controller: Controller, _: EmptyRequ
 		const headers = {
 			Authorization: `Bearer ${apiKey}`,
 		}
-		const response = await axios.get(url, { headers })
+		const response = await axios.get(url, { headers, ...getAxiosSettings() })
 		if (response.data?.data) {
 			for (const model of response.data.data) {
 				const modelInfo: OpenRouterModelInfo = OpenRouterModelInfo.create({

src/core/controller/models/refreshVercelAiGatewayModels.ts

@@ -4,6 +4,7 @@ import { fileExistsAtPath } from "@utils/fs"
 import axios from "axios"
 import fs from "fs/promises"
 import path from "path"
+import { getAxiosSettings } from "@/shared/net"
 import { Controller } from ".."
 
 /**
@@ -17,7 +18,7 @@ export async function refreshVercelAiGatewayModels(_controller: Controller): Pro
 	let models: Record<string, ModelInfo> = {}
 
 	try {
-		const response = await axios.get("https://ai-gateway.vercel.sh/v1/models")
+		const response = await axios.get("https://ai-gateway.vercel.sh/v1/models", getAxiosSettings())
 
 		if (response.data?.data) {
 			const rawModels = response.data.data

src/core/prompts/commands.ts

@@ -1,4 +1,5 @@
-import { getShell } from "@utils/shell"
+import type { ApiProviderInfo } from "@/core/api"
+import { getDeepPlanningPrompt } from "./commands/deep-planning"
 
 export const newTaskToolResponse = () =>
 	`<explicit_instructions type="new_task">
@@ -208,256 +209,12 @@ cline "<prompt>"
 </explicit_instructions>\n
 `
 
-export const deepPlanningToolResponse = (focusChainSettings?: { enabled: boolean }) => {
-	const detectedShell = getShell()
-
-	// FIXME: detectedShell returns a non-string value on some Windows machines
-	let isPowerShell = false
-	try {
-		isPowerShell =
-			detectedShell != null &&
-			typeof detectedShell === "string" &&
-			(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
-	} catch {}
-
-	return `<explicit_instructions type="deep-planning">
-Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
-
-Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
-
-## STEP 1: Silent Investigation
-
-<important>
-until explicitly instructed by the user to proceed with coding.
-You must thoroughly understand the existing codebase before proposing any changes.
-Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
-</important>
-
-### Required Research Activities
-You must use the read_file tool to examine relevant source files, configuration files, and documentation. You must use terminal commands to gather information about the codebase structure and patterns. All terminal output must be piped to cat for visibility.
-
-### Essential Terminal Commands
-First, determine the language(s) used in the codebase, then execute these commands to build your understanding. You must tailor them to the codebase and ensure the output is not overly verbose. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. These are only examples, the exact commands will differ depending on the codebase.
-
-${
-	isPowerShell
-		? `
-# Discover project structure and file types
-Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
-
-# Find all class and function definitions
-Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
-
-# Analyze import patterns and dependencies
-Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
-
-# Find dependency manifests
-Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
-
-# Identify technical debt and TODOs
-Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
-`
-		: `
-# Discover project structure and file types
-find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
-
-# Find all class and function definitions
-grep -r "class\|function\|def\|interface\|struct\|func\|type.*struct\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
-
-# Analyze import patterns and dependencies
-grep -r "import\|from\|require\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
-
-# Find dependency manifests
-find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
-
-# Identify technical debt and TODOs
-grep -r "TODO\|FIXME\|XXX\|HACK\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
-`
-}
-
-
-## STEP 2: Discussion and Questions
-
-Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
-
-**Ask questions only when necessary for:**
-- Clarifying ambiguous requirements or specifications
-- Choosing between multiple equally valid implementation approaches  
-- Confirming assumptions about existing system behavior or constraints
-- Understanding preferences for specific technical decisions that will affect the implementation
-
-Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
-
-## STEP 3: Create Implementation Plan Document
-
-Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
-
-### Document Structure Requirements
-
-Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
-
-
-# Implementation Plan
-
-[Overview]
-Single sentence describing the overall goal.
-
-Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
-
-[Types]  
-Single sentence describing the type system changes.
-
-Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
-
-[Files]
-Single sentence describing file modifications.
-
-Detailed breakdown:
-- New files to be created (with full paths and purpose)
-- Existing files to be modified (with specific changes)  
-- Files to be deleted or moved
-- Configuration file updates
-
-[Functions]
-Single sentence describing function modifications.
-
-Detailed breakdown:
-- New functions (name, signature, file path, purpose)
-- Modified functions (exact name, current file path, required changes)
-- Removed functions (name, file path, reason, migration strategy)
-
-[Classes]
-Single sentence describing class modifications.
-
-Detailed breakdown:
-- New classes (name, file path, key methods, inheritance)
-- Modified classes (exact name, file path, specific modifications)
-- Removed classes (name, file path, replacement strategy)
-
-[Dependencies]
-Single sentence describing dependency modifications.
-
-Details of new packages, version changes, and integration requirements.
-
-[Testing]
-Single sentence describing testing approach.
-
-Test file requirements, existing test modifications, and validation strategies.
-
-[Implementation Order]
-Single sentence describing the implementation sequence.
-
-Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
-
-
-## STEP 4: Create Implementation Task
-
-Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
-
-### Task Creation Requirements
-
-Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
-
-**Plan Document Navigation Commands:**
-The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you createdm, and explicitly provide them when creating the new task:
-
-${
-	isPowerShell
-		? `
-# Read Overview section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Types section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Files section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Functions section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Classes section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Dependencies section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Testing section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
-
-# Read Implementation Order section
-$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
-`
-		: `
-# Read Overview section
-sed -n '/\[Overview\]/,/\[Types\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Types section  
-sed -n '/\[Types\]/,/\[Files\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Files section
-sed -n '/\[Files\]/,/\[Functions\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Functions section
-sed -n '/\[Functions\]/,/\[Classes\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Classes section
-sed -n '/\[Classes\]/,/\[Dependencies\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Dependencies section
-sed -n '/\[Dependencies\]/,/\[Testing\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Testing section
-sed -n '/\[Testing\]/,/\[Implementation Order\]/p' implementation_plan.md | head -n 1 | cat
-
-# Read Implementation Order section
-sed -n '/\[Implementation Order\]/,$p' implementation_plan.md | cat
-`
-}
-
-
-**Task Progress Format:**
-<IMPORTANT>
-You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
-
-
-task_progress Items:
-- [ ] Step 1: Brief description of first implementation step
-- [ ] Step 2: Brief description of second implementation step  
-- [ ] Step 3: Brief description of third implementation step
-- [ ] Step N: Brief description of final implementation step
-
-
-You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
-
-Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
-
-${
-	focusChainSettings?.enabled
-		? `
-**Task Progress Parameter:**
-When creating the new task, you must include a task_progress parameter that breaks down the implementation into trackable steps. This should follow the standard Markdown checklist format with "- [ ]" for incomplete items.`
-		: ""
-}
-
-
-
-### Mode Switching
-
-When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
-</IMPORTANT>
-
-## Quality Standards
-
-You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
-
-Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
-
----
-
-**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
-
-Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
-</explicit_instructions>\n
-`
+/**
+ * Generates the deep-planning slash command response with model-family-aware variant selection
+ * @param focusChainSettings Optional focus chain settings to include in the prompt
+ * @param providerInfo Optional API provider info for model family detection
+ * @returns The deep-planning prompt string with appropriate variant and focus chain settings applied
+ */
+export const deepPlanningToolResponse = (focusChainSettings?: { enabled: boolean }, providerInfo?: ApiProviderInfo) => {
+	return getDeepPlanningPrompt(focusChainSettings, providerInfo)
 }

src/core/prompts/commands/deep-planning/index.ts

@@ -0,0 +1,37 @@
+import type { ApiProviderInfo } from "@/core/api"
+import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
+import { getDeepPlanningRegistry } from "./registry"
+
+/**
+ * Generates the deep-planning slash command response with model-family-aware variant selection
+ * @param focusChainSettings Optional focus chain settings to include in the prompt
+ * @param providerInfo Optional API provider info for model family detection
+ * @returns The deep-planning prompt string with appropriate variant and focus chain settings applied
+ */
+export function getDeepPlanningPrompt(focusChainSettings?: { enabled: boolean }, providerInfo?: ApiProviderInfo): string {
+	// Create context for variant selection
+	const context: SystemPromptContext = {
+		providerInfo: providerInfo || ({} as ApiProviderInfo),
+		ide: "vscode",
+	}
+
+	// Get the appropriate variant from registry
+	const registry = getDeepPlanningRegistry()
+	const variant = registry.get(context)
+
+	// Apply focus chain settings to template
+	let template = variant.template
+
+	// Replace the FOCUS_CHAIN_PARAM placeholder with actual content or empty string
+	const focusChainParam = focusChainSettings?.enabled
+		? `**Task Progress Parameter:**
+When creating the new task, you must include a task_progress parameter that breaks down the implementation into trackable steps. This parameter should be included inside the tool call, but not located inside of other content/argument blocks. This should follow the standard Markdown checklist format with "- [ ]" for incomplete items.`
+		: ""
+
+	template = template.replace("{{FOCUS_CHAIN_PARAM}}", focusChainParam)
+
+	return template
+}
+
+// Export types for external use
+export type { DeepPlanningRegistry, DeepPlanningVariant } from "./types"

src/core/prompts/commands/deep-planning/registry.ts

@@ -0,0 +1,92 @@
+import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
+import type { DeepPlanningVariant, DeepPlanningRegistry as IDeepPlanningRegistry } from "./types"
+import { createAnthropicVariant, createGeminiVariant, createGenericVariant, createGPT5Variant } from "./variants"
+
+/**
+ * Singleton registry for managing deep-planning prompt variants
+ * Selects appropriate variant based on model family detection
+ */
+class DeepPlanningRegistry implements IDeepPlanningRegistry {
+	private static instance: DeepPlanningRegistry | null = null
+	private variants: Map<string, DeepPlanningVariant> = new Map()
+	private genericVariant: DeepPlanningVariant
+
+	private constructor() {
+		// Initialize all variants
+		this.registerVariant(createAnthropicVariant())
+		this.registerVariant(createGeminiVariant())
+		this.registerVariant(createGPT5Variant())
+
+		// Generic variant must be registered last as fallback
+		const genericVariant = createGenericVariant()
+		this.registerVariant(genericVariant)
+		this.genericVariant = genericVariant
+	}
+
+	/**
+	 * Get the singleton instance of the registry
+	 */
+	public static getInstance(): DeepPlanningRegistry {
+		if (!DeepPlanningRegistry.instance) {
+			DeepPlanningRegistry.instance = new DeepPlanningRegistry()
+		}
+		return DeepPlanningRegistry.instance
+	}
+
+	/**
+	 * Register a new variant in the registry
+	 */
+	public register(variant: DeepPlanningVariant): void {
+		this.registerVariant(variant)
+	}
+
+	/**
+	 * Internal method to register a variant
+	 */
+	private registerVariant(variant: DeepPlanningVariant): void {
+		this.variants.set(variant.id, variant)
+	}
+
+	/**
+	 * Get the appropriate variant based on the system prompt context
+	 * Uses matcher functions to determine which variant to use
+	 * Falls back to generic variant if no match or on error
+	 */
+	public get(context: SystemPromptContext): DeepPlanningVariant {
+		try {
+			// Try each variant's matcher function (except generic which is last)
+			for (const variant of this.variants.values()) {
+				// Skip generic variant in iteration (it's the fallback)
+				if (variant.id === "generic") {
+					continue
+				}
+
+				// Test if this variant matches the context
+				if (variant.matcher(context)) {
+					return variant
+				}
+			}
+
+			// No match found, return generic variant
+			return this.genericVariant
+		} catch (error) {
+			// On any error, safely fall back to generic variant
+			console.warn("Error selecting deep-planning variant, falling back to generic:", error)
+			return this.genericVariant
+		}
+	}
+
+	/**
+	 * Get all registered variants
+	 */
+	public getAll(): DeepPlanningVariant[] {
+		return Array.from(this.variants.values())
+	}
+}
+
+/**
+ * Export singleton instance getter
+ */
+export function getDeepPlanningRegistry(): DeepPlanningRegistry {
+	return DeepPlanningRegistry.getInstance()
+}

src/core/prompts/commands/deep-planning/types.ts

@@ -0,0 +1,38 @@
+import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
+
+/**
+ * Configuration for a deep-planning prompt variant
+ */
+export interface DeepPlanningVariant {
+	/** Unique identifier for this variant (e.g., "anthropic", "gemini", "gpt-5", "generic") */
+	id: string
+
+	/** Human-readable description of this variant */
+	description: string
+
+	/** The model family this variant is designed for */
+	family: string
+
+	/** Version number for this variant */
+	version: number
+
+	/** Matcher function to determine if this variant should be used */
+	matcher: (context: SystemPromptContext) => boolean
+
+	/** The complete prompt template string */
+	template: string
+}
+
+/**
+ * Registry for deep-planning prompt variants
+ */
+export interface DeepPlanningRegistry {
+	/** Get the appropriate variant based on context */
+	get(context: SystemPromptContext): DeepPlanningVariant
+
+	/** Register a new variant */
+	register(variant: DeepPlanningVariant): void
+
+	/** Get all registered variants */
+	getAll(): DeepPlanningVariant[]
+}

src/core/prompts/commands/deep-planning/variants/anthropic.ts

@@ -0,0 +1,277 @@
+import { isAnthropicModelId } from "@utils/model-utils"
+import { getShell } from "@utils/shell"
+import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
+import type { DeepPlanningVariant } from "../types"
+
+/**
+ * Creates the Anthropic Claude variant for deep-planning prompt
+ * This variant is optimized for Claude models
+ */
+export function createAnthropicVariant(): DeepPlanningVariant {
+	return {
+		id: "anthropic",
+		description: "Deep-planning variant optimized for Anthropic Claude models",
+		family: "anthropic",
+		version: 1,
+		matcher: (context: SystemPromptContext) => {
+			const modelId = context.providerInfo?.model?.id
+			if (!modelId) {
+				return false
+			}
+			return isAnthropicModelId(modelId)
+		},
+		template: generateTemplate(),
+	}
+}
+
+/**
+ * Generates the deep-planning template with shell-specific commands
+ */
+function generateTemplate(): string {
+	const detectedShell = getShell()
+
+	// FIXME: detectedShell returns a non-string value on some Windows machines
+	let isPowerShell = false
+	try {
+		isPowerShell =
+			detectedShell != null &&
+			typeof detectedShell === "string" &&
+			(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
+	} catch {}
+
+	return `<explicit_instructions type="deep-planning">
+Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
+
+Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
+
+## STEP 1: Silent Investigation
+
+<important>
+until explicitly instructed by the user to proceed with coding.
+You must thoroughly understand the existing codebase before proposing any changes.
+Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
+</important>
+
+### Required Research Activities
+You must use the read_file tool to examine relevant source files, configuration files, and documentation. You must use terminal commands to gather information about the codebase structure and patterns. All terminal output must be piped to cat for visibility.
+
+### Essential Terminal Commands
+First, determine the language(s) used in the codebase, then execute these commands to build your understanding. You must tailor them to the codebase and ensure the output is not overly verbose. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. These are only examples, the exact commands will differ depending on the codebase.
+
+${
+	isPowerShell
+		? // PowerShell-specific commands
+
+			`# Discover project structure and file types
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
+
+# Find all class and function definitions
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
+
+# Analyze import patterns and dependencies
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
+
+# Find dependency manifests
+Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
+
+# Identify technical debt and TODOs
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
+`
+		: // bash/zsh-specific commands
+			`# Discover project structure and file types
+find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
+
+# Find all class and function definitions
+grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+
+# Analyze import patterns and dependencies
+grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
+
+# Find dependency manifests
+find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
+
+# Identify technical debt and TODOs
+grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+`
+}
+
+
+## STEP 2: Discussion and Questions
+
+Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
+
+**Ask questions only when necessary for:**
+- Clarifying ambiguous requirements or specifications
+- Choosing between multiple equally valid implementation approaches  
+- Confirming assumptions about existing system behavior or constraints
+- Understanding preferences for specific technical decisions that will affect the implementation
+
+Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
+
+## STEP 3: Create Implementation Plan Document
+
+Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
+
+### Document Structure Requirements
+
+Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
+
+
+# Implementation Plan
+
+[Overview]
+Single sentence describing the overall goal.
+
+Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
+
+[Types]  
+Single sentence describing the type system changes.
+
+Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
+
+[Files]
+Single sentence describing file modifications.
+
+Detailed breakdown:
+- New files to be created (with full paths and purpose)
+- Existing files to be modified (with specific changes)  
+- Files to be deleted or moved
+- Configuration file updates
+
+[Functions]
+Single sentence describing function modifications.
+
+Detailed breakdown:
+- New functions (name, signature, file path, purpose)
+- Modified functions (exact name, current file path, required changes)
+- Removed functions (name, file path, reason, migration strategy)
+
+[Classes]
+Single sentence describing class modifications.
+
+Detailed breakdown:
+- New classes (name, file path, key methods, inheritance)
+- Modified classes (exact name, file path, specific modifications)
+- Removed classes (name, file path, replacement strategy)
+
+[Dependencies]
+Single sentence describing dependency modifications.
+
+Details of new packages, version changes, and integration requirements.
+
+[Testing]
+Single sentence describing testing approach.
+
+Test file requirements, existing test modifications, and validation strategies.
+
+[Implementation Order]
+Single sentence describing the implementation sequence.
+
+Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
+
+
+## STEP 4: Create Implementation Task
+
+Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
+
+### Task Creation Requirements
+
+Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
+
+**Plan Document Navigation Commands:**
+The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
+
+${
+	isPowerShell
+		? `
+# Read Overview section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Types section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Files section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Functions section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Classes section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Dependencies section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Testing section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Implementation Order section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
+`
+		: `
+# Read Overview section
+sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Types section  
+sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Files section
+sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Functions section
+sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Classes section
+sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Dependencies section
+sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Testing section
+sed -n '/\\[Testing\\]/,/\\[Implementation Order\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Implementation Order section
+sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
+`
+}
+
+
+**Task Progress Format:**
+<IMPORTANT>
+You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
+
+
+task_progress Items:
+- [ ] Step 1: Brief description of first implementation step
+- [ ] Step 2: Brief description of second implementation step  
+- [ ] Step 3: Brief description of third implementation step
+- [ ] Step N: Brief description of final implementation step
+
+
+You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
+
+Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
+
+{{FOCUS_CHAIN_PARAM}}
+
+
+
+### Mode Switching
+
+When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
+</IMPORTANT>
+
+## Quality Standards
+
+You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
+
+Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
+
+---
+
+**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
+
+Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
+</explicit_instructions>
+`
+}

src/core/prompts/commands/deep-planning/variants/gemini.ts

@@ -0,0 +1,285 @@
+import { isGemini2dot5ModelFamily } from "@utils/model-utils"
+import { getShell } from "@utils/shell"
+import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
+import type { DeepPlanningVariant } from "../types"
+
+/**
+ * Creates the Google Gemini 2.5 variant for deep-planning prompt
+ * This variant is optimized for Gemini 2.5 models
+ */
+export function createGeminiVariant(): DeepPlanningVariant {
+	return {
+		id: "gemini",
+		description: "Deep-planning variant optimized for Google Gemini 2.5 models",
+		family: "gemini",
+		version: 1,
+		matcher: (context: SystemPromptContext) => {
+			const modelId = context.providerInfo?.model?.id
+			if (!modelId) {
+				return false
+			}
+			return isGemini2dot5ModelFamily(modelId)
+		},
+		template: generateTemplate(),
+	}
+}
+
+/**
+ * Generates the deep-planning template with shell-specific commands
+ */
+function generateTemplate(): string {
+	const detectedShell = getShell()
+
+	// FIXME: detectedShell returns a non-string value on some Windows machines
+	let isPowerShell = false
+	try {
+		isPowerShell =
+			detectedShell != null &&
+			typeof detectedShell === "string" &&
+			(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
+	} catch {}
+
+	return `<explicit_instructions type="deep-planning">
+Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
+
+Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
+
+## STEP 1: Silent Investigation
+
+<important>
+until explicitly instructed by the user to proceed with coding.
+You must thoroughly understand the existing codebase before proposing any changes.
+Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
+</important>
+
+### Required Research Activities
+You must first use the read_file tool to examine several source files, configuration files, and documentation to better inform subsequent research steps. You should only use read_file to prepare for more granular searching. Use this tool to determine the language(s) used in the codebase, and to identify the domain(s) relevant to the user's request.
+
+You must then use terminal commands to gather information about the codebase structure and patterns relevant to the user's request. All terminal output must be piped to cat for visibility.
+You will tailor these commands to explore and identify key functions, classes, methods, types, and variables that are directly, or indirectly related to the task.
+These commands must be crafted to not produce exceptionally long or verbose search results. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. Carefully consider the scope of search patterns. Use the results of your read_file tool calls to tailor the commands for balanced search result lengths. If a command returns no results, you may loosen the search patterns or scope slightly. If a command returns hundreds or thousands of results, you should adjust subsequent commands to be more targeted.
+
+Execute these commands to build your understanding. Adjust subsequent commands based on the output you have received from each previous command, informing the scope and direction of your search.
+
+Here are some example commands, remember to adjust them as instructed previously:
+
+${
+	isPowerShell
+		? // PowerShell-specific commands
+			`
+# Discover project structure and file types
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
+
+# Find all class and function definitions
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
+
+# Analyze import patterns and dependencies
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
+
+# Find dependency manifests
+Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
+
+# Identify technical debt and TODOs
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
+`
+		: // bash/zsh-specific commands
+			`
+# Discover project structure and file types
+find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
+
+# Find all class and function definitions
+grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+
+# Analyze import patterns and dependencies
+grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
+
+# Find dependency manifests
+find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
+
+# Identify technical debt and TODOs
+grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+`
+}
+
+
+## STEP 2: Discussion and Questions
+
+Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
+
+**Ask questions only when necessary for:**
+- Clarifying ambiguous requirements or specifications
+- Choosing between multiple equally valid implementation approaches  
+- Confirming assumptions about existing system behavior or constraints
+- Understanding preferences for specific technical decisions that will affect the implementation
+
+Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
+
+## STEP 3: Create Implementation Plan Document
+
+Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
+
+### Document Structure Requirements
+
+Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
+
+
+# Implementation Plan
+
+[Overview]
+Single sentence describing the overall goal.
+
+Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
+
+[Types]  
+Single sentence describing the type system changes.
+
+Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
+
+[Files]
+Single sentence describing file modifications.
+
+Detailed breakdown:
+- New files to be created (with full paths and purpose)
+- Existing files to be modified (with specific changes)  
+- Files to be deleted or moved
+- Configuration file updates
+
+[Functions]
+Single sentence describing function modifications.
+
+Detailed breakdown:
+- New functions (name, signature, file path, purpose)
+- Modified functions (exact name, current file path, required changes)
+- Removed functions (name, file path, reason, migration strategy)
+
+[Classes]
+Single sentence describing class modifications.
+
+Detailed breakdown:
+- New classes (name, file path, key methods, inheritance)
+- Modified classes (exact name, file path, specific modifications)
+- Removed classes (name, file path, replacement strategy)
+
+[Dependencies]
+Single sentence describing dependency modifications.
+
+Details of new packages, version changes, and integration requirements.
+
+[Testing]
+Single sentence describing testing approach.
+
+Test file requirements, existing test modifications, and validation strategies.
+
+[Implementation Order]
+Single sentence describing the implementation sequence.
+
+Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
+
+
+## STEP 4: Create Implementation Task
+
+Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
+
+### Task Creation Requirements
+
+Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
+
+**Plan Document Navigation Commands:**
+The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
+
+${
+	isPowerShell
+		? // PowerShell-specific commands
+			`
+# Read Overview section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Types section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Files section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Functions section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Classes section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Dependencies section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Testing section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Implementation Order section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
+`
+		: // bash/zsh-specific commands
+			`
+# Read Overview section
+sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Types section  
+sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Files section
+sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Functions section
+sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Classes section
+sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Dependencies section
+sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Testing section
+sed -n '/\\[Testing\\]/,/\\[Implementation Order\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Implementation Order section
+sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
+`
+}
+
+
+**Task Progress Format:**
+<IMPORTANT>
+You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
+
+
+task_progress Items:
+- [ ] Step 1: Brief description of first implementation step
+- [ ] Step 2: Brief description of second implementation step  
+- [ ] Step 3: Brief description of third implementation step
+- [ ] Step N: Brief description of final implementation step
+
+
+You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
+
+Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
+
+{{FOCUS_CHAIN_PARAM}}
+
+
+
+### Mode Switching
+
+When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
+</IMPORTANT>
+
+## Quality Standards
+
+You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
+
+Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
+
+---
+
+**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
+
+Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
+</explicit_instructions>
+`
+}

src/core/prompts/commands/deep-planning/variants/generic.ts

@@ -0,0 +1,268 @@
+import { getShell } from "@utils/shell"
+import type { DeepPlanningVariant } from "../types"
+
+/**
+ * Creates the generic fallback variant for deep-planning prompt
+ * This variant is used when no specific model family matcher applies
+ */
+export function createGenericVariant(): DeepPlanningVariant {
+	return {
+		id: "generic",
+		description: "Generic fallback variant for deep-planning prompt, used for all models",
+		family: "generic",
+		version: 1,
+		matcher: () => true, // Always matches as fallback
+		template: generateTemplate(),
+	}
+}
+
+/**
+ * Generates the deep-planning template with shell-specific commands
+ */
+function generateTemplate(): string {
+	const detectedShell = getShell()
+
+	// FIXME: detectedShell returns a non-string value on some Windows machines
+	let isPowerShell = false
+	try {
+		isPowerShell =
+			detectedShell != null &&
+			typeof detectedShell === "string" &&
+			(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
+	} catch {}
+
+	return `<explicit_instructions type="deep-planning">
+Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
+
+Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
+
+## STEP 1: Silent Investigation
+
+<important>
+until explicitly instructed by the user to proceed with coding.
+You must thoroughly understand the existing codebase before proposing any changes.
+Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
+</important>
+
+### Required Research Activities
+You must use the read_file tool to examine relevant source files, configuration files, and documentation. You must use terminal commands to gather information about the codebase structure and patterns. All terminal output must be piped to cat for visibility.
+
+### Essential Terminal Commands
+First, determine the language(s) used in the codebase, then execute these commands to build your understanding. You must tailor them to the codebase and ensure the output is not overly verbose. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. These are only examples, the exact commands will differ depending on the codebase.
+
+${
+	isPowerShell
+		? `
+# Discover project structure and file types
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
+
+# Find all class and function definitions
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
+
+# Analyze import patterns and dependencies
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
+
+# Find dependency manifests
+Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
+
+# Identify technical debt and TODOs
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
+`
+		: `
+# Discover project structure and file types
+find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
+
+# Find all class and function definitions
+grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+
+# Analyze import patterns and dependencies
+grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
+
+# Find dependency manifests
+find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
+
+# Identify technical debt and TODOs
+grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+`
+}
+
+
+## STEP 2: Discussion and Questions
+
+Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
+
+**Ask questions only when necessary for:**
+- Clarifying ambiguous requirements or specifications
+- Choosing between multiple equally valid implementation approaches  
+- Confirming assumptions about existing system behavior or constraints
+- Understanding preferences for specific technical decisions that will affect the implementation
+
+Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
+
+## STEP 3: Create Implementation Plan Document
+
+Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
+
+### Document Structure Requirements
+
+Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
+
+
+# Implementation Plan
+
+[Overview]
+Single sentence describing the overall goal.
+
+Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
+
+[Types]  
+Single sentence describing the type system changes.
+
+Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
+
+[Files]
+Single sentence describing file modifications.
+
+Detailed breakdown:
+- New files to be created (with full paths and purpose)
+- Existing files to be modified (with specific changes)  
+- Files to be deleted or moved
+- Configuration file updates
+
+[Functions]
+Single sentence describing function modifications.
+
+Detailed breakdown:
+- New functions (name, signature, file path, purpose)
+- Modified functions (exact name, current file path, required changes)
+- Removed functions (name, file path, reason, migration strategy)
+
+[Classes]
+Single sentence describing class modifications.
+
+Detailed breakdown:
+- New classes (name, file path, key methods, inheritance)
+- Modified classes (exact name, file path, specific modifications)
+- Removed classes (name, file path, replacement strategy)
+
+[Dependencies]
+Single sentence describing dependency modifications.
+
+Details of new packages, version changes, and integration requirements.
+
+[Testing]
+Single sentence describing testing approach.
+
+Test file requirements, existing test modifications, and validation strategies.
+
+[Implementation Order]
+Single sentence describing the implementation sequence.
+
+Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
+
+
+## STEP 4: Create Implementation Task
+
+Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
+
+### Task Creation Requirements
+
+Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
+
+**Plan Document Navigation Commands:**
+The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
+
+${
+	isPowerShell
+		? `
+# Read Overview section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Types section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Files section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Functions section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Classes section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Dependencies section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Testing section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Implementation Order section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
+`
+		: `
+# Read Overview section
+sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Types section  
+sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Files section
+sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Functions section
+sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Classes section
+sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Dependencies section
+sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Testing section
+sed -n '/\\[Testing\\]/,/\\[Implementation Order\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Implementation Order section
+sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
+`
+}
+
+
+**Task Progress Format:**
+<IMPORTANT>
+You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
+
+
+task_progress Items:
+- [ ] Step 1: Brief description of first implementation step
+- [ ] Step 2: Brief description of second implementation step  
+- [ ] Step 3: Brief description of third implementation step
+- [ ] Step N: Brief description of final implementation step
+
+
+You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
+
+Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
+
+{{FOCUS_CHAIN_PARAM}}
+
+
+
+### Mode Switching
+
+When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
+</IMPORTANT>
+
+## Quality Standards
+
+You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
+
+Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
+
+---
+
+**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
+
+Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
+</explicit_instructions>
+`
+}

src/core/prompts/commands/deep-planning/variants/gpt5.ts

@@ -0,0 +1,273 @@
+import { isGPT5ModelFamily } from "@utils/model-utils"
+import { getShell } from "@utils/shell"
+import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
+import type { DeepPlanningVariant } from "../types"
+
+/**
+ * Creates the OpenAI GPT-5 variant for deep-planning prompt
+ * This variant is optimized for GPT-5 models
+ */
+export function createGPT5Variant(): DeepPlanningVariant {
+	return {
+		id: "gpt-5",
+		description: "Deep-planning variant optimized for OpenAI GPT-5 models",
+		family: "gpt-5",
+		version: 1,
+		matcher: (context: SystemPromptContext) => {
+			const modelId = context.providerInfo?.model?.id
+			if (!modelId) {
+				return false
+			}
+			return isGPT5ModelFamily(modelId)
+		},
+		template: generateTemplate(),
+	}
+}
+
+/**
+ * Generates the deep-planning template with shell-specific commands
+ */
+function generateTemplate(): string {
+	const detectedShell = getShell()
+
+	// FIXME: detectedShell returns a non-string value on some Windows machines
+	let isPowerShell = false
+	try {
+		isPowerShell =
+			detectedShell != null &&
+			typeof detectedShell === "string" &&
+			(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
+	} catch {}
+
+	return `<explicit_instructions type="deep-planning">
+Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
+
+Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
+
+## STEP 1: Silent Investigation
+
+<important>
+until explicitly instructed by the user to proceed with coding.
+You must thoroughly understand the existing codebase before proposing any changes.
+Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
+</important>
+
+### Required Research Activities
+You MUST first use the read_file tool to examine several source files, configuration files, and documentation to better inform subsequent research steps. You should only use read_file to prepare for more granular searching. Use this tool to determine the language(s) used in the codebase, and to identify the domain(s) relevant to the user's request.
+
+You must then use terminal commands to gather information about the codebase structure and patterns relevant to the user's request. All terminal output must be piped to cat for visibility.
+You will tailor these commands to explore and identify key functions, classes, methods, types, and variables that are directly, or indirectly related to the task.
+These commands must be crafted to not produce exceptionally long or verbose search results. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. Carefully consider the scope of search patterns. Use the results of your read_file tool calls to tailor the commands for balanced search result lengths. If a command returns no results, you may loosen the search patterns or scope slightly. If a command returns hundreds or thousands of results, you should adjust subsequent commands to be more targeted.
+Execute these commands to build your understanding. Adjust subsequent commands based on the output you have recieved from each previous command, informing the scope and direction of your search.
+You should only execute one command at a time for the first several commands. Do not chain search commands until you have executed and interpreted the results of several search commands.
+
+Here are some example commands, remember to adjust them as instructed previously:
+${
+	isPowerShell
+		? // PowerShell-specific commands
+			`
+# Discover project structure and file types
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
+
+# Find all class and function definitions
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
+
+# Analyze import patterns and dependencies
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
+
+# Find dependency manifests
+Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
+
+# Identify technical debt and TODOs
+Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
+`
+		: // bash/zsh-specific commands
+			`
+# Discover project structure and file types
+find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
+
+# Find all class and function definitions
+grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+
+# Analyze import patterns and dependencies
+grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
+
+# Find dependency manifests
+find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
+
+# Identify technical debt and TODOs
+grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
+`
+}
+
+
+## STEP 2: Discussion and Questions
+
+Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
+
+**Ask questions only when necessary for:**
+- Clarifying ambiguous requirements or specifications
+- Choosing between multiple equally valid implementation approaches  
+- Confirming assumptions about existing system behavior or constraints
+- Understanding preferences for specific technical decisions that will affect the implementation
+
+Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
+
+## STEP 3: Create Implementation Plan Document
+
+Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
+
+### Document Structure Requirements
+
+Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
+
+
+# Implementation Plan
+
+[Overview]
+Single sentence describing the overall goal.
+
+Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
+
+[Types]  
+Single sentence describing the type system changes.
+
+Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
+
+[Files]
+Single sentence describing file modifications.
+
+Detailed breakdown:
+- New files to be created (with full paths and purpose)
+- Existing files to be modified (with specific changes)  
+- Files to be deleted or moved
+- Configuration file updates
+
+[Functions]
+Single sentence describing function modifications.
+
+Detailed breakdown:
+- New functions (name, signature, file path, purpose)
+- Modified functions (exact name, current file path, required changes)
+- Removed functions (name, file path, reason, migration strategy)
+
+[Classes]
+Single sentence describing class modifications.
+
+Detailed breakdown:
+- New classes (name, file path, key methods, inheritance)
+- Modified classes (exact name, file path, specific modifications)
+- Removed classes (name, file path, replacement strategy)
+
+[Dependencies]
+Single sentence describing dependency modifications.
+
+Details of new packages, version changes, and integration requirements.
+
+[Implementation Order]
+Single sentence describing the implementation sequence.
+
+Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
+
+
+## STEP 4: Create Implementation Task
+
+Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
+
+### Task Creation Requirements
+
+Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
+
+**Plan Document Navigation Commands:**
+The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
+
+${
+	isPowerShell
+		? // PowerShell-specific commands
+			`
+# Read Overview section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Types section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Files section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Functions section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Classes section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Dependencies section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
+
+# Read Implementation Order section
+$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
+`
+		: // bash/zsh-specific commands
+			`
+# Read Overview section
+sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Types section  
+sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Files section
+sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Functions section
+sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Classes section
+sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Dependencies section
+sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
+
+# Read Implementation Order section
+sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
+`
+}
+
+
+**Task Progress Format:**
+<IMPORTANT>
+You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
+
+
+task_progress Items:
+- [ ] Step 1: Brief description of first implementation step
+- [ ] Step 2: Brief description of second implementation step  
+- [ ] Step 3: Brief description of third implementation step
+- [ ] Step N: Brief description of final implementation step
+
+
+You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
+
+Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
+
+{{FOCUS_CHAIN_PARAM}}
+
+
+
+### Mode Switching
+
+When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
+</IMPORTANT>
+
+## Quality Standards
+
+You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
+
+Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
+
+---
+
+**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
+
+Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
+</explicit_instructions>
+`
+}

src/core/prompts/commands/deep-planning/variants/index.ts

@@ -0,0 +1,8 @@
+/**
+ * Export for all deep-planning prompt variants
+ */
+
+export { createAnthropicVariant } from "./anthropic"
+export { createGeminiVariant } from "./gemini"
+export { createGenericVariant } from "./generic"
+export { createGPT5Variant } from "./gpt5"

src/core/prompts/system-prompt/__tests__/__snapshots__/anthropic_claude_sonnet_4-basic.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -182,7 +182,7 @@ Description: Fetches content from a specified URL and processes into markdown
 - This tool is read-only and does not modify any files
 Parameters:
 - url: (required) The URL to fetch content from
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <web_fetch>
 <url>https://example.com/docs</url>
@@ -195,7 +195,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -214,7 +214,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -227,7 +227,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -454,16 +454,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -582,32 +597,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, use the browser, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/anthropic_claude_sonnet_4-no-browser.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -148,7 +148,7 @@ Description: Fetches content from a specified URL and processes into markdown
 - This tool is read-only and does not modify any files
 Parameters:
 - url: (required) The URL to fetch content from
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <web_fetch>
 <url>https://example.com/docs</url>
@@ -161,7 +161,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -180,7 +180,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -193,7 +193,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -420,16 +420,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -548,32 +563,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/anthropic_claude_sonnet_4-no-mcp.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -182,7 +182,7 @@ Description: Fetches content from a specified URL and processes into markdown
 - This tool is read-only and does not modify any files
 Parameters:
 - url: (required) The URL to fetch content from
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <web_fetch>
 <url>https://example.com/docs</url>
@@ -195,7 +195,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -214,7 +214,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -227,7 +227,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -454,16 +454,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -562,32 +577,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, use the browser, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/cline_claude_4_5_sonnet-basic.snap

@@ -6,16 +6,23 @@ You have access to a set of tools that are executed upon the user's approval. Yo
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.
 
 ====
 

src/core/prompts/system-prompt/__tests__/__snapshots__/cline_claude_4_5_sonnet-no-browser.snap

@@ -6,16 +6,23 @@ You have access to a set of tools that are executed upon the user's approval. Yo
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.
 
 ====
 

src/core/prompts/system-prompt/__tests__/__snapshots__/cline_claude_4_5_sonnet-no-mcp.snap

@@ -6,16 +6,23 @@ You have access to a set of tools that are executed upon the user's approval. Yo
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.
 
 ====
 

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_3-basic.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -177,7 +177,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -196,7 +196,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -209,7 +209,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -436,16 +436,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -564,32 +579,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, use the browser, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_3-no-browser.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -143,7 +143,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -162,7 +162,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -175,7 +175,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -402,16 +402,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -530,32 +545,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_3-no-mcp.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -177,7 +177,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -196,7 +196,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -209,7 +209,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -436,16 +436,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -544,32 +559,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, use the browser, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_5-basic.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -182,7 +182,7 @@ Description: Fetches content from a specified URL and processes into markdown
 - This tool is read-only and does not modify any files
 Parameters:
 - url: (required) The URL to fetch content from
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <web_fetch>
 <url>https://example.com/docs</url>
@@ -195,7 +195,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -214,7 +214,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -227,7 +227,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -454,16 +454,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -582,32 +597,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, use the browser, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_5-no-browser.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -148,7 +148,7 @@ Description: Fetches content from a specified URL and processes into markdown
 - This tool is read-only and does not modify any files
 Parameters:
 - url: (required) The URL to fetch content from
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <web_fetch>
 <url>https://example.com/docs</url>
@@ -161,7 +161,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -180,7 +180,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -193,7 +193,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -420,16 +420,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -548,32 +563,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_5-no-mcp.snap

@@ -42,7 +42,7 @@ Usage:
 Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string. Do NOT use this tool to list the contents of a directory. Only use this tool on files.
 Parameters:
 - path: (required) The path of the file to read (relative to the current working directory /test/project)
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <read_file>
 <path>File path here</path>
@@ -54,7 +54,7 @@ Description: Request to write content to a file at the specified path. If the fi
 Parameters:
 - path: (required) The path of the file to write to (relative to the current working directory /test/project)
 - content: (required) The content to write to the file. ALWAYS provide the COMPLETE intended content of the file, without any truncation or omissions. You MUST include ALL parts of the file, even if they haven't been modified.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <write_to_file>
 <path>File path here</path>
@@ -90,7 +90,7 @@ Parameters:
   4. Special operations:
      * To move code: Use two SEARCH/REPLACE blocks (one to delete from original + one to insert at new location)
      * To delete code: Use empty REPLACE section
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <replace_in_file>
 <path>File path here</path>
@@ -104,7 +104,7 @@ Parameters:
 - path: (required) The path of the directory to search in (relative to the current working directory /test/project). This directory will be recursively searched.
 - regex: (required) The regular expression pattern to search for. Uses Rust regex syntax.
 - file_pattern: (optional) Glob pattern to filter files (e.g., '*.ts' for TypeScript files). If not provided, it will search all files (*).
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <search_files>
 <path>Directory path here</path>
@@ -118,7 +118,7 @@ Description: Request to list files and directories within the specified director
 Parameters:
 - path: (required) The path of the directory to list contents for (relative to the current working directory /test/project)
 - recursive: (optional) Whether to list files recursively. Use true for recursive listing, false or omit for top-level only.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_files>
 <path>Directory path here</path>
@@ -130,7 +130,7 @@ Usage:
 Description: Request to list definition names (classes, functions, methods, etc.) used in source code files at the top level of the specified directory. This tool provides insights into the codebase structure and important constructs, encapsulating high-level concepts and relationships that are crucial for understanding the overall architecture.
 Parameters:
 - path: (required) The path of the directory (relative to the current working directory /test/project) to list top level source code definitions for.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <list_code_definition_names>
 <path>Directory path here</path>
@@ -182,7 +182,7 @@ Description: Fetches content from a specified URL and processes into markdown
 - This tool is read-only and does not modify any files
 Parameters:
 - url: (required) The URL to fetch content from
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <web_fetch>
 <url>https://example.com/docs</url>
@@ -195,7 +195,7 @@ Parameters:
 - server_name: (required) The name of the MCP server providing the tool
 - tool_name: (required) The name of the tool to execute
 - arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <use_mcp_tool>
 <server_name>server name here</server_name>
@@ -214,7 +214,7 @@ Description: Request to access a resource provided by a connected MCP server. Re
 Parameters:
 - server_name: (required) The name of the MCP server providing the resource
 - uri: (required) The URI identifying the specific resource to access
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <access_mcp_resource>
 <server_name>server name here</server_name>
@@ -227,7 +227,7 @@ Description: Ask the user a question to gather additional information needed to
 Parameters:
 - question: (required) The question to ask the user. This should be a clear, specific question that addresses the information you need.
 - options: (optional) An array of 2-5 options for the user to choose from. Each option should be a string describing a possible answer. You may not always need to provide options, but it may be helpful in many cases where it can save the user from having to type out a response manually. IMPORTANT: NEVER include an option to toggle to Act mode, as this would be something you need to direct the user to do manually themselves if needed.
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)
+- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
 Usage:
 <ask_followup_question>
 <question>Your question here</question>
@@ -454,16 +454,31 @@ By waiting for and carefully considering the user's response after each tool use
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
 
 ====
 
@@ -562,32 +577,6 @@ In each user message, the environment_details will specify the current mode. The
 
 ====
 
-UPDATING TASK PROGRESS
-
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
-
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
-====
-
 CAPABILITIES
 
 - You have access to tools that let you execute CLI commands on the user's computer, list files, view source code definitions, regex search, use the browser, read and edit files, and ask follow-up questions. These tools help you effectively accomplish a wide range of tasks, such as writing code, making edits or improvements to existing files, understanding the current state of a project, performing system operations, and much more.

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_5_codex-basic.snap

@@ -6,16 +6,23 @@ You have access to a set of tools that are executed upon the user's approval. Yo
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.
 
 ====
 

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_5_codex-no-browser.snap

@@ -6,16 +6,23 @@ You have access to a set of tools that are executed upon the user's approval. Yo
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.
 
 ====
 

src/core/prompts/system-prompt/__tests__/__snapshots__/openai_gpt_5_codex-no-mcp.snap

@@ -6,16 +6,23 @@ You have access to a set of tools that are executed upon the user's approval. Yo
 
 ====
 
-AUTOMATIC TODO LIST MANAGEMENT
+UPDATING TASK PROGRESS
 
-The system automatically manages todo lists to help track task progress:
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
 - Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.
 
 ====
 

src/core/prompts/system-prompt/__tests__/__snapshots__/zai_glm_4_6-basic.snap

@@ -128,6 +128,30 @@ Include options/trade-offs when helpful, ask if plan matches, then add the exact
 <task_progress>Checklist here (If you have presented the user with concrete steps or requirements, you can optionally include a todo list outlining these steps.)</task_progress>
 </plan_mode_respond>
 
+## UPDATING TASK PROGRESS
+
+Each tool supports an optional task_progress parameter for maintaining a Markdown checklist of your progress. Use it to show completed and remaining steps throughout a task.
+
+- Normally, skip task_progress during PLAN MODE until the plan is approved and you enter ACT MODE.
+- Use standard Markdown checkboxes: - [ ] (incomplete) and - [x] (complete).
+- Include the full checklist of meaningful milestones—not low-level technical steps.
+- Update the checklist whenever progress is made; rewrite it if scope or priorities change.
+- When adding the checklist for the first time, mark the current step as completed if it was just accomplished.
+- Short checklists are fine for simple tasks; keep longer ones concise and readable.
+- task_progress must be included as a parameter, not as a standalone tool call.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>    <- NOTE THIS IS ALWAYS A PARAMETER INSIDE THE TOOL CALL
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
+
 ## RULES
 
 - Accomplish the user's task; avoid back-and-forth conversation.
@@ -253,17 +277,6 @@ You have access to two tools for working with files: **write_to_file** and **rep
 5. Once the file has been edited with either write_to_file or replace_in_file, the system will provide you with the final state of the modified file. Use this updated content as the reference point for any subsequent SEARCH/REPLACE operations, since it reflects any auto-formatting or user-applied changes.
 By thoughtfully selecting between write_to_file and replace_in_file, you can make your file editing process smoother, safer, and more efficient.
 
-## AUTOMATIC TODO LIST MANAGEMENT
-
-The system automatically manages todo lists to help track task progress:
-
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
-- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
-
 ## MCP SERVERS
 
 The Model Context Protocol (MCP) enables communication between the system and locally running MCP servers that provide additional tools and resources to extend your capabilities.
@@ -283,30 +296,6 @@ When a server is connected, you can use the server's tools via the `use_mcp_tool
       "properties": {}
     }
 
-## UPDATING TASK PROGRESS
-
-Each tool supports an optional task_progress parameter for maintaining a Markdown checklist of your progress. Use it to show completed and remaining steps throughout a task.
-
-- Normally, skip task_progress during PLAN MODE until the plan is approved and you enter ACT MODE.
-- Use standard Markdown checkboxes: - [ ] (incomplete) and - [x] (complete).
-- Include the full checklist of meaningful milestones—not low-level technical steps.
-- Update the checklist whenever progress is made; rewrite it if scope or priorities change.
-- When adding the checklist for the first time, mark the current step as completed if it was just accomplished.
-- Short checklists are fine for simple tasks; keep longer ones concise and readable.
-- task_progress must be included as a parameter, not as a standalone tool call.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>    <- NOTE THIS IS ALWAYS A PARAMETER INSIDE THE TOOL CALL
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
 ## SYSTEM INFORMATION
 
 Operating System: macOS

src/core/prompts/system-prompt/__tests__/__snapshots__/zai_glm_4_6-no-browser.snap

@@ -128,6 +128,30 @@ Include options/trade-offs when helpful, ask if plan matches, then add the exact
 <task_progress>Checklist here (If you have presented the user with concrete steps or requirements, you can optionally include a todo list outlining these steps.)</task_progress>
 </plan_mode_respond>
 
+## UPDATING TASK PROGRESS
+
+Each tool supports an optional task_progress parameter for maintaining a Markdown checklist of your progress. Use it to show completed and remaining steps throughout a task.
+
+- Normally, skip task_progress during PLAN MODE until the plan is approved and you enter ACT MODE.
+- Use standard Markdown checkboxes: - [ ] (incomplete) and - [x] (complete).
+- Include the full checklist of meaningful milestones—not low-level technical steps.
+- Update the checklist whenever progress is made; rewrite it if scope or priorities change.
+- When adding the checklist for the first time, mark the current step as completed if it was just accomplished.
+- Short checklists are fine for simple tasks; keep longer ones concise and readable.
+- task_progress must be included as a parameter, not as a standalone tool call.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>    <- NOTE THIS IS ALWAYS A PARAMETER INSIDE THE TOOL CALL
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
+
 ## RULES
 
 - Accomplish the user's task; avoid back-and-forth conversation.
@@ -250,17 +274,6 @@ You have access to two tools for working with files: **write_to_file** and **rep
 5. Once the file has been edited with either write_to_file or replace_in_file, the system will provide you with the final state of the modified file. Use this updated content as the reference point for any subsequent SEARCH/REPLACE operations, since it reflects any auto-formatting or user-applied changes.
 By thoughtfully selecting between write_to_file and replace_in_file, you can make your file editing process smoother, safer, and more efficient.
 
-## AUTOMATIC TODO LIST MANAGEMENT
-
-The system automatically manages todo lists to help track task progress:
-
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
-- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
-
 ## MCP SERVERS
 
 The Model Context Protocol (MCP) enables communication between the system and locally running MCP servers that provide additional tools and resources to extend your capabilities.
@@ -280,30 +293,6 @@ When a server is connected, you can use the server's tools via the `use_mcp_tool
       "properties": {}
     }
 
-## UPDATING TASK PROGRESS
-
-Each tool supports an optional task_progress parameter for maintaining a Markdown checklist of your progress. Use it to show completed and remaining steps throughout a task.
-
-- Normally, skip task_progress during PLAN MODE until the plan is approved and you enter ACT MODE.
-- Use standard Markdown checkboxes: - [ ] (incomplete) and - [x] (complete).
-- Include the full checklist of meaningful milestones—not low-level technical steps.
-- Update the checklist whenever progress is made; rewrite it if scope or priorities change.
-- When adding the checklist for the first time, mark the current step as completed if it was just accomplished.
-- Short checklists are fine for simple tasks; keep longer ones concise and readable.
-- task_progress must be included as a parameter, not as a standalone tool call.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>    <- NOTE THIS IS ALWAYS A PARAMETER INSIDE THE TOOL CALL
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
 ## SYSTEM INFORMATION
 
 Operating System: macOS

src/core/prompts/system-prompt/__tests__/__snapshots__/zai_glm_4_6-no-mcp.snap

@@ -100,6 +100,30 @@ Include options/trade-offs when helpful, ask if plan matches, then add the exact
 <task_progress>Checklist here (If you have presented the user with concrete steps or requirements, you can optionally include a todo list outlining these steps.)</task_progress>
 </plan_mode_respond>
 
+## UPDATING TASK PROGRESS
+
+Each tool supports an optional task_progress parameter for maintaining a Markdown checklist of your progress. Use it to show completed and remaining steps throughout a task.
+
+- Normally, skip task_progress during PLAN MODE until the plan is approved and you enter ACT MODE.
+- Use standard Markdown checkboxes: - [ ] (incomplete) and - [x] (complete).
+- Include the full checklist of meaningful milestones—not low-level technical steps.
+- Update the checklist whenever progress is made; rewrite it if scope or priorities change.
+- When adding the checklist for the first time, mark the current step as completed if it was just accomplished.
+- Short checklists are fine for simple tasks; keep longer ones concise and readable.
+- task_progress must be included as a parameter, not as a standalone tool call.
+
+Example:
+<execute_command>
+<command>npm install react</command>
+<requires_approval>false</requires_approval>
+<task_progress>    <- NOTE THIS IS ALWAYS A PARAMETER INSIDE THE TOOL CALL
+- [x] Set up project structure
+- [x] Install dependencies
+- [ ] Create components
+- [ ] Test application
+</task_progress>
+</execute_command>
+
 ## RULES
 
 - Accomplish the user's task; avoid back-and-forth conversation.
@@ -225,41 +249,6 @@ You have access to two tools for working with files: **write_to_file** and **rep
 5. Once the file has been edited with either write_to_file or replace_in_file, the system will provide you with the final state of the modified file. Use this updated content as the reference point for any subsequent SEARCH/REPLACE operations, since it reflects any auto-formatting or user-applied changes.
 By thoughtfully selecting between write_to_file and replace_in_file, you can make your file editing process smoother, safer, and more efficient.
 
-## AUTOMATIC TODO LIST MANAGEMENT
-
-The system automatically manages todo lists to help track task progress:
-
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
-- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details
-
-## UPDATING TASK PROGRESS
-
-Each tool supports an optional task_progress parameter for maintaining a Markdown checklist of your progress. Use it to show completed and remaining steps throughout a task.
-
-- Normally, skip task_progress during PLAN MODE until the plan is approved and you enter ACT MODE.
-- Use standard Markdown checkboxes: - [ ] (incomplete) and - [x] (complete).
-- Include the full checklist of meaningful milestones—not low-level technical steps.
-- Update the checklist whenever progress is made; rewrite it if scope or priorities change.
-- When adding the checklist for the first time, mark the current step as completed if it was just accomplished.
-- Short checklists are fine for simple tasks; keep longer ones concise and readable.
-- task_progress must be included as a parameter, not as a standalone tool call.
-
-Example:
-<execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>    <- NOTE THIS IS ALWAYS A PARAMETER INSIDE THE TOOL CALL
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</execute_command>
-
 ## SYSTEM INFORMATION
 
 Operating System: macOS

src/core/prompts/system-prompt/components/auto_todo.ts

@@ -1,27 +0,0 @@
-import { SystemPromptSection } from "../templates/placeholders"
-import { TemplateEngine } from "../templates/TemplateEngine"
-import type { PromptVariant, SystemPromptContext } from "../types"
-
-const TODO_LIST_TEMPLATE_TEXT = `AUTOMATIC TODO LIST MANAGEMENT
-
-The system automatically manages todo lists to help track task progress:
-
-- Every 10th API request, you will be prompted to review and update the current todo list if one exists
-- When switching from PLAN MODE to ACT MODE, you should create a comprehensive todo list for the task
-- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- The system will automatically include todo list context in your prompts when appropriate
-- Focus on creating actionable, meaningful steps rather than granular technical details`
-
-export async function getTodoListSection(variant: PromptVariant, context: SystemPromptContext): Promise<string | undefined> {
-	if (!context.focusChainSettings?.enabled) {
-		return undefined
-	}
-
-	const template = variant.componentOverrides?.[SystemPromptSection.TODO]?.template || TODO_LIST_TEMPLATE_TEXT
-
-	const templateEngine = new TemplateEngine()
-	return templateEngine.resolve(template, context, {
-		// Add any todo-specific placeholders here
-	})
-}

src/core/prompts/system-prompt/components/index.ts

@@ -1,7 +1,6 @@
 import { SystemPromptSection } from "../templates/placeholders"
 import { getActVsPlanModeSection } from "./act_vs_plan_mode"
 import { getAgentRoleSection } from "./agent_role"
-import { getTodoListSection } from "./auto_todo"
 import { getCapabilitiesSection } from "./capabilities"
 import { getCliSubagentsSection } from "./cli_subagents"
 import { getEditingFilesSection } from "./editing_files"
@@ -24,7 +23,6 @@ export function getSystemPromptComponents() {
 		{ id: SystemPromptSection.AGENT_ROLE, fn: getAgentRoleSection },
 		{ id: SystemPromptSection.SYSTEM_INFO, fn: getSystemInfo },
 		{ id: SystemPromptSection.MCP, fn: getMcp },
-		{ id: SystemPromptSection.TODO, fn: getTodoListSection },
 		{
 			id: SystemPromptSection.USER_INSTRUCTIONS,
 			fn: getUserInstructions,

src/core/prompts/system-prompt/components/task_progress.ts

@@ -1,16 +1,19 @@
+import { ModelFamily } from "@/shared/prompts"
 import { PromptVariant, SystemPromptContext, SystemPromptSection, TemplateEngine } from ".."
 
 const UPDATING_TASK_PROGRESS = `UPDATING TASK PROGRESS
 
-Every tool use supports an optional task_progress parameter that allows you to provide an updated checklist to keep the user informed of your overall progress on the task. This should be used regularly throughout the task to keep the user informed of completed and remaining steps. Before using the attempt_completion tool, ensure the final checklist item is checked off to indicate task completion.
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
 
-- You probably wouldn't use this while in PLAN mode until the user has approved your plan and switched you to ACT mode.
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
+- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
 - Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
 - Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your parameter input since this checklist will be displayed after this tool use is completed.
 - For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
 - If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
 
 Example:
 <execute_command>
@@ -24,12 +27,40 @@ Example:
 </task_progress>
 </execute_command>`
 
+const UPDATING_TASK_PROGRESS_NATIVE_NEXT_GEN = `UPDATING TASK PROGRESS
+
+You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
+
+- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
+- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
+- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
+- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
+- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
+- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
+- If a checklist is being used, be sure to update it any time a step has been completed.
+- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
+
+**How to use task_progress:**
+- include the task_progress parameter in your tool calls to provide an updated checklist
+- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
+- The task_progress parameter MUST be included as a seperate parameter in the tool, it should not be included inside other content or argument blocks.`
+
 export async function getUpdatingTaskProgress(variant: PromptVariant, context: SystemPromptContext): Promise<string | undefined> {
 	if (!context.focusChainSettings?.enabled) {
 		return undefined
 	}
 
-	const template = variant.componentOverrides?.[SystemPromptSection.TASK_PROGRESS]?.template || UPDATING_TASK_PROGRESS
+	// Check for component override first
+	if (variant.componentOverrides?.[SystemPromptSection.TASK_PROGRESS]?.template) {
+		const template = variant.componentOverrides[SystemPromptSection.TASK_PROGRESS].template
+		return new TemplateEngine().resolve(template, context, {})
+	}
+
+	// Select template based on model family
+	let template = UPDATING_TASK_PROGRESS
+	if (variant.id === ModelFamily.NATIVE_NEXT_GEN || variant.id === ModelFamily.NATIVE_GPT_5) {
+		template = UPDATING_TASK_PROGRESS_NATIVE_NEXT_GEN
+	}
 
 	return new TemplateEngine().resolve(template, context, {})
 }

src/core/prompts/system-prompt/types.ts

@@ -256,7 +256,7 @@ export interface VariantSchema {
 export const TASK_PROGRESS_PARAMETER = {
 	name: "task_progress",
 	required: false,
-	instruction: `A checklist showing task progress after this tool use is completed. (See 'Updating Task Progress' section for more details)`,
+	instruction: `A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a seperate parameter inside of the parent tool call, it must be seperate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)`,
 	usage: "Checklist here (optional)",
 	dependencies: [ClineDefaultTool.TODO],
 }

src/core/prompts/system-prompt/variants/generic/config.ts

@@ -40,7 +40,6 @@ export const config = createVariant(ModelFamily.GENERIC)
 		SystemPromptSection.EDITING_FILES,
 		SystemPromptSection.ACT_VS_PLAN,
 		SystemPromptSection.CLI_SUBAGENTS,
-		SystemPromptSection.TODO,
 		SystemPromptSection.CAPABILITIES,
 		SystemPromptSection.RULES,
 		SystemPromptSection.SYSTEM_INFO,

src/core/prompts/system-prompt/variants/generic/template.ts

@@ -6,7 +6,7 @@ export const baseTemplate = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TODO}}}
+{{${SystemPromptSection.TASK_PROGRESS}}}
 
 ====
 
@@ -26,10 +26,6 @@ export const baseTemplate = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TASK_PROGRESS}}}
-
-====
-
 {{${SystemPromptSection.CAPABILITIES}}}
 
 ====

src/core/prompts/system-prompt/variants/glm/config.ts

@@ -22,6 +22,7 @@ export const config = createVariant(ModelFamily.GLM)
 	.components(
 		SystemPromptSection.AGENT_ROLE,
 		SystemPromptSection.TOOL_USE,
+		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.RULES,
 		SystemPromptSection.ACT_VS_PLAN,
 		SystemPromptSection.CLI_SUBAGENTS,
@@ -29,7 +30,6 @@ export const config = createVariant(ModelFamily.GLM)
 		SystemPromptSection.EDITING_FILES,
 		SystemPromptSection.TODO,
 		SystemPromptSection.MCP,
-		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.SYSTEM_INFO,
 		SystemPromptSection.OBJECTIVE,
 		SystemPromptSection.USER_INSTRUCTIONS,

src/core/prompts/system-prompt/variants/glm/template.ts

@@ -4,6 +4,7 @@ export const baseTemplate = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 {{${SystemPromptSection.TOOL_USE}}}
 
+## {{${SystemPromptSection.TASK_PROGRESS}}}
 
 ## {{${SystemPromptSection.RULES}}}
 
@@ -19,8 +20,6 @@ export const baseTemplate = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ## {{${SystemPromptSection.MCP}}}
 
-## {{${SystemPromptSection.TASK_PROGRESS}}}
-
 ## {{${SystemPromptSection.SYSTEM_INFO}}}
 
 ## {{${SystemPromptSection.OBJECTIVE}}}

src/core/prompts/system-prompt/variants/gpt-5/config.ts

@@ -31,12 +31,11 @@ export const config = createVariant(ModelFamily.GPT_5)
 	.components(
 		SystemPromptSection.AGENT_ROLE,
 		SystemPromptSection.TOOL_USE,
-		SystemPromptSection.TODO,
+		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.MCP,
 		SystemPromptSection.EDITING_FILES,
 		SystemPromptSection.ACT_VS_PLAN,
 		SystemPromptSection.CLI_SUBAGENTS,
-		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.CAPABILITIES,
 		SystemPromptSection.FEEDBACK,
 		SystemPromptSection.RULES,

src/core/prompts/system-prompt/variants/gpt-5/template.ts

@@ -3,7 +3,6 @@ import type { SystemPromptContext } from "../../types"
 
 /**
  * Base template for GPT-5 variant with structured sections
- * Removed SystemPromptSection.TASK_PROGRESS
  */
 export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
@@ -11,7 +10,7 @@ export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TODO}}}
+{{${SystemPromptSection.TASK_PROGRESS}}}
 
 ====
 
@@ -31,10 +30,6 @@ export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TASK_PROGRESS}}}
-
-====
-
 {{${SystemPromptSection.CAPABILITIES}}}
 
 ====

src/core/prompts/system-prompt/variants/native-gpt-5/config.ts

@@ -32,7 +32,7 @@ export const config = createVariant(ModelFamily.NATIVE_GPT_5)
 	.components(
 		SystemPromptSection.AGENT_ROLE,
 		SystemPromptSection.TOOL_USE,
-		SystemPromptSection.TODO,
+		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.ACT_VS_PLAN,
 		SystemPromptSection.CLI_SUBAGENTS,
 		SystemPromptSection.CAPABILITIES,

src/core/prompts/system-prompt/variants/native-gpt-5/template.ts

@@ -3,7 +3,6 @@ import type { SystemPromptContext } from "../../types"
 
 /**
  * Base template for GPT-5 variant with structured sections
- * Removed SystemPromptSection.TASK_PROGRESS
  */
 export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
@@ -11,12 +10,11 @@ export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TODO}}}
+{{${SystemPromptSection.TASK_PROGRESS}}}
 
 ====
 
 {{${SystemPromptSection.ACT_VS_PLAN}}}
-
 ====
 
 {{${SystemPromptSection.CLI_SUBAGENTS}}}

src/core/prompts/system-prompt/variants/native-next-gen/template.ts

@@ -3,7 +3,6 @@ import type { SystemPromptContext } from "../../types"
 
 /**
  * Base template for GPT-5 variant with structured sections
- * Removed SystemPromptSection.TASK_PROGRESS
  */
 export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
@@ -15,6 +14,10 @@ export const BASE = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
+{{${SystemPromptSection.TASK_PROGRESS}}}
+
+====
+
 {{${SystemPromptSection.EDITING_FILES}}}
 
 ====

src/core/prompts/system-prompt/variants/next-gen/config.ts

@@ -34,12 +34,11 @@ export const config = createVariant(ModelFamily.NEXT_GEN)
 	.components(
 		SystemPromptSection.AGENT_ROLE,
 		SystemPromptSection.TOOL_USE,
-		SystemPromptSection.TODO,
+		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.MCP,
 		SystemPromptSection.EDITING_FILES,
 		SystemPromptSection.ACT_VS_PLAN,
 		SystemPromptSection.CLI_SUBAGENTS,
-		SystemPromptSection.TASK_PROGRESS,
 		SystemPromptSection.CAPABILITIES,
 		SystemPromptSection.FEEDBACK,
 		SystemPromptSection.RULES,

src/core/prompts/system-prompt/variants/next-gen/template.ts

@@ -7,7 +7,7 @@ export const baseTemplate = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TODO}}}
+{{${SystemPromptSection.TASK_PROGRESS}}}
 
 ====
 
@@ -27,10 +27,6 @@ export const baseTemplate = `{{${SystemPromptSection.AGENT_ROLE}}}
 
 ====
 
-{{${SystemPromptSection.TASK_PROGRESS}}}
-
-====
-
 {{${SystemPromptSection.CAPABILITIES}}}
 
 ====

src/core/slash-commands/index.ts

@@ -1,5 +1,6 @@
 import { ClineRulesToggles } from "@shared/cline-rules"
 import fs from "fs/promises"
+import type { ApiProviderInfo } from "@/core/api"
 import { telemetryService } from "@/services/telemetry"
 import {
 	condenseToolResponse,
@@ -20,6 +21,7 @@ export async function parseSlashCommands(
 	globalWorkflowToggles: ClineRulesToggles,
 	ulid: string,
 	focusChainSettings?: { enabled: boolean },
+	providerInfo?: ApiProviderInfo,
 ): Promise<{ processedText: string; needsClinerulesFileCheck: boolean }> {
 	const SUPPORTED_DEFAULT_COMMANDS = ["newtask", "smol", "compact", "newrule", "reportbug", "deep-planning", "subagent"]
 
@@ -29,7 +31,7 @@ export async function parseSlashCommands(
 		compact: condenseToolResponse(focusChainSettings),
 		newrule: newRuleToolResponse(),
 		reportbug: reportBugToolResponse(),
-		"deep-planning": deepPlanningToolResponse(focusChainSettings),
+		"deep-planning": deepPlanningToolResponse(focusChainSettings, providerInfo),
 		subagent: subagentToolResponse(),
 	}
 

src/core/storage/remote-config/fetch.ts

@@ -1,5 +1,6 @@
 import axios, { AxiosRequestConfig, AxiosResponse } from "axios"
 import { Controller } from "@/core/controller"
+import { getAxiosSettings } from "@/shared/net"
 import { ClineEnv } from "../../../config"
 import { AuthService } from "../../../services/auth/AuthService"
 import { CLINE_API_ENDPOINT } from "../../../shared/cline/api"
@@ -35,6 +36,7 @@ async function fetchRemoteConfigForOrganization(organizationId: string): Promise
 				Authorization: `Bearer ${authToken}`,
 				"Content-Type": "application/json",
 			},
+			...getAxiosSettings(),
 		}
 
 		const response: AxiosResponse<{

src/core/task/focus-chain/prompts.ts

@@ -1,6 +1,6 @@
 // Prompt for initial list creation
 const initial = `
-# TODO LIST CREATION REQUIRED - ACT MODE ACTIVATED
+# task_progress CREATION REQUIRED - ACT MODE ACTIVATED
 
 **You've just switched from PLAN MODE to ACT MODE!**
 
@@ -11,7 +11,7 @@ const initial = `
 	- [ ] For tasks to be done
 	- [x] For any tasks already completed
 
-**Your todo list should include:**
+**Your todo/task_progress list should include:**
    - All major implementation steps
    - Testing and validation tasks
    - Documentation updates if needed
@@ -25,15 +25,15 @@ const initial = `
    - [ ] Test implementation
    - [ ] Document changes
 
-**Remember:** Keeping the todo list updated helps track progress and ensures nothing is missed.`
+**Remember:** Keeping the task_progress list updated helps track progress and ensures nothing is missed.`
 
 // For when recommending but not requiring a list
 const listInstructionsRecommended = `
-1. Include the task_progress parameter in your next tool call
+1. Include a todo list using the task_progress parameter in your next tool call
 2. Create a comprehensive checklist of all steps needed
 3. Use markdown format: - [ ] for incomplete, - [x] for complete
 
-**Benefits of creating a todo list now:**
+**Benefits of creating a todo/task_progress list now:**
 	- Clear roadmap for implementation
 	- Progress tracking throughout the task
 	- Nothing gets forgotten or missed
@@ -47,7 +47,7 @@ const listInstructionsRecommended = `
 - [ ] Test the implementation
 - [ ] Verify results\`\`\`
 
-Keeping the todo list updated helps track progress and ensures nothing is missed.`
+Keeping the task_progress list updated helps track progress and ensures nothing is missed.`
 
 // Prompt for reminders to update the list periodically
 const reminder = `
@@ -61,11 +61,11 @@ const reminder = `
 		- Reorder if the sequence has changed
 4. Ensure the list accurately reflects the current state
 
-**Remember:** Keeping the todo list updated helps track progress and ensures nothing is missed.`
+**Remember:** Keeping the task_progress list updated helps track progress and ensures nothing is missed.`
 
 const completed = `
 
-**🎉 EXCELLENT! All {{totalItems}} items have been completed!**
+**All {{totalItems}} items have been completed!**
 
 **Completed Items:**
 {{currentFocusChainChecklist}}
@@ -78,7 +78,7 @@ const completed = `
 **Remember:** Only use attempt_completion if you're confident the task is truly finished. If there's any remaining work, create a new focus chain list to track it.`
 
 const planModeReminder = `
-# Todo List (Optional - Plan Mode)
+# task_progress List (Optional - Plan Mode)
 
 While in PLAN MODE, if you've outlined concrete steps or requirements for the user, you may include a preliminary todo list using the task_progress parameter.
 
@@ -87,17 +87,17 @@ Reminder on how to use the task_progress parameter:
 ${reminder}`
 
 const recommended = `
-# TODO LIST RECOMMENDED
+# task_progress RECOMMENDED
 
-When starting a new task, it is recommended to create a todo list.
+When starting a new task, it is recommended to include a todo list using the task_progress parameter.
 
 ${listInstructionsRecommended}
 `
 
 const apiRequestCount = `
-# TODO LIST
+# task_progress
 
-You've made {{apiRequestCount}} API requests without a todo list. Consider creating one to track remaining work.
+You've made {{apiRequestCount}} API requests without a task_progress parameter. It is strongly recomended that you create one to track remaining work.
 
 ${reminder}
 `

src/core/task/index.ts

@@ -1358,6 +1358,14 @@ export class Task {
 				}
 			}
 
+			if (this.activeBackgroundCommand) {
+				try {
+					await this.cancelBackgroundCommand()
+				} catch (error) {
+					Logger.error("Failed to cancel background command during task abort", error)
+				}
+			}
+
 			// PHASE 4: Run TaskCancel hook
 			// This allows the hook UI to appear in the webview
 			// Use the shouldRunTaskCancelHook value we captured in Phase 1
@@ -3188,6 +3196,7 @@ export class Task {
 								globalWorkflowToggles,
 								this.ulid,
 								this.stateManager.getGlobalSettingsKey("focusChainSettings"),
+								this.getCurrentProviderInfo(),
 							)
 
 							if (needsCheck) {

src/integrations/misc/link-preview.ts

@@ -1,5 +1,6 @@
 import axios from "axios"
 import ogs from "open-graph-scraper"
+import { getAxiosSettings } from "@/shared/net"
 
 export interface OpenGraphData {
 	title?: string
@@ -94,6 +95,7 @@ export async function detectImageUrl(url: string): Promise<boolean> {
 				"User-Agent": "Mozilla/5.0 (compatible; VSCodeExtension/1.0; +https://cline.bot)",
 			},
 			timeout: 3000,
+			...getAxiosSettings(),
 		})
 
 		const contentType = response.headers["content-type"]

src/services/account/ClineAccountService.ts

@@ -9,6 +9,7 @@ import type {
 import axios, { AxiosRequestConfig, AxiosResponse } from "axios"
 import { ClineEnv } from "@/config"
 import { CLINE_API_ENDPOINT } from "@/shared/cline/api"
+import { getAxiosSettings } from "@/shared/net"
 import { AuthService } from "../auth/AuthService"
 
 export class ClineAccountService {
@@ -60,6 +61,7 @@ export class ClineAccountService {
 				"Content-Type": "application/json",
 				...config.headers,
 			},
+			...getAxiosSettings(),
 		}
 		const response: AxiosResponse<{ data?: T; error: string; success: boolean }> = await axios.request({
 			url,

src/services/auth/oca/providers/OcaAuthProvider.ts

@@ -102,7 +102,7 @@ export class OcaAuthProvider {
 			if (!idcs_url || !client_id) {
 				throw new Error("IDCS URL or Client ID are not configured")
 			}
-			const discovery = await axios.get(`${idcs_url}/.well-known/openid-configuration`, { ...getAxiosSettings() })
+			const discovery = await axios.get(`${idcs_url}/.well-known/openid-configuration`, getAxiosSettings())
 			const tokenEndpoint = discovery.data.token_endpoint
 			const params: any = {
 				grant_type: "refresh_token",
@@ -183,7 +183,7 @@ export class OcaAuthProvider {
 			}
 			const { code_verifier, nonce, redirect_uri } = entry
 			OcaAuthProvider.pkceStateMap.delete(state)
-			const discovery = await axios.get(`${idcs_url}/.well-known/openid-configuration`, { ...getAxiosSettings() })
+			const discovery = await axios.get(`${idcs_url}/.well-known/openid-configuration`, getAxiosSettings())
 			const tokenEndpoint = discovery.data.token_endpoint
 			const params: any = {
 				grant_type: "authorization_code",

src/services/auth/providers/ClineAuthProvider.ts

@@ -4,7 +4,7 @@ import { Controller } from "@/core/controller"
 import { HostProvider } from "@/hosts/host-provider"
 import { Logger } from "@/services/logging/Logger"
 import { CLINE_API_ENDPOINT } from "@/shared/cline/api"
-import { fetch } from "@/shared/net"
+import { fetch, getAxiosSettings } from "@/shared/net"
 import type { ClineAccountUserInfo, ClineAuthInfo } from "../AuthService"
 import { IAuthProvider } from "./IAuthProvider"
 
@@ -306,6 +306,7 @@ export class ClineAuthProvider implements IAuthProvider {
 				headers: {
 					Authorization: `Bearer workos:${tokenData.accessToken}`,
 				},
+				...getAxiosSettings(),
 			})
 
 			return userResponse.data.data

src/services/auth/providers/FirebaseAuthProvider.ts

@@ -5,6 +5,7 @@ import { jwtDecode } from "jwt-decode"
 import { ClineEnv, EnvironmentConfig } from "@/config"
 import { Controller } from "@/core/controller"
 import { ErrorService } from "@/services/error"
+import { getAxiosSettings } from "@/shared/net"
 import type { ClineAccountUserInfo, ClineAuthInfo } from "../AuthService"
 import { IAuthProvider } from "./IAuthProvider"
 
@@ -55,6 +56,7 @@ export class FirebaseAuthProvider implements IAuthProvider {
 				headers: {
 					Authorization: `Bearer ${idToken}`,
 				},
+				...getAxiosSettings(),
 			})
 
 			// Store user data
@@ -78,6 +80,7 @@ export class FirebaseAuthProvider implements IAuthProvider {
 				headers: {
 					"Content-Type": "application/x-www-form-urlencoded",
 				},
+				...getAxiosSettings(),
 			},
 		)
 

src/services/banner/BannerService.ts

@@ -4,6 +4,7 @@ import axios from "axios"
 import { ClineEnv } from "@/config"
 import type { Controller } from "@/core/controller"
 import { HostProvider } from "@/hosts/host-provider"
+import { getAxiosSettings } from "@/shared/net"
 import { AuthService } from "../auth/AuthService"
 import { Logger } from "../logging/Logger"
 
@@ -93,6 +94,7 @@ export class BannerService {
 				headers: {
 					"Content-Type": "application/json",
 				},
+				...getAxiosSettings(),
 			})
 
 			if (!response.data?.data?.banners) {

src/utils/env.ts

@@ -1,5 +1,5 @@
 import { EmptyRequest, StringRequest } from "@shared/proto/cline/common"
-import open from "open"
+import opn from "opn"
 import { HostProvider } from "@/hosts/host-provider"
 
 /**
@@ -40,5 +40,5 @@ export async function readTextFromClipboard(): Promise<string> {
  */
 export async function openExternal(url: string): Promise<void> {
 	console.log("Opening browser:", url)
-	await open(url)
+	await opn(url)
 }

standalone/runtime-files/vscode/enhanced-terminal.js

@@ -35,8 +35,16 @@ class StandaloneTerminalProcess extends EventEmitter {
 			// Spawn the process
 			this.childProcess = spawn(shell, shellArgs, {
 				cwd: cwd,
-				stdio: ["pipe", "pipe", "pipe"],
-				env: { ...process.env, TERM: "xterm-256color" },
+				stdio: ["ignore", "pipe", "pipe"], // Disable STDIN to prevent interactivity
+				env: {
+					...process.env,
+					TERM: "xterm-256color",
+					PAGER: "cat", // Prevent less from being used, reducing interactivity
+					EDITOR: process.env.EDITOR || "cat", // Set EDITOR if not already set
+					GIT_PAGER: "cat", // Prevent git from using less
+					SYSTEMD_PAGER: "", // Disable systemd pager
+					MANPAGER: "cat", // Disable man pager
+				},
 			})
 
 			// Track process state