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/better-cars-travel.md

@@ -1,5 +0,0 @@
----
-"claude-dev": patch
----
-
-Use http_proxy, https_proxy and no_proxy in JetBrains and CLI mode

.changeset/dull-showers-speak.md

@@ -1,5 +0,0 @@
----
-"claude-dev": patch
----
-
-Fixing the logic for Oca Token Refresh

.changeset/famous-maps-scream.md

@@ -0,0 +1,5 @@
+---
+"claude-dev": patch
+---
+
+Added change to hide the context window usage message from env details when using next gen models and before the usage has reached an elevated state

.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/large-moles-check.md

@@ -1,5 +0,0 @@
----
-"claude-dev": minor
----
-
-add new provider AIhubmix

.changeset/open-taxis-float.md

@@ -1,5 +0,0 @@
----
-"claude-dev": patch
----
-
-Fix issues where assistant message with empty content is added to conversation history

.changeset/proud-humans-itch.md

@@ -1,5 +0,0 @@
----
-"claude-dev": patch
----
-
-Fixes a bug where the checkbox shows in the model selector dropdown.

.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.

.changeset/tidy-pugs-hope.md

@@ -1,5 +0,0 @@
----
-"claude-dev": patch
----
-
-switch from defaultUserAgentProvider to customUserAgent for Bedrock

.clinerules/hooks/PostToolUse.example

@@ -1,15 +1,19 @@
 #!/usr/bin/env bash
 
-for i in {1..100}; do
+echo "PostToolUse running inside local cline/.clinerules/hooks/ directory"
+
+input=$(cat)
+echo $input | jq .
+
+for i in {1..5}; do
+  sleep 1
   echo "$i"
 done
 
-sleep 3
-
 cat <<EOF
 {
   "cancel": false,
-  "contextModification": "WORKSPACE_RULES: This is from the local bar/ workspace.",
-  "errorMessage": "PostToolUse hook custom errorMessage: foo"
+  "contextModification": "PostToolUse response from the local cline/.clinerules/hooks/ directory.",
+  "errorMessage": "PostToolUse hook custom errorMessage"
 }
 EOF

.clinerules/hooks/PreToolUse.example

@@ -1,15 +1,19 @@
 #!/usr/bin/env bash
 
-for i in {1..100}; do
+echo "PreToolUse running inside local cline/.clinerules/hooks/ directory"
+
+input=$(cat)
+echo $input | jq .
+
+for i in {1..5}; do
+  sleep 1
   echo "$i"
 done
 
-sleep 3
-
 cat <<EOF
 {
   "cancel": false,
-  "contextModification": "Make sure that all variables in python code in this repo always start with the string 'EVIEDEBUG_'.  This is important.",
-  "errorMessage": "PreToolUse hook custom errorMessage: foo"
+  "contextModification": "PreToolUse response from the local cline/.clinerules/hooks/ directory.",
+  "errorMessage": "PreToolUse hook custom errorMessage"
 }
 EOF

.clinerules/hooks/README.md

@@ -4,7 +4,7 @@
 
 Cline hooks allow you to execute custom scripts at specific points in the agentic workflow. Hooks can be placed in either:
 - **Global hooks directory**: `~/Documents/Cline/Hooks/` (applies to all workspaces)
-- **Workspace hooks directory**: `.clinerules/hooks/` (applies to specific workspace)
+- **Workspace hooks directory**: `.clinerules/hooks/` (applies to the workspace the repo is part of)
 
 Hooks run automatically when enabled.
 
@@ -20,51 +20,51 @@ Hooks run automatically when enabled.
 ### TaskStart Hook
 - **When**: Runs when a NEW task is started (not when resuming)
 - **Purpose**: Initialize task context, validate task requirements, set up environment
-- **Global Location**: `~/Documents/Cline/Hooks/TaskStart` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/TaskStart` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/TaskStart`
+- **Workspace Location**: `.clinerules/hooks/TaskStart`
 
 ### TaskResume Hook
 - **When**: Runs when an EXISTING task is resumed (after user clicks resume button)
 - **Purpose**: Validate resumed task state, restore context, check for changes since last run
-- **Global Location**: `~/Documents/Cline/Hooks/TaskResume` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/TaskResume` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/TaskResume`
+- **Workspace Location**: `.clinerules/hooks/TaskResume`
 
 ### TaskCancel Hook
-- **When**: Runs when a task is cancelled by the user (only if there's actual active work or work was started)
+- **When**: Runs when a task is cancelled or a hook is aborted by the user (only if there's actual active work or work was started)
 - **Purpose**: Clean up resources, log cancellation, save state
-- **Global Location**: `~/Documents/Cline/Hooks/TaskCancel` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/TaskCancel` (all platforms)
-- **Note**: This hook is NOT cancellable and will complete even if the task is being aborted
+- **Global Location**: `~/Documents/Cline/Hooks/TaskCancel`
+- **Workspace Location**: `.clinerules/hooks/TaskCancel`
+- **Note**: This hook is NOT cancellable
 
-### TaskComplete Hook
+### TaskComplete Hook (coming soon!)
 - **When**: Runs when a task is marked as complete
 - **Purpose**: Log completion status, perform final cleanup, generate reports
-- **Global Location**: `~/Documents/Cline/Hooks/TaskComplete` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/TaskComplete` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/TaskComplete`
+- **Workspace Location**: `.clinerules/hooks/TaskComplete`
 
 ### UserPromptSubmit Hook
 - **When**: Runs when the user submits a prompt/message (initial task, resume, or feedback)
 - **Purpose**: Validate user input, preprocess prompts, add context to user messages
-- **Global Location**: `~/Documents/Cline/Hooks/UserPromptSubmit` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/UserPromptSubmit` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/UserPromptSubmit`
+- **Workspace Location**: `.clinerules/hooks/UserPromptSubmit`
 
 ### PreToolUse Hook
 - **When**: Runs BEFORE a tool is executed
 - **Purpose**: Validate parameters, block execution, or add context
-- **Global Location**: `~/Documents/Cline/Hooks/PreToolUse` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/PreToolUse` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/PreToolUse`
+- **Workspace Location**: `.clinerules/hooks/PreToolUse`
 
 ### PostToolUse Hook
 - **When**: Runs AFTER a tool completes
 - **Purpose**: Observe results, track patterns, or add context
-- **Global Location**: `~/Documents/Cline/Hooks/PostToolUse` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/PostToolUse` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/PostToolUse`
+- **Workspace Location**: `.clinerules/hooks/PostToolUse`
 
-### PreCompact Hook
+### PreCompact Hook (coming soon!)
 - **When**: Runs BEFORE the conversation context is compacted/truncated
 - **Purpose**: Observe compaction events, log context management, track token usage
-- **Global Location**: `~/Documents/Cline/Hooks/PreCompact` (all platforms)
-- **Workspace Location**: `.clinerules/hooks/PreCompact` (all platforms)
+- **Global Location**: `~/Documents/Cline/Hooks/PreCompact`
+- **Workspace Location**: `.clinerules/hooks/PreCompact`
 
 ## Cross-Platform Hook Format
 
@@ -74,13 +74,12 @@ Cline uses a git-style approach for hooks that works consistently across all pla
 - **No file extensions**: Hooks are named exactly `PreToolUse` or `PostToolUse` (no `.bat`, `.cmd`, `.sh` etc.)
 - **Shebang required**: First line must be a shebang (e.g., `#!/usr/bin/env bash` or `#!/usr/bin/env node`)
 - **Executable on Unix**: On Unix/Linux/macOS, hooks must be executable: `chmod +x PreToolUse`
-- **Windows**: No special permissions needed - hooks are executed through the shell
+- **Windows**: Not currently supported.
 
 ### How It Works
 
 Like git hooks, Cline executes hook files through a shell that interprets the shebang line:
 - On Unix/Linux/macOS: Native shell execution with shebang support
-- On Windows: Shell execution handles shebang interpretation
 
 This means:
 - ✅ Same hook script works on all platforms
@@ -98,12 +97,6 @@ nano ~/Documents/Cline/Hooks/PreToolUse
 chmod +x ~/Documents/Cline/Hooks/PreToolUse
 ```
 
-**On Windows:**
-```batch
-REM Create hook file (note: no file extension)
-notepad %USERPROFILE%\Documents\Cline\Hooks\PreToolUse
-```
-
 ## Context Injection Timing
 
 **IMPORTANT**: Context injected by hooks affects **FUTURE AI decisions**, not the current tool execution.
@@ -218,27 +211,6 @@ All hooks must return:
 - `false` (or omitted): Allow execution to continue
 - `true`: Block execution and show error message to user
 
-## Context Modification Format
-
-Use structured prefixes to help the AI understand context type:
-
-- `WORKSPACE_RULES:` - Project conventions and requirements
-- `FILE_OPERATIONS:` - File creation/modification patterns
-- `TOOL_RESULT:` - Outcomes of tool executions
-- `PERFORMANCE:` - Performance concerns
-- `VALIDATION:` - Validation results
-- Custom prefixes as needed
-
-Example:
-```bash
-cat <<EOF
-{
-  "cancel": false,
-  "contextModification": "WORKSPACE_RULES: This is a TypeScript project. All new files must use .ts or .tsx extensions."
-}
-EOF
-```
-
 ## Hook Execution Limits
 
 - **Timeout**: Hooks must complete within 30 seconds (configurable via `HOOK_EXECUTION_TIMEOUT_MS`)
@@ -260,7 +232,7 @@ if [[ "$tool_name" == "write_to_file" && "$path" == *.js ]]; then
 {
   "cancel": true,
   "errorMessage": "Cannot create .js files in TypeScript project",
-  "contextModification": "WORKSPACE_RULES: Use .ts/.tsx extensions only"
+  "contextModification": "Use .ts/.tsx extensions only"
 }
 EOF
   exit 0
@@ -282,7 +254,7 @@ if [[ "$tool_name" == "write_to_file" && "$success" == "true" ]]; then
   cat <<EOF
 {
   "cancel": false,
-  "contextModification": "FILE_OPERATIONS: Created '$path'. Maintain consistency with this file's patterns in future operations."
+  "contextModification": "Created '$path'. Maintain consistency with this file's patterns in future operations."
 }
 EOF
 else
@@ -302,7 +274,7 @@ if [[ "$execution_time" -gt 5000 ]]; then
   cat <<EOF
 {
   "cancel": false,
-  "contextModification": "PERFORMANCE: Tool '$tool_name' took ${execution_time}ms. Consider optimizing future similar operations."
+  "contextModification": "Tool '$tool_name' took ${execution_time}ms. Consider optimizing future similar operations."
 }
 EOF
 else
@@ -328,7 +300,7 @@ echo '{"cancel": false}'
 Cline supports two levels of hooks:
 
 ### Global Hooks
-- **Location**: `~/Documents/Cline/Hooks/` (macOS/Linux) or `%USERPROFILE%\Documents\Cline\Hooks\` (Windows)
+- **Location**: `~/Documents/Cline/Hooks/` (macOS/Linux)
 - **Scope**: Apply to ALL workspaces and projects
 - **Use Case**: Organization-wide policies, personal preferences, universal validations
 - **Priority**: Order not guaranteed when combined with workspace hooks
@@ -356,16 +328,12 @@ When multiple hooks exist (global and/or workspace):
 
 1. The global hooks directory is automatically created at:
    - macOS/Linux: `~/Documents/Cline/Hooks/`
-   - Windows: `%USERPROFILE%\Documents\Cline\Hooks\`
 
 2. Add your hook script:
    ```bash
    # Unix/Linux/macOS
    nano ~/Documents/Cline/Hooks/PreToolUse
    chmod +x ~/Documents/Cline/Hooks/PreToolUse
-   
-   # Windows
-   notepad %USERPROFILE%\Documents\Cline\Hooks\PreToolUse
    ```
 
 3. Enable hooks in Cline settings
@@ -433,7 +401,6 @@ If you have multiple workspace roots, you can place hooks in each root's `.cline
 
 ### Context Not Affecting Behavior
 - Remember: context affects FUTURE decisions, not the current tool
-- Use PreToolUse for validation (blocking) if you need immediate effect
 - Ensure context modifications are clear and actionable
 - Check that context isn't being truncated (50KB limit)
 

.clinerules/hooks/TaskCancel.example

@@ -1,15 +1,19 @@
 #!/usr/bin/env bash
 
-for i in {1..100}; do
+echo "TaskCancel running inside local cline/.clinerules/hooks/ directory"
+
+input=$(cat)
+echo $input | jq .
+
+for i in {1..5}; do
+  sleep 1
   echo "$i"
 done
 
-sleep 3
-
 cat <<EOF
 {
-  "cancel", false,
-  "contextModification": "WORKSPACE_RULES: This is from the local bar/ workspace.",
-  "errorMessage": "TaskCancel hook custom errorMessage: foo"
+  "cancel": false,
+  "contextModification": "TaskCancel response from the local cline/.clinerules/hooks/ directory.",
+  "errorMessage": "TaskCancel hook custom errorMessage"
 }
 EOF

.clinerules/hooks/TaskResume.example

@@ -1,15 +1,19 @@
 #!/usr/bin/env bash
 
-for i in {1..100}; do
+echo "TaskResume running inside local cline/.clinerules/hooks/ directory"
+
+input=$(cat)
+echo $input | jq .
+
+for i in {1..5}; do
+  sleep 1
   echo "$i"
 done
 
-sleep 3
-
 cat <<EOF
 {
   "cancel": false,
-  "contextModification": "WORKSPACE_RULES: This is from the local bar/ workspace.",
-  "errorMessage": "TaskResume hook custom errorMessage: foo"
+  "contextModification": "TaskResume response from the local cline/.clinerules/hooks/ directory.",
+  "errorMessage": "TaskResume hook custom errorMessage"
 }
 EOF

.clinerules/hooks/TaskStart.example

@@ -1,15 +1,19 @@
 #!/usr/bin/env bash
 
-for i in {1..100}; do
+echo "TaskStart running inside local cline/.clinerules/hooks/ directory"
+
+input=$(cat)
+echo $input | jq .
+
+for i in {1..5}; do
+  sleep 1
   echo "$i"
 done
 
-sleep 1
-
 cat <<EOF
 {
   "cancel": false,
-  "contextModification": "WORKSPACE_RULES: This is from the local bar/ workspace.",
-  "errorMessage": "TaskStart hook custom errorMessage: foo"
+  "contextModification": "TaskStart response from the local cline/.clinerules/hooks/ directory.",
+  "errorMessage": "TaskStart hook custom errorMessage"
 }
 EOF

.clinerules/hooks/UserPromptSubmit.example

@@ -1,15 +1,19 @@
 #!/usr/bin/env bash
 
-for i in {1..100}; do
+echo "UserPromptSubmit running inside local cline/.clinerules/hooks/ directory"
+
+input=$(cat)
+echo $input | jq .
+
+for i in {1..5}; do
+  sleep 1
   echo "$i"
 done
 
-sleep 3
-
 cat <<EOF
 {
   "cancel": false,
-  "contextModification": "WORKSPACE_RULES: This is from the local bar/ workspace.",
-  "errorMessage": "UserPromptSubmit hook custom errorMessage: foo"
+  "contextModification": "UserPromptSubmit response from the local cline/.clinerules/hooks/ directory.",
+  "errorMessage": "UserPromptSubmit hook custom errorMessage"
 }
 EOF

CHANGELOG.md

@@ -1,5 +1,24 @@
 # Changelog
 
+## [3.36.1]
+
+- fix: remove native tool calling support from Gemini and XAI provider due to invalid tool names issues
+- fix: disable native tool callings for grok code models
+- Add MCP tool usage to GLM
+- Removes reasoning_details content field from Anthropic providers
+
+## [3.36.0]
+
+- Add: Hooks allow you to inject custom logic into Cline's workflow
+- Add: new provider AIhubmix
+- Add: Use http_proxy, https_proxy and no_proxy in JetBrains
+- Fix: Oca Token Refresh logic
+- Fix: issues where assistant message with empty content is added to conversation history
+- Fix: bug where the checkbox shows in the model selector dropdown
+- Fix: Switch from defaultUserAgentProvider to customUserAgent for Bedrock
+- Fix: support for `<think>` tags for better compatibility with open-source models
+- Fix: refinements to the GLM-4.6 system prompt
+
 ## [3.35.1]
 
 - Add: Hicap API integration as provider

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**

cli/pkg/cli/auth/byo_quick_setup.go

@@ -4,6 +4,7 @@ import (
 	"context"
 	"fmt"
 	"strings"
+	"time"
 
 	"github.com/cline/cli/pkg/cli/global"
 	"github.com/cline/cli/pkg/cli/task"
@@ -75,6 +76,11 @@ func QuickSetupFromFlags(ctx context.Context, provider, apiKey, modelID, baseURL
 		}
 	}
 
+	// WORKAROUND: Wait for debounced state persistence to complete
+	// Fixes `cline auth` issue when ran in docker environments
+	// TODO: implement better solution w/ changes in StateManager
+	time.Sleep(600 * time.Millisecond)
+
 	// Success message
 	fmt.Printf("\n✓ Successfully configured %s provider\n", GetProviderDisplayName(providerEnum))
 	fmt.Printf("  Model: %s\n", finalModelID)

cli/pkg/cli/display/tool_renderer.go

@@ -106,6 +106,14 @@ func (tr *ToolRenderer) generateToolHeader(tool *types.ToolMessage, verbTense st
 		}
 		return fmt.Sprintf("### Cline %s `%s`", action, tool.Path)
 
+	case string(types.ToolTypeFileDeleted):
+		if verbTense == "wants to" {
+			action = "wants to delete"
+		} else {
+			action = "is deleting"
+		}
+		return fmt.Sprintf("### Cline %s `%s`", action, tool.Path)
+
 	case string(types.ToolTypeListFilesTopLevel):
 		if verbTense == "wants to" {
 			action = "wants to list files in"
@@ -199,7 +207,7 @@ func (tr *ToolRenderer) GenerateToolContentPreview(tool *types.ToolMessage) stri
 		previewMd := fmt.Sprintf("```\n%s\n```", preview)
 		return tr.renderMarkdown(previewMd)
 
-	case string(types.ToolTypeReadFile), string(types.ToolTypeWebFetch):
+	case string(types.ToolTypeReadFile), string(types.ToolTypeWebFetch), string(types.ToolTypeFileDeleted):
 		// No preview for read/fetch operations
 		return ""
 
@@ -226,7 +234,8 @@ func (tr *ToolRenderer) GenerateToolContentBody(tool *types.ToolMessage) string
 	toolParser := NewToolResultParser(tr.mdRenderer)
 
 	switch tool.Tool {
-	case string(types.ToolTypeReadFile):
+	case string(types.ToolTypeReadFile),
+		string(types.ToolTypeFileDeleted):
 		// readFile: show header only, no body
 		return ""
 

cli/pkg/cli/task/input_handler.go

@@ -256,6 +256,8 @@ func determineAutoApprovalAction(msg *types.ClineMessage) (string, error) {
 		case types.ToolTypeEditedExistingFile,
 			types.ToolTypeNewFileCreated:
 			return "edit_files", nil
+		case types.ToolTypeFileDeleted:
+			return "apply_patch", nil
 		default:
 			return "", fmt.Errorf("unsupported tool type: %s", toolMsg.Tool)
 		}

cli/pkg/cli/types/messages.go

@@ -107,6 +107,7 @@ const (
 	ToolTypeEditedExistingFile      ToolType = "editedExistingFile"
 	ToolTypeNewFileCreated          ToolType = "newFileCreated"
 	ToolTypeReadFile                ToolType = "readFile"
+	ToolTypeFileDeleted             ToolType = "fileDeleted"
 	ToolTypeListFilesTopLevel       ToolType = "listFilesTopLevel"
 	ToolTypeListFilesRecursive      ToolType = "listFilesRecursive"
 	ToolTypeListCodeDefinitionNames ToolType = "listCodeDefinitionNames"

docs/cline-cli/samples/github-integration.mdx

@@ -0,0 +1,324 @@
+---
+title: "GitHub Actions Integration"
+description: "Automatically respond to GitHub issues by mentioning @cline in comments using Cline CLI in GitHub Actions."
+---
+
+# GitHub Integration Sample
+
+Automate GitHub issue analysis with AI. Mention `@cline` in any issue comment to trigger an autonomous investigation that reads files, analyzes code, and provides actionable insights - all running automatically in GitHub Actions.
+
+
+<Note>
+**New to Cline CLI?** This sample assumes you understand Cline CLI basics and have completed the [Installation Guide](https://docs.cline.bot/cline-cli/installation). If you're new to Cline CLI, we recommend starting with the [GitHub RCA sample](../github-issue-rca) first, as it's simpler and will help you understand the fundamentals before setting up GitHub Actions.
+</Note>
+
+## The Workflow
+
+Trigger Cline by mentioning `@cline` in any issue comment:
+
+<Frame>
+  <img src="https://storage.googleapis.com/cline_public_images/ss0a-comment.png" alt="Issue comment with @cline mention" width="600" />
+</Frame>
+
+Cline's automated analysis appears as a new comment, with insights drawn from your actual codebase:
+
+<Frame>
+  <img src="https://storage.googleapis.com/cline_public_images/ss0b-final.png" alt="Automated analysis response from Cline" width="600" />
+</Frame>
+
+The entire investigation runs autonomously in GitHub Actions - from file exploration to posting results.
+
+Let's configure your repository.
+
+## Prerequisites
+
+Before you begin, you'll need:
+
+- **Cline CLI knowledge** - Completed the [Installation Guide](https://docs.cline.bot/cline-cli/installation) and understand basic usage
+- **GitHub repository** - With admin access to configure Actions and secrets
+- **GitHub Actions familiarity** - Basic understanding of workflows and CI/CD
+- **API provider account** - OpenRouter, Anthropic, or similar with API key
+
+## Setup
+
+### 1. Copy the Workflow File
+
+
+
+Copy the workflow file from this sample to your repository. The workflow file must be placed in the `.github/workflows/` directory in your repository root for GitHub Actions to detect and run it. In this case, we'll name it `cline-responder.yml`.
+
+```bash
+# In your repository root
+mkdir -p .github/workflows
+curl -o .github/workflows/cline-responder.yml https://raw.githubusercontent.com/cline/cline/main/src/samples/cli/github-integration/cline-responder.yml
+```
+
+Alternatively, you can copy the full workflow file directly into `.github/workflows/cline-responder.yml`:
+
+<Accordion title="Click to view the complete cline-responder.yml workflow">
+```yaml
+name: Cline Issue Assistant
+
+on:
+  issue_comment:
+    types: [created, edited]
+
+permissions:
+  issues: write
+
+jobs:
+  respond:
+    runs-on: ubuntu-latest
+    environment: cline-actions
+    steps:
+      - name: Check for @cline mention
+        id: detect
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const body = context.payload.comment?.body || "";
+            const isPR = !!context.payload.issue?.pull_request;
+            const hit = body.toLowerCase().includes("@cline");
+            core.setOutput("hit", (!isPR && hit) ? "true" : "false");
+            core.setOutput("issue_number", String(context.payload.issue?.number || ""));
+            core.setOutput("issue_url", context.payload.issue?.html_url || "");
+            core.setOutput("comment_body", body);
+
+      - name: Checkout repository
+        if: steps.detect.outputs.hit == 'true'
+        uses: actions/checkout@v4
+
+      # Node v20 is needed for Cline CLI on GitHub Actions Linux
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+
+      - name: Setup Cline CLI
+        if: steps.detect.outputs.hit == 'true'
+        run: |
+          # Install the Cline CLI
+          sudo npm install -g cline
+
+      - name: Create Cline Instance
+        if: steps.detect.outputs.hit == 'true'
+        env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
+          CLINE_DIR: ${{ runner.temp }}/cline
+        run: |
+          # Create instance and capture output
+          INSTANCE_OUTPUT=$(cline instance new 2>&1)
+          
+          # Parse address from output (format: "  Address: 127.0.0.1:36733")
+          CLINE_ADDRESS=$(echo "$INSTANCE_OUTPUT" | grep "Address:" | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}:[0-9]+')
+          echo "CLINE_ADDRESS=$CLINE_ADDRESS" >> $GITHUB_ENV
+          
+          # Configure API key
+          cline config set open-router-api-key=$OPENROUTER_API_KEY --address $CLINE_ADDRESS -v
+
+      - name: Download analyze script
+        if: steps.detect.outputs.hit == 'true'
+        run: |
+          export GITORG="YOUR-GITHUB-ORG"
+          export GITREPO="YOUR-GITHUB-REPO"
+
+          curl -L https://raw.githubusercontent.com/${GITORG}/${GITREPO}/refs/heads/main/git-scripts/analyze-issue.sh -o analyze-issue.sh
+          chmod +x analyze-issue.sh
+
+      - name: Run analysis
+        if: steps.detect.outputs.hit == 'true'
+        id: analyze
+        env:
+          ISSUE_URL: ${{ steps.detect.outputs.issue_url }}
+          COMMENT: ${{ steps.detect.outputs.comment_body }}
+          CLINE_ADDRESS: ${{ env.CLINE_ADDRESS }}
+        run: |
+          set -euo pipefail
+          
+          RESULT=$(./analyze-issue.sh "${ISSUE_URL}" "Analyze this issue. The user asked: ${COMMENT}" "$CLINE_ADDRESS")
+          
+          {
+            echo 'result<<EOF'
+            printf "%s\n" "$RESULT"
+            echo 'EOF'
+          } >> "$GITHUB_OUTPUT"
+
+      - name: Post response
+        if: steps.detect.outputs.hit == 'true'
+        uses: actions/github-script@v7
+        env:
+          ISSUE_NUMBER: ${{ steps.detect.outputs.issue_number }}
+          RESULT: ${{ steps.analyze.outputs.result }}
+        with:
+          script: |
+            await github.rest.issues.createComment({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              issue_number: Number(process.env.ISSUE_NUMBER),
+              body: process.env.RESULT || "(no output)"
+            });
+```
+</Accordion>
+
+<Warning>
+**You MUST edit the workflow file before committing!**
+
+Open `.github/workflows/cline-responder.yml` and update the "Download analyze script" step within the workflow to specify your GitHub organization and repository where the analysis script is stored:
+
+```yaml
+export GITORG="YOUR-GITHUB-ORG"      # Change this!
+export GITREPO="YOUR-GITHUB-REPO"    # Change this!
+```
+
+**Example:** If your repository is `github.com/acme/myproject`, set:
+```yaml
+export GITORG="acme"
+export GITREPO="myproject"
+```
+
+This tells the workflow where to download the analysis script from your repository after you commit it in step 3.
+</Warning>
+
+The workflow will look for new or updated issues, check for `@cline` mentions, and then
+start up an instance of the Cline CLI to dig into the issue, providing feedback
+as a reply to the issue.
+
+### 2. Configure API Keys
+
+Add your AI provider API keys as repository secrets:
+
+1. Go to your GitHub repository
+2. Navigate to **Settings** → **Environment** and Add a new environment.
+
+   <Frame>
+     <img src="https://storage.googleapis.com/cline_public_images/ss01-environment.png" alt="Navigate to Actions secrets" width="600" />
+   </Frame>
+
+   Make sure to name it "cline-actions" so that it matches the `environment`
+   value at the top of the `cline-responder.yml` file.
+
+3. Click **New repository secret**
+4. Add a secret for the `OPENROUTER_API_KEY` with a value of an API key from
+   [openrouter.com](https://openrouter.com).
+
+   <Frame>
+     <img src="https://storage.googleapis.com/cline_public_images/ss02-api-key.png" alt="Add API key secret" width="600" />
+   </Frame>
+
+5. Verify your secret is configured:
+
+   <Frame>
+     <img src="https://storage.googleapis.com/cline_public_images/ss03-ready.png" alt="API key configured" width="600" />
+   </Frame>
+
+Now you're ready to supply Cline with the credentials it needs in a GitHub Action.
+
+### 3. Add Analysis Script
+
+Add the analysis script from the `github-issue-rca` sample to your repository. **First, you'll need to create a `git-scripts` directory in your repository root where the script will be located.** Choose one of these options:
+
+**Option A: Download directly (Recommended)**
+
+```bash
+# In your repository root, create the directory and download the script
+mkdir -p git-scripts
+curl -o git-scripts/analyze-issue.sh https://raw.githubusercontent.com/cline/cline/main/src/samples/cli/github-issue-rca/analyze-issue.sh
+chmod +x git-scripts/analyze-issue.sh
+```
+
+**Option B: Manual copy-paste**
+
+Create the directory and file manually, then paste the script content:
+
+```bash
+# In your repository root
+mkdir -p git-scripts
+# Create and edit the file with your preferred editor
+nano git-scripts/analyze-issue.sh  # or use vim, code, etc.
+```
+
+<Accordion title="Click to view the complete analyze-issue.sh script">
+```bash
+#!/bin/bash
+# Analyze a GitHub issue using Cline CLI
+
+if [ -z "$1" ]; then
+    echo "Usage: $0 <github-issue-url> [prompt] [address]"
+    echo "Example: $0 https://github.com/owner/repo/issues/123"
+    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause of this issue?'"
+    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause of this issue?' 127.0.0.1:46529"
+    exit 1
+fi
+
+# Gather the args
+ISSUE_URL="$1"
+PROMPT="${2:-What is the root cause of this issue?}"
+if [ -n "$3" ]; then
+    ADDRESS="--address $3"
+fi
+
+# Ask Cline for its analysis, showing only the summary
+cline -y "$PROMPT: $ISSUE_URL" --mode act $ADDRESS -F json | \
+    sed -n '/^{/,$p' | \
+    jq -r 'select(.say == "completion_result") | .text' | \
+    sed 's/\\n/\n/g'
+```
+
+After pasting the script content, make it executable:
+```bash
+chmod +x git-scripts/analyze-issue.sh
+```
+</Accordion>
+
+This analysis script calls Cline to execute a prompt on a GitHub issue,
+summarizing the output to populate the reply to the issue.
+
+### 4. Commit and Push
+
+```bash
+git add .github/workflows/cline-responder.yml
+git add git-scripts/analyze-issue.sh
+git commit -m "Add Cline issue assistant workflow"
+git push
+```
+
+## Usage
+
+Once set up, simply mention `@cline` in any issue comment:
+
+```
+@cline what's causing this error?
+
+@cline analyze the root cause
+
+@cline what are the security implications?
+```
+
+GitHub Actions will:
+1. Detect the `@cline` mention
+2. Start a Cline CLI instance
+3. Download the analysis script
+4. Analyze the issue using act mode with yolo (fully autonomous)
+5. Post Cline's analysis as a new comment
+
+**Note**: The workflow only triggers on issue comments, not pull request
+comments.
+
+## How It Works
+
+The workflow (`cline-responder.yml`):
+
+1. **Triggers** on issue comments (created or edited)
+2. **Detects** `@cline` mentions (case-insensitive)
+3. **Installs** Cline CLI globally using npm
+4. **Creates** a Cline instance using `cline instance new`
+5. **Configures** authentication using `cline config set open-router-api-key=...
+   --address ...`
+6. **Downloads** the reusable `analyze-issue.sh` script from the
+   `github-issue-rca` sample
+7. **Runs** analysis with the instance address
+8. **Posts** the analysis result as a comment
+
+## Related Samples
+
+- **[github-issue-rca](./github-issue-rca)**: The reusable script that powers this integration

docs/cline-cli/samples/github-issue-rca.mdx

@@ -0,0 +1,383 @@
+---
+title: "GitHub Issue RCA Sample"
+description: "Automated GitHub issue analysis using Cline CLI to identify root causes."
+---
+
+# GitHub Root Cause Analysis
+
+Automated GitHub issue analysis using Cline CLI. This script uses Cline's autonomous AI capabilities to fetch, analyze, and identify root causes of GitHub issues, outputting clean, parseable results that can be easily integrated into your development workflows.
+
+<Note>
+**New to Cline CLI?** This sample assumes you have already completed the [Installation Guide](https://docs.cline.bot/cline-cli/installation) and authenticated with `cline auth`. If you haven't set up Cline CLI yet, please start there first.
+</Note>
+
+<Frame>
+  <img src="https://storage.googleapis.com/cline_public_images/cli-rca.gif" alt="CLI Root Cause Analysis Demo" width="600" />
+</Frame>
+
+## Prerequisites
+
+This sample assumes you have already:
+
+- **Cline CLI** installed and authenticated ([Installation Guide](https://docs.cline.bot/cline-cli/installation))
+- **At least one AI model provider** configured (e.g., OpenRouter, Anthropic, OpenAI)
+- **Basic familiarity** with Cline CLI commands
+
+Additionally, you'll need:
+
+- **GitHub CLI** (`gh`) installed and authenticated
+- **jq** installed for JSON parsing
+- **bash** shell (or compatible shell)
+
+### Installation Instructions
+
+#### macOS
+
+<Note>
+These instructions require [Homebrew](https://brew.sh/) to be installed. If you don't have Homebrew, install it first by running:
+```bash
+/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+```
+</Note>
+
+```bash
+# Install GitHub CLI
+brew install gh
+
+# Install jq
+brew install jq
+
+# Authenticate with GitHub
+gh auth login
+```
+
+#### Linux
+
+```bash
+# Install GitHub CLI (Debian/Ubuntu)
+sudo apt install gh
+
+# Or for other Linux distributions, see: https://cli.github.com/manual/installation
+
+# Install jq (Debian/Ubuntu)
+sudo apt install jq
+
+# Authenticate with GitHub
+gh auth login
+```
+
+## Getting the Script
+
+**Option 1: Download directly with curl**
+```bash
+curl -O https://raw.githubusercontent.com/cline/cline/main/src/samples/cli/github-issue-rca/analyze-issue.sh
+```
+
+**Option 2: Copy the full script**
+
+<Accordion title="Click to view the complete analyze-issue.sh script">
+
+```bash
+#!/bin/bash
+# Analyze a GitHub issue using Cline CLI
+
+if [ -z "$1" ]; then
+    echo "Usage: $0 <github-issue-url> [prompt] [address]"
+    echo "Example: $0 https://github.com/owner/repo/issues/123"
+    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause of this issue?'"
+    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause of this issue?' 127.0.0.1:46529"
+    exit 1
+fi
+
+# Gather the args
+ISSUE_URL="$1"
+PROMPT="${2:-What is the root cause of this issue?}"
+if [ -n "$3" ]; then
+    ADDRESS="--address $3"
+fi
+
+# Ask Cline for its analysis, showing only the summary
+cline -y "$PROMPT: $ISSUE_URL" --mode act $ADDRESS -F json | \
+    sed -n '/^{/,$p' | \
+    jq -r 'select(.say == "completion_result") | .text' | \
+    sed 's/\\n/\n/g'
+```
+
+</Accordion>
+
+<Note>
+**After downloading or creating the script**, make it executable by running:
+```bash
+chmod +x analyze-issue.sh
+```
+</Note>
+
+## Quick Usage Examples
+
+### Basic Usage
+
+Run this command in your terminal from the directory where you saved the script to analyze an issue with the default root cause prompt:
+
+```bash
+./analyze-issue.sh https://github.com/owner/repo/issues/123
+```
+
+This will:
+- Fetch issue #123 from the repository
+- Analyze the issue to identify root causes
+- Provide detailed analysis with recommendations
+
+### Custom Analysis Prompt
+
+Ask specific questions about the issue:
+
+```bash
+./analyze-issue.sh https://github.com/owner/repo/issues/456 "What is the security impact?"
+```
+
+### Using Specific Cline Instance
+
+Target a particular Cline instance by address:
+
+```bash
+./analyze-issue.sh https://github.com/owner/repo/issues/123 \
+    "What is the root cause of this issue?" \
+    127.0.0.1:46529
+```
+
+<Warning>
+This is useful when:
+- Running multiple Cline instances
+- Using a remote Cline server
+- Testing with specific configurations
+</Warning>
+
+<Note>
+The script will automatically handle everything: fetching the issue, analyzing it with Cline, and displaying the results. The analysis typically takes 30-60 seconds depending on the issue complexity.
+</Note>
+
+## How It Works
+
+Let's analyze each component of the script to understand how it works.
+
+### Argument Validation
+
+The script validates input and provides usage instructions:
+
+```bash
+if [ -z "$1" ]; then
+    echo "Usage: $0 <github-issue-url> [prompt] [address]"
+    echo "Example: $0 https://github.com/owner/repo/issues/123"
+    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause?'"
+    echo "Example: $0 https://github.com/owner/repo/issues/123 'Analyze security impact' 127.0.0.1:46529"
+    exit 1
+fi
+```
+
+**Key Points:**
+- Validates required GitHub issue URL
+- Shows clear usage examples
+- Supports optional custom prompt
+- Supports optional Cline instance address
+
+### Argument Parsing
+
+The script extracts and sets up the arguments:
+
+```bash
+# Gather the args
+ISSUE_URL="$1"
+PROMPT="${2:-What is the root cause of this issue?}"
+if [ -n "$3" ]; then
+    ADDRESS="--address $3"
+fi
+```
+
+**Explanation:**
+- `ISSUE_URL="$1"` - First argument is always the issue URL
+- `PROMPT="${2:-...}"` - Second argument is optional, defaults to root cause analysis
+- `ADDRESS` - Third argument is optional, only set if provided
+
+### The Core Analysis Pipeline
+
+This is where the magic happens:
+
+```bash
+# Ask Cline for his analysis, showing only the summary
+cline -y "$PROMPT: $ISSUE_URL" --mode act $ADDRESS -F json | \
+    sed -n '/^{/,$p' | \
+    jq -r 'select(.say == "completion_result") | .text' | \
+    sed 's/\\n/\n/g'
+```
+
+<Accordion title="Pipeline Breakdown: Understanding Each Component">
+
+**1. `cline -y "$PROMPT: $ISSUE_URL"`**
+   - `-y` enables yolo mode (no user interaction)
+   - Constructs prompt with issue URL
+
+**2. `--mode act`**
+   - Enables act mode for active investigation
+   - Allows Cline to use tools (read files, run commands, etc.)
+
+**3. `$ADDRESS`**
+   - Optional address flag for specific instance
+   - Expands to `--address <ip:port>` if set
+
+**4. `-F json`**
+   - Outputs in JSON format for parsing
+
+**5. `sed -n '/^{/,$p'`**
+   - Extracts JSON from output
+   - Skips any non-JSON prefix lines
+
+**6. `jq -r 'select(.say == "completion_result") | .text'`**
+   - Filters for completion result messages
+   - Extracts the text field
+   - `-r` outputs raw strings (no JSON quotes)
+
+**7. `sed 's/\\n/\n/g'`**
+   - Converts escaped newlines to actual newlines
+   - Makes output readable
+
+</Accordion>
+
+## Sample Output
+
+Here's an example analyzing a real Flutter issue:
+
+```bash
+$ ./analyze-issue.sh https://github.com/csells/flutter_counter/issues/2
+```
+
+**Output:**
+
+```markdown
+**Root Cause Analysis of Issue #2: "setState isn't cutting it"**
+
+After examining the GitHub issue and analyzing the Flutter counter codebase, 
+I've identified the root cause of why setState() is insufficient for this 
+project's needs:
+
+## Current Implementation Problems
+
+The current Flutter counter app uses setState() for state management, which 
+has several limitations:
+
+1. **Local State Only**: setState() only works within a single widget, making 
+   it difficult to share state across the app
+2. **Rebuild Overhead**: Every setState() call rebuilds the entire widget tree, 
+   causing performance issues with complex UIs
+3. **No State Persistence**: State is lost when the widget is disposed
+4. **Testing Challenges**: setState-based logic is tightly coupled to the UI, 
+   making unit testing difficult
+
+## Why This Matters
+
+As the app grows beyond a simple counter, these limitations become critical:
+- Multiple screens need to access the count
+- State needs to persist across navigation
+- Business logic should be testable independently
+- UI should only rebuild when necessary
+
+## Recommended Solutions
+
+The issue mentions "Provider or Bloc" - both are excellent alternatives:
+
+1. **Provider**: Simple, lightweight state management using InheritedWidget
+   - Easy migration path from setState
+   - Good for small to medium apps
+   - Official Flutter recommendation
+
+2. **Bloc**: More structured approach with clear separation between events, 
+   states, and business logic
+   - Better for complex apps
+   - Excellent testability
+   - Clear architectural patterns
+
+3. **Riverpod**: Modern alternative to Provider with better performance and 
+   developer experience
+   - Compile-time safety
+   - Better testing support
+   - More flexible than Provider
+
+4. **GetX**: Full-featured solution with state management, routing, and 
+   dependency injection
+   - Minimal boilerplate
+   - Fast and lightweight
+   - All-in-one solution
+
+## Next Steps
+
+The current codebase needs refactoring to implement proper state management 
+architecture to handle more complex state scenarios effectively. Provider 
+would be the easiest migration path while Bloc provides better long-term 
+scalability.
+```
+
+## When to Use This Pattern
+
+This script pattern is ideal for various development scenarios where automated GitHub issue analysis can accelerate your workflow.
+
+### Bug Investigation
+
+Quickly analyze bug reports and identify root causes without manual code exploration:
+
+```bash
+./analyze-issue.sh https://github.com/project/repo/issues/123 \
+    "What is the root cause of this bug?"
+```
+
+### Feature Request Analysis
+
+Understand context and implications of feature requests:
+
+```bash
+./analyze-issue.sh https://github.com/project/repo/issues/456 \
+    "What are the implementation challenges?"
+```
+
+### Security Audits
+
+Assess security implications of reported issues:
+
+```bash
+./analyze-issue.sh https://github.com/project/repo/issues/789 \
+    "What are the security implications?"
+```
+
+### Documentation Generation
+
+Generate detailed technical documentation from issues:
+
+```bash
+./analyze-issue.sh https://github.com/project/repo/issues/654 \
+    "Provide detailed technical documentation for this issue"
+```
+
+### Code Review Assistance
+
+Get second opinions on proposed changes:
+
+```bash
+./analyze-issue.sh https://github.com/project/repo/issues/987 \
+    "Review the proposed solution approach"
+```
+
+## Conclusion
+
+This sample demonstrates how to build an autonomous GitHub issue analysis tool using Cline CLI:
+
+1. **Building autonomous CLI tools** using Cline's capabilities
+2. **Parsing structured JSON output** from Cline CLI
+3. **Creating flexible automation scripts** with custom prompting
+4. **Integrating with GitHub** for issue analysis
+5. **Handling command-line arguments** effectively
+
+This pattern can be adapted for many other automation scenarios, from pull request reviews to documentation generation to code quality analysis.
+
+## Related Resources
+
+- [CLI Installation Guide](https://docs.cline.bot/cline-cli/installation)
+- [CLI Reference Documentation](https://docs.cline.bot/cline-cli/cli-reference)
+- [Three Core Flows](https://docs.cline.bot/cline-cli/three-core-flows)

docs/cline-cli/samples/overview.mdx

@@ -0,0 +1,32 @@
+---
+title: "Samples Overview"
+description: Example implementations demonstrating Cline CLI capabilities
+---
+
+This section provides sample implementations that demonstrate various Cline CLI features and capabilities. Each sample includes complete code, detailed explanations, and real-world usage examples.
+
+## Available Samples
+
+<CardGroup cols={1}>
+  <Card 
+    title="GitHub Root Cause Analysis" 
+    icon="magnifying-glass-chart" 
+    href="/cline-cli/samples/github-issue-rca"
+  >
+    A command-line script that uses Cline's autonomous AI capabilities to fetch, analyze, and identify root causes of GitHub issues. Features JSON output parsing and non-interactive execution.
+  </Card>
+
+  <Card 
+    title="GitHub Integration (Actions)" 
+    icon="github" 
+    href="/cline-cli/samples/github-integration"
+  >
+    Automatically respond to GitHub issues by mentioning @cline in comments. Uses Cline CLI in GitHub Actions to create an AI-powered issue assistant that analyzes and responds autonomously.
+  </Card>
+</CardGroup>
+
+## Additional Resources
+
+- [CLI Installation Guide](/cline-cli/installation)
+- [CLI Reference Documentation](/cline-cli/cli-reference)
+- [Three Core Flows](/cline-cli/three-core-flows)

docs/docs.json

@@ -88,6 +88,14 @@
 							"cline-cli/overview",
 							"cline-cli/installation",
 							"cline-cli/three-core-flows",
+							{
+								"group": "CLI Samples",
+								"pages": [
+									"cline-cli/samples/overview",
+									"cline-cli/samples/github-issue-rca",
+									"cline-cli/samples/github-integration"
+								]
+							},
 							"cline-cli/cli-reference"
 						]
 					},
@@ -130,6 +138,7 @@
 							"features/drag-and-drop",
 							"features/editing-messages",
 							"features/focus-chain",
+							"features/hooks",
 							"features/multiroot-workspace",
 							"features/plan-and-act",
 							{
@@ -315,6 +324,10 @@
 		{
 			"source": "/getting-started/your-first-task",
 			"destination": "/getting-started/your-first-project"
+		},
+		{
+			"source": "/cline-cli/samples",
+			"destination": "/cline-cli/samples/overview"
 		}
 	],
 	"search": {

docs/features/hooks.mdx

@@ -0,0 +1,391 @@
+---
+title: "Hooks"
+sidebarTitle: "Hooks"
+description: "Inject custom logic into Cline's workflow to validate operations, monitor tool usage, and shape AI decisions"
+---
+
+Hooks let you inject custom logic into Cline's workflow at key moments. Think of them as automated checkpoints where you can validate operations before they execute, monitor tool usage as it happens, and shape how Cline makes decisions.
+
+Hooks run automatically when specific events happen during development. They receive detailed information about each operation, can block problematic actions before they cause issues, and can inject context that guides future AI decisions.
+
+The real power comes from combining these capabilities. You can:
+
+- Stop operations before they cause problems (like creating `.js` files in a TypeScript project)
+- Learn from what's happening and build up project knowledge over time
+- Monitor performance and catch issues as they emerge
+- Track everything for analytics or compliance
+- Trigger external tools or services at the right moments
+
+<Warning>
+Hooks are currently supported on macOS and Linux only. Windows support is not available.
+</Warning>
+
+## Getting Started
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/hooks.gif" alt="Hooks in action" />
+</Frame>
+
+Enabling hooks in Cline is straightforward. Here's what you need to do:
+
+<Steps>
+<Step title="Enable Hooks in Settings">
+Open Cline settings and check the **"Enable Hooks"** checkbox.
+
+You can find this setting by:
+1. Opening Cline
+2. Click the "Settings" button on the top right corner
+3. Click the "Feature" section in the left side navigation menu.
+4. Scroll down until you see the "Enable Hooks" checkbox and check it. 
+</Step>
+
+<Step title="Choose Your Hook Location">
+Decide where to place your hooks:
+
+**For personal or organization-wide hooks:**
+- Create hooks in `~/Documents/Cline/Rules/Hooks/`
+- These apply to all workspaces automatically
+
+**For project-specific hooks:**
+- Create hooks in `.clinerules/hooks/` in your project root
+- These only apply to the specific workspace
+- Commit them to version control so your team can use them too
+</Step>
+
+<Step title="Create Your First Hook">
+Hook files must have exact names with no file extensions. For example, to create a TaskStart hook:
+
+```bash
+# Create the hook file
+vim .clinerules/hooks/TaskStart
+```
+
+Add your script (must start with shebang)
+``` bash
+#!/usr/bin/env bash
+
+# Store piped input into a variable
+input=$(cat)
+
+# Dump the entire JSON payload
+echo "$input" | jq .
+
+# Get the type of a field
+echo "$input" | jq -r '.timestamp | type'
+```
+
+This example script demonstrates the key mechanics of hook input/output: reading the JSON payload from stdin with `input=$(cat)`, and using `jq` to inspect the data structure and field types that your hook receives. This helps you understand what data is available before building more complex hook logic.
+
+#### Make it executable
+
+```bash
+chmod +x .clinerules/hooks/TaskStart
+```
+</Step>
+
+<Step title="Test Your Hook">
+Start a task in Cline and verify your hook executes.
+</Step>
+</Steps>
+
+<Tip>
+Start with a simple hook that just logs information before building complex validation logic. This helps you understand the data structure and timing.
+</Tip>
+
+## Hook Types
+
+Cline provides multiple hook types that let you tap into different stages of the AI workflow. They're organized into categories based on their trigger points and use cases.
+
+<Note>
+The hook names below are the exact file names you need to create. For example, to use the TaskStart hook, create a file named `TaskStart` (no file extension) in your hooks directory.
+</Note>
+
+Each hook receives base fields in addition to its specific data: `clineVersion`, `hookName`, `timestamp`, `taskId`, `workspaceRoots`, `userId`.
+
+### Tool Execution
+
+These hooks intercept and validate tool operations before and after they execute. Use them to enforce policies, track changes, and learn from operations.
+
+#### PreToolUse
+
+Runs before any tool executes. Use it to block invalid operations, validate parameters, and enforce project policies before changes happen.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "PreToolUse",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "preToolUse": {
+    "toolName": "string",
+    "parameters": {}
+  }
+}
+```
+
+#### PostToolUse
+
+Runs after a tool completes. Use it to learn from results, track performance metrics, and build project knowledge based on operations performed.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "PostToolUse",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "postToolUse": {
+    "toolName": "string",
+    "parameters": {},
+    "result": "string",
+    "success": boolean,
+    "executionTimeMs": number
+  }
+}
+```
+
+### User Interaction
+
+These hooks monitor and enhance user communication with Cline. Use them to validate input, inject context, and track interaction patterns.
+
+#### UserPromptSubmit
+
+Runs when a user sends a message to Cline. Use it to validate input, inject context based on the prompt, and track interaction patterns.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "UserPromptSubmit",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "userPromptSubmit": {
+    "prompt": "string",
+    "attachments": ["string"]
+  }
+}
+```
+
+### Task Lifecycle
+
+These hooks monitor and respond to task state changes from start to finish. Use them to track progress, restore state, and trigger workflows.
+
+#### TaskStart
+
+Runs when a new task begins. Use it to detect project type, initialize tracking, and inject initial context that shapes how Cline approaches the work.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "TaskStart",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "taskStart": {
+    "taskMetadata": {
+      "taskId": "string",
+      "ulid": "string",
+      "initialTask": "string"
+    }
+  }
+}
+```
+
+#### TaskResume
+
+Runs when a task resumes after interruption. Use it to restore state, refresh context, and log resumption for analytics or external system notifications.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "TaskResume",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "taskResume": {
+    "taskMetadata": {
+      "taskId": "string",
+      "ulid": "string"
+    },
+    "previousState": {
+      "lastMessageTs": "string",
+      "messageCount": "string",
+      "conversationHistoryDeleted": "string"
+    }
+  }
+}
+```
+
+#### TaskCancel
+
+Runs when a task is cancelled. Use it to cleanup resources, log cancellation details, and notify external systems about interrupted work.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "TaskCancel",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "taskCancel": {
+    "taskMetadata": {
+      "taskId": "string",
+      "ulid": "string",
+      "completionStatus": "string"
+    }
+  }
+}
+```
+
+{/*
+#### TaskComplete
+
+Runs when a task finishes successfully. Use it for final cleanup, tracking metrics, generating reports, and triggering post-task workflows.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "TaskComplete",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "taskComplete": {
+    "taskMetadata": {
+      "taskId": "string",
+      "ulid": "string"
+    }
+  }
+}
+```
+*/}
+
+### System Events
+
+These hooks monitor internal Cline operations and system-level events. Use them to track context usage, log system behavior, and analyze performance patterns.
+
+{/*
+#### PreCompact
+
+Runs before conversation context is truncated to fit token limits. Use it to monitor compaction frequency, log events, and track context usage patterns.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "PreCompact",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "preCompact": {
+    "contextSize": number,
+    "messagesToCompact": number,
+    "compactionStrategy": "string"
+  }
+}
+```
+*/}
+
+### JSON Communication
+
+Hooks receive JSON via stdin and return JSON via stdout.
+
+**Output structure:**
+```json
+{
+  "cancel": false,
+  "contextModification": "WORKSPACE_RULES: Use TypeScript",
+  "errorMessage": "Error details if blocking"
+}
+```
+
+Your hook script can output logging or diagnostic information to stdout during execution, as long as the JSON response is the last thing written. Cline will parse only the final JSON object from stdout.
+
+For example:
+```bash
+#!/usr/bin/env bash
+echo "Processing hook..."  # This is fine
+echo "Tool: $tool_name"    # This is also fine
+# The JSON must be last:
+echo '{"cancel": false}'
+```
+
+The `cancel` field controls whether execution continues. Set it to `true` to block an action, `false` to allow it.
+
+The `contextModification` field injects text into the conversation. This affects future AI decisions, not the current one. Use prefixes like `WORKSPACE_RULES:` or `PERFORMANCE:` to help categorize the context.
+
+### Understanding Context Timing
+
+Context injection affects future decisions, not current ones. When a hook runs:
+
+1. The AI has already decided what to do
+2. The hook can block or allow it
+3. Any context gets added to the conversation
+4. The next AI request sees that context
+
+This means PreToolUse hooks are for blocking bad actions, while PostToolUse hooks are for learning from completed ones.
+
+
+## What You Can Build
+
+Once you understand the basics, hooks open up creative possibilities:
+
+- **Intelligent Code Review**:
+Run linters or custom validators before files get saved. Block commits that don't pass checks. Track code quality metrics over time.
+
+- **Security Enforcement**:
+Prevent operations that violate security policies. Detect when sensitive data might be exposed. Audit all file access for compliance.
+
+- **Development Analytics**: Measure how long different operations take. Identify patterns in how the AI works. Generate productivity reports from hook data.
+
+- **Integration Hub**: Connect to issue trackers when certain keywords appear. Update project management tools. Sync with external APIs at the right moments.
+
+The key is combining hooks with external tools. A hook can be the glue between Cline's workflow and the rest of your development ecosystem.
+
+## Troubleshooting
+
+### Hook Not Running
+- Ensure the "Enable Hooks" setting is checked
+- Verify the hook file is executable (`chmod +x hookname`)
+- Check the hook file has no syntax errors
+- Look for errors in VSCode's Output panel (Cline channel)
+
+### Hook Timing Out
+- Reduce complexity of the hook script
+- Avoid expensive operations (network calls, heavy computations)
+- Consider moving complex logic to a background process
+
+### Context Not Affecting Behavior
+- Remember: context affects FUTURE decisions, not the current tool
+- The current AI behavior is based on the previous "API Request..." block
+- Your `contextModification` gets injected into the NEXT "API Request..." block
+- Use PreToolUse for validation (blocking) if you need immediate effect
+- Ensure context modifications are clear and actionable
+- Check that context isn't being truncated (50KB limit)
+
+<Warning>
+Hooks run with the same permissions as VS Code. They can access all workspace files and environment variables. Review hooks from untrusted sources before enabling them.
+</Warning>
+
+## Related Features
+
+Hooks complement other Cline features:
+
+- [Cline Rules](/features/cline-rules) define high-level guidance that hooks can enforce
+- [Checkpoints](/features/checkpoints) let you roll back changes if a hook didn't catch an issue
+- [Auto-Approve](/features/auto-approve) works well with hooks as safety nets for automated operations

package-lock.json

@@ -1,12 +1,12 @@
 {
 	"name": "claude-dev",
-	"version": "3.35.1",
+	"version": "3.36.1",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "claude-dev",
-			"version": "3.35.1",
+			"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",
@@ -72,12 +73,13 @@
 				"jschardet": "^3.1.4",
 				"jwt-decode": "^4.0.0",
 				"mammoth": "^1.11.0",
+				"nanoid": "^5.1.6",
 				"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",
@@ -6493,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,
@@ -7840,6 +7851,7 @@
 		},
 		"node_modules/bundle-name": {
 			"version": "4.1.0",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"run-applescript": "^7.0.0"
@@ -8806,6 +8818,7 @@
 		},
 		"node_modules/default-browser": {
 			"version": "5.2.1",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"bundle-name": "^4.1.0",
@@ -8820,6 +8833,7 @@
 		},
 		"node_modules/default-browser-id": {
 			"version": "5.0.0",
+			"dev": true,
 			"license": "MIT",
 			"engines": {
 				"node": ">=18"
@@ -8882,6 +8896,7 @@
 		},
 		"node_modules/define-lazy-prop": {
 			"version": "3.0.0",
+			"dev": true,
 			"license": "MIT",
 			"engines": {
 				"node": ">=12"
@@ -11427,6 +11442,7 @@
 		},
 		"node_modules/is-inside-container": {
 			"version": "1.0.0",
+			"dev": true,
 			"license": "MIT",
 			"dependencies": {
 				"is-docker": "^3.0.0"
@@ -11443,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"
@@ -13385,9 +13402,9 @@
 			}
 		},
 		"node_modules/nanoid": {
-			"version": "3.3.11",
-			"resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.11.tgz",
-			"integrity": "sha512-N8SpfPUnUp1bK+PMYW8qSWdl9U+wwNWI4QKxOYDy9JAro3WMX7p2OeVRF9v+347pnakNevPmiHhNmZ2HbFA76w==",
+			"version": "5.1.6",
+			"resolved": "https://registry.npmjs.org/nanoid/-/nanoid-5.1.6.tgz",
+			"integrity": "sha512-c7+7RQ+dMB5dPwwCp4ee1/iV/q2P6aK1mTZcfr1BTuVlyW9hJYiMPybJCcnBlQtuSmTIWNeazm/zqNoZSSElBg==",
 			"funding": [
 				{
 					"type": "github",
@@ -13395,12 +13412,11 @@
 				}
 			],
 			"license": "MIT",
-			"peer": true,
 			"bin": {
-				"nanoid": "bin/nanoid.cjs"
+				"nanoid": "bin/nanoid.js"
 			},
 			"engines": {
-				"node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
+				"node": "^18 || >=20"
 			}
 		},
 		"node_modules/napi-build-utils": {
@@ -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",
@@ -15093,6 +15132,25 @@
 				"node": "^10 || ^12 || >=14"
 			}
 		},
+		"node_modules/postcss/node_modules/nanoid": {
+			"version": "3.3.11",
+			"resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.11.tgz",
+			"integrity": "sha512-N8SpfPUnUp1bK+PMYW8qSWdl9U+wwNWI4QKxOYDy9JAro3WMX7p2OeVRF9v+347pnakNevPmiHhNmZ2HbFA76w==",
+			"funding": [
+				{
+					"type": "github",
+					"url": "https://github.com/sponsors/ai"
+				}
+			],
+			"license": "MIT",
+			"peer": true,
+			"bin": {
+				"nanoid": "bin/nanoid.cjs"
+			},
+			"engines": {
+				"node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
+			}
+		},
 		"node_modules/posthog-node": {
 			"version": "5.8.0",
 			"resolved": "https://registry.npmjs.org/posthog-node/-/posthog-node-5.8.0.tgz",
@@ -15823,6 +15881,7 @@
 		},
 		"node_modules/run-applescript": {
 			"version": "7.0.0",
+			"dev": true,
 			"license": "MIT",
 			"engines": {
 				"node": ">=18"

package.json

@@ -2,7 +2,7 @@
 	"name": "claude-dev",
 	"displayName": "Cline",
 	"description": "Autonomous coding agent right in your IDE, capable of creating/editing files, running commands, using the browser, and more with your permission every step of the way.",
-	"version": "3.35.1",
+	"version": "3.36.1",
 	"icon": "assets/icons/icon.png",
 	"engines": {
 		"vscode": "^1.84.0"
@@ -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",
@@ -466,12 +468,13 @@
 		"jschardet": "^3.1.4",
 		"jwt-decode": "^4.0.0",
 		"mammoth": "^1.11.0",
+		"nanoid": "^5.1.6",
 		"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

@@ -96,6 +96,7 @@ message OpenRouterModelInfo {
   optional ThinkingConfig thinking_config = 10;
   optional bool supports_global_endpoint = 11;
   repeated ModelTier tiers = 12;
+  optional string name = 13;
 }
 
 // Shared response message for model information
@@ -312,7 +313,7 @@ message ApiConfiguration {
 // Request for updating API configuration (new - uses separate options and secrets)
 message UpdateApiConfigurationRequestNew {
   Metadata metadata = 1;
-  ApiConfiguration api_configuration = 2;
+  ApiConfiguration updates = 2;
 
   // Required field mask specifying which fields to update.
   // Field paths use dot notation with camelCase field names:
@@ -320,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

proto/cline/state.proto

@@ -23,6 +23,7 @@ service StateService {
   rpc updateSettingsCli(UpdateSettingsRequestCli) returns (Empty);
   rpc updateTaskSettings(UpdateTaskSettingsRequest) returns (Empty);
   rpc updateTelemetrySetting(TelemetrySettingRequest) returns (Empty);
+  rpc captureOnboardingProgress(OnboardingProgressRequest) returns (Empty);
   rpc setWelcomeViewCompleted(BooleanRequest) returns (Empty);
   rpc updateInfoBannerVersion(Int64Request) returns (Empty);
   rpc updateModelBannerVersion(Int64Request) returns (Empty);
@@ -379,3 +380,10 @@ message ProcessInfo {
   optional string version = 2;
   optional int64 uptime_ms = 3;
 }
+
+message OnboardingProgressRequest {
+  int32 step = 1;
+  optional string action = 2;
+  optional bool completed = 3;
+  optional string model_selected = 4;
+}

proto/cline/ui.proto

@@ -77,6 +77,7 @@ enum ClineSayToolType {
   LIST_CODE_DEFINITION_NAMES = 5;
   SEARCH_FILES = 6;
   WEB_FETCH = 7;
+  FILE_DELETED = 8;
 }
 
 // Enum for browser actions

src/config.ts

@@ -62,7 +62,7 @@ class ClineEndpoint {
 					environment: Environment.staging,
 					appBaseUrl: "https://staging-app.cline.bot",
 					apiBaseUrl: "https://core-api.staging.int.cline.bot",
-					mcpBaseUrl: "https://api.cline.bot/v1/mcp",
+					mcpBaseUrl: "https://core-api.staging.int.cline.bot/v1/mcp",
 					firebase: {
 						apiKey: "AIzaSyASSwkwX1kSO8vddjZkE5N19QU9cVQ0CIk",
 						authDomain: "cline-staging.firebaseapp.com",

src/core/api/providers/aihubmix.ts

@@ -27,7 +27,7 @@ export class AIhubmixHandler implements ApiHandler {
 		const { baseURL, appCode, ...rest } = options
 		this.options = {
 			baseURL: baseURL ?? "https://aihubmix.com",
-			appCode: appCode ?? "KUWF9311", // 应用代码，享受折扣
+			appCode: appCode ?? "KUWF9311",
 			...rest,
 		}
 	}
@@ -81,7 +81,6 @@ export class AIhubmixHandler implements ApiHandler {
 				this.geminiClient = new GoogleGenAI({
 					apiKey: this.options.apiKey,
 					httpOptions: {
-						// AIhubmix Gemini 兼容网关，按 Google GenAI 路径规范
 						baseUrl: `${this.options.baseURL}/gemini`,
 						headers: {
 							// @ts-expect-error
@@ -97,9 +96,6 @@ export class AIhubmixHandler implements ApiHandler {
 		return this.geminiClient
 	}
 
-	/**
-	 * 根据模型名称路由到对应的客户端
-	 */
 	private routeModel(modelName: string): "anthropic" | "openai" | "gemini" | "openai-response" {
 		const id = modelName || ""
 		if (id.startsWith("claude")) {
@@ -114,9 +110,6 @@ export class AIhubmixHandler implements ApiHandler {
 		return "openai"
 	}
 
-	/**
-	 * 修复空工具时的 tool_choice 问题
-	 */
 	private fixToolChoice(requestBody: any): any {
 		if (requestBody.tools?.length === 0 && requestBody.tool_choice) {
 			delete requestBody.tool_choice
@@ -203,25 +196,21 @@ export class AIhubmixHandler implements ApiHandler {
 		const client = this.ensureOpenaiClient()
 		const modelId = this.options.modelId || "gpt-4o-mini"
 
-		// 将 Anthropic 风格消息转换为 Responses API 的 input 结构
 		const input = (messages || []).map((m: any) => {
 			const role = m.role || "user"
 			const contentArray = Array.isArray(m.content) ? m.content : [{ type: "text", text: m.content }]
 			const content = contentArray
 				.filter((c: any) => c != null)
 				.map((c: any) => {
-					// 图片
 					if (c.type === "image" || c.type === "input_image" || c.type === "image_url") {
 						return { type: "input_image", image_url: c.image_url || c.url || c.source?.url }
 					}
-					// 文本（用户 -> input_text，助手 -> output_text）
 					const text = c.text ?? (typeof c === "string" ? c : "")
 					return { type: role === "assistant" ? "output_text" : "input_text", text }
 				})
 			return { role, content }
 		})
 
-		// 使用 Responses 流式 API，以事件驱动产出
 		const stream = await (client as any).responses.stream({
 			model: modelId,
 			instructions: systemPrompt,
@@ -261,7 +250,6 @@ export class AIhubmixHandler implements ApiHandler {
 			stream: true,
 		}
 
-		// 修复空工具问题
 		const fixedRequestBody = this.fixToolChoice(requestBody)
 
 		const stream = await client.chat.completions.create(fixedRequestBody)

src/core/api/providers/anthropic.ts

@@ -1,11 +1,12 @@
 import { Anthropic } from "@anthropic-ai/sdk"
-import { Tool as AnthropicTool, MessageParam } from "@anthropic-ai/sdk/resources/index"
+import { Tool as AnthropicTool } from "@anthropic-ai/sdk/resources/index"
 import { Stream as AnthropicStream } from "@anthropic-ai/sdk/streaming"
 import { AnthropicModelId, anthropicDefaultModelId, anthropicModels, CLAUDE_SONNET_1M_SUFFIX, ModelInfo } from "@shared/api"
 import { fetch } from "@/shared/net"
 import { ClineTool } from "@/shared/tools"
 import { ApiHandler, CommonApiHandlerOptions } from "../index"
 import { withRetry } from "../retry"
+import { sanitizeAnthropicMessages } from "../transform/anthropic-format"
 import { ApiStream } from "../transform/stream"
 
 interface AnthropicHandlerOptions extends CommonApiHandlerOptions {
@@ -63,6 +64,7 @@ export class AnthropicHandler implements ApiHandler {
 		switch (modelId) {
 			// 'latest' alias does not support cache_control
 			case "claude-haiku-4-5-20251001":
+			case "claude-sonnet-4-5-20250929:1m":
 			case "claude-sonnet-4-5-20250929":
 			case "claude-sonnet-4-20250514":
 			case "claude-3-7-sonnet-20250219":
@@ -84,35 +86,7 @@ export class AnthropicHandler implements ApiHandler {
 				const lastUserMsgIndex = userMsgIndices[userMsgIndices.length - 1] ?? -1
 				const secondLastMsgUserIndex = userMsgIndices[userMsgIndices.length - 2] ?? -1
 
-				const anthropicMessages: Array<MessageParam> = messages.map((message, index) => {
-					if (index === lastUserMsgIndex || index === secondLastMsgUserIndex) {
-						return {
-							...message,
-							content:
-								typeof message.content === "string"
-									? [
-											{
-												type: "text",
-												text: message.content,
-												cache_control: {
-													type: "ephemeral",
-												},
-											},
-										]
-									: message.content.map((content, contentIndex) =>
-											contentIndex === message.content.length - 1
-												? {
-														...content,
-														cache_control: {
-															type: "ephemeral",
-														},
-													}
-												: content,
-										),
-						}
-					}
-					return message
-				})
+				const anthropicMessages = sanitizeAnthropicMessages(messages, lastUserMsgIndex, secondLastMsgUserIndex)
 
 				stream = await client.messages.create(
 					{
@@ -161,7 +135,7 @@ export class AnthropicHandler implements ApiHandler {
 					max_tokens: model.info.maxTokens || 8192,
 					temperature: 0,
 					system: [{ text: systemPrompt, type: "text" }],
-					messages,
+					messages: sanitizeAnthropicMessages(messages),
 					// tools,
 					// tool_choice: { type: "auto" },
 					stream: true,

src/core/api/providers/requesty.ts

@@ -2,8 +2,8 @@ import { Anthropic } from "@anthropic-ai/sdk"
 import { ModelInfo, requestyDefaultModelId, requestyDefaultModelInfo } from "@shared/api"
 import { calculateApiCostOpenAI } from "@utils/cost"
 import OpenAI from "openai"
+import { toRequestyServiceStringUrl } from "@/shared/clients/requesty"
 import { fetch } from "@/shared/net"
-import { toRequestyServiceStringUrl } from "@/shared/providers/requesty"
 import { ApiHandler, CommonApiHandlerOptions } from "../index"
 import { withRetry } from "../retry"
 import { convertToOpenAiMessages } from "../transform/openai-format"

src/core/api/providers/vertex.ts

@@ -6,6 +6,7 @@ import { ModelInfo, VertexModelId, vertexDefaultModelId, vertexModels } from "@s
 import { ClineTool } from "@/shared/tools"
 import { ApiHandler, CommonApiHandlerOptions } from "../"
 import { withRetry } from "../retry"
+import { sanitizeAnthropicMessages } from "../transform/anthropic-format"
 import { ApiStream } from "../transform/stream"
 import { GeminiHandler } from "./gemini"
 
@@ -122,46 +123,7 @@ export class VertexHandler implements ApiHandler {
 								cache_control: { type: "ephemeral" },
 							},
 						],
-						messages: messages.map((message, index) => {
-							if (index === lastUserMsgIndex || index === secondLastMsgUserIndex) {
-								return {
-									...message,
-									content:
-										typeof message.content === "string"
-											? [
-													{
-														type: "text",
-														text: message.content,
-														cache_control: {
-															type: "ephemeral",
-														},
-													},
-												]
-											: message.content.map((content, contentIndex) =>
-													contentIndex === message.content.length - 1
-														? {
-																...content,
-																cache_control: {
-																	type: "ephemeral",
-																},
-															}
-														: content,
-												),
-								}
-							}
-							return {
-								...message,
-								content:
-									typeof message.content === "string"
-										? [
-												{
-													type: "text",
-													text: message.content,
-												},
-											]
-										: message.content,
-							}
-						}),
+						messages: sanitizeAnthropicMessages(messages, lastUserMsgIndex, secondLastMsgUserIndex),
 						stream: true,
 						tools: tools?.length ? (tools as AnthropicTool[]) : undefined,
 						// tool_choice options:
@@ -187,18 +149,7 @@ export class VertexHandler implements ApiHandler {
 							type: "text",
 						},
 					],
-					messages: messages.map((message) => ({
-						...message,
-						content:
-							typeof message.content === "string"
-								? [
-										{
-											type: "text",
-											text: message.content,
-										},
-									]
-								: message.content,
-					})),
+					messages: sanitizeAnthropicMessages(messages),
 					stream: true,
 					tools: tools?.length ? (tools as AnthropicTool[]) : undefined,
 					// tool_choice options:

src/core/api/transform/anthropic-format.ts

@@ -1,19 +1,77 @@
-import { Tool as AnthropicTool } from "@anthropic-ai/sdk/resources/index"
-import { ChatCompletionTool as OpenAITool } from "openai/resources/chat/completions"
+import { MessageParam } from "@anthropic-ai/sdk/resources/index"
 
 /**
- * Converts an OpenAI ChatCompletionTool into an Anthropic Tool definition
+ * Sanitize Anthropic messages by removing reasoning details and adding ephemeral cache control
+ * to the last two user messages to prevent them from being stored in Anthropic's cache.
  */
-export function openAIToolToAnthropic(openAITool: OpenAITool): AnthropicTool {
-	const func = openAITool.function
+export function sanitizeAnthropicMessages(
+	messages: Array<MessageParam>,
+	lastUserMsgIndex?: number,
+	secondLastMsgUserIndex?: number,
+): Array<MessageParam> {
+	return messages.map((_message, index) => {
+		const message = removeReasoningDetails(_message)
+		const addCacheControl = lastUserMsgIndex !== undefined && secondLastMsgUserIndex !== undefined
 
-	return {
-		name: func.name,
-		description: func.description || "",
-		input_schema: {
-			type: "object",
-			properties: func.parameters?.properties || {},
-			required: func.parameters?.required || [],
-		},
-	}
+		if (addCacheControl && (index === lastUserMsgIndex || index === secondLastMsgUserIndex)) {
+			return {
+				...message,
+				content:
+					typeof message.content === "string"
+						? [
+								{
+									type: "text",
+									text: message.content,
+									cache_control: {
+										type: "ephemeral",
+									},
+								},
+							]
+						: message.content.map((content, contentIndex) =>
+								contentIndex === message.content.length - 1
+									? {
+											...content,
+											cache_control: {
+												type: "ephemeral",
+											},
+										}
+									: content,
+							),
+			}
+		}
+
+		return {
+			...message,
+			content:
+				typeof message.content === "string"
+					? [
+							{
+								type: "text",
+								text: message.content,
+							},
+						]
+					: message.content,
+		}
+	})
+}
+
+/**
+ * Remove reasoning details from a single Anthropic message parameter
+ */
+function removeReasoningDetails(param: MessageParam): MessageParam {
+	if (Array.isArray(param.content)) {
+		return {
+			...param,
+			content: param.content.map((item) => {
+				if (item.type === "text") {
+					return {
+						...item,
+						reasoning_details: undefined,
+					}
+				}
+				return item
+			}),
+		}
+	}
+	return param
 }

src/core/api/transform/gemini-format.ts

@@ -5,40 +5,44 @@ export function convertAnthropicContentToGemini(content: string | Anthropic.Cont
 	if (typeof content === "string") {
 		return [{ text: content }]
 	}
-	return content.flatMap((block): Part => {
-		switch (block.type) {
-			case "text":
-				return { text: block.text }
-			case "image":
-				if (block.source.type !== "base64") {
-					throw new Error("Unsupported image source type")
-				}
-				return {
-					inlineData: {
-						data: block.source.data,
-						mimeType: block.source.media_type,
-					},
-				}
-			case "tool_use":
-				return {
-					functionCall: {
-						name: block.name,
-						args: block.input as Record<string, unknown>,
-					},
-				}
-			case "tool_result":
-				return {
-					functionResponse: {
-						name: block.tool_use_id,
-						response: {
-							result: block.content,
+	return content
+		.flatMap((block): Part | undefined => {
+			switch (block.type) {
+				case "text":
+					return { text: block.text }
+				case "image":
+					if (block.source.type !== "base64") {
+						throw new Error("Unsupported image source type")
+					}
+					return {
+						inlineData: {
+							data: block.source.data,
+							mimeType: block.source.media_type,
 						},
-					},
-				}
-			default:
-				throw new Error(`Unsupported content block type: ${block.type}`)
-		}
-	})
+					}
+				case "tool_use":
+					return {
+						functionCall: {
+							name: block.name,
+							args: block.input as Record<string, unknown>,
+						},
+					}
+				case "tool_result":
+					return {
+						functionResponse: {
+							name: block.tool_use_id,
+							response: {
+								result: block.content,
+							},
+						},
+					}
+				case "thinking":
+					return { text: block.thinking, thought: true, thoughtSignature: block.signature }
+				default:
+					return undefined
+			}
+		})
+		.filter((part): part is Part => part !== undefined) // Filter out unsupported blocks
 }
 
 export function convertAnthropicMessageToGemini(message: Anthropic.Messages.MessageParam): Content {

src/core/controller/account/requestyAuthClicked.ts

@@ -1,6 +1,6 @@
 import { Empty, StringRequest } from "@shared/proto/cline/common"
-import { toRequestyServiceUrl } from "@shared/providers/requesty"
 import { HostProvider } from "@/hosts/host-provider"
+import { toRequestyServiceUrl } from "@/shared/clients/requesty"
 import { openExternal } from "@/utils/env"
 import { Controller } from ".."
 

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 {
@@ -853,9 +855,9 @@ export class Controller {
 		const vscodeTerminalExecutionMode = this.stateManager.getGlobalStateKey("vscodeTerminalExecutionMode")
 		const defaultTerminalProfile = this.stateManager.getGlobalSettingsKey("defaultTerminalProfile")
 		const isNewUser = this.stateManager.getGlobalStateKey("isNewUser")
-		const welcomeViewCompleted = Boolean(
-			this.stateManager.getGlobalStateKey("welcomeViewCompleted") || this.authService.getInfo()?.user?.uid,
-		)
+		// Can be undefined but is set to either true or false by the migration that runs on extension launch in extension.ts
+		const welcomeViewCompleted = !!this.stateManager.getGlobalStateKey("welcomeViewCompleted")
+
 		const customPrompt = this.stateManager.getGlobalSettingsKey("customPrompt")
 		const mcpResponsesCollapsed = this.stateManager.getGlobalStateKey("mcpResponsesCollapsed")
 		const terminalOutputLineLimit = this.stateManager.getGlobalSettingsKey("terminalOutputLineLimit")
@@ -932,7 +934,7 @@ export class Controller {
 			vscodeTerminalExecutionMode: vscodeTerminalExecutionMode,
 			defaultTerminalProfile,
 			isNewUser,
-			welcomeViewCompleted: welcomeViewCompleted as boolean, // Can be undefined but is set to either true or false by the migration that runs on extension launch in extension.ts
+			welcomeViewCompleted,
 			mcpResponsesCollapsed,
 			terminalOutputLineLimit,
 			maxConsecutiveMistakes,
@@ -954,7 +956,7 @@ export class Controller {
 			},
 			hooksEnabled: {
 				user: this.stateManager.getGlobalStateKey("hooksEnabled"),
-				featureFlag: featureFlagsService.getHooksEnabled(),
+				featureFlag: true, // Hooks feature is now always available
 			},
 			lastDismissedInfoBannerVersion,
 			lastDismissedModelBannerVersion,

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

@@ -4,7 +4,13 @@ import axios from "axios"
 import cloneDeep from "clone-deep"
 import fs from "fs/promises"
 import path from "path"
-import { CLAUDE_SONNET_1M_TIERS, openRouterClaudeSonnet41mModelId, openRouterClaudeSonnet451mModelId } from "@/shared/api"
+import {
+	ANTHROPIC_MAX_THINKING_BUDGET,
+	CLAUDE_SONNET_1M_TIERS,
+	openRouterClaudeSonnet41mModelId,
+	openRouterClaudeSonnet451mModelId,
+} from "@/shared/api"
+import { getAxiosSettings } from "@/shared/net"
 import type { Controller } from ".."
 
 type OpenRouterSupportedParams =
@@ -59,7 +65,6 @@ interface OpenRouterRawModelInfo {
 		input_cache_read: string
 		input_cache_write: string
 	} | null
-	thinking_config: Record<string, unknown> | null
 	supports_global_endpoint: boolean | null
 	tiers: any[] | null
 	supported_parameters?: OpenRouterSupportedParams[] | null
@@ -75,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
@@ -86,8 +91,10 @@ export async function refreshOpenRouterModels(controller: Controller): Promise<R
 				return undefined
 			}
 			for (const rawModel of rawModels as OpenRouterRawModelInfo[]) {
-				const supportThinking = rawModel.supported_parameters?.some((p) => p === "include_reasoning")
+				const supportThinking = rawModel.supported_parameters?.some((p) => p === "include_reasoning" || p === "reasoning")
+
 				const modelInfo: ModelInfo = {
+					name: rawModel.name,
 					maxTokens: rawModel.top_provider?.max_completion_tokens ?? 0,
 					contextWindow: rawModel.context_length ?? 0,
 					supportsImages: rawModel.architecture?.modality?.includes("image") ?? false,
@@ -97,7 +104,9 @@ export async function refreshOpenRouterModels(controller: Controller): Promise<R
 					cacheWritesPrice: parsePrice(rawModel.pricing?.input_cache_write),
 					cacheReadsPrice: parsePrice(rawModel.pricing?.input_cache_read),
 					description: rawModel.description ?? "",
-					thinkingConfig: (supportThinking && rawModel.thinking_config) || undefined,
+					// If thinking is supported, set maxBudget with a default value as a placeholder
+					// to ensure it has a valid thinkingConfig that lets the application know thinking is supported.
+					thinkingConfig: supportThinking ? { maxBudget: ANTHROPIC_MAX_THINKING_BUDGET } : undefined,
 					supportsGlobalEndpoint: rawModel.supports_global_endpoint ?? undefined,
 					tiers: rawModel.tiers ?? undefined,
 				}

src/core/controller/models/refreshRequestyModels.ts

@@ -1,7 +1,8 @@
 import { EmptyRequest } from "@shared/proto/cline/common"
 import { OpenRouterCompatibleModelInfo, OpenRouterModelInfo } from "@shared/proto/cline/models"
 import axios from "axios"
-import { toRequestyServiceUrl } from "@/shared/providers/requesty"
+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/controller/models/updateApiConfiguration.ts

@@ -31,6 +31,20 @@ function parseFieldMask(updateMask: string[]): {
 	return { options, secrets }
 }
 
+/**
+ * Gets the alternate mode field name (e.g., planModeX <-> actModeX)
+ * @param fieldName The field name to get alternate for
+ * @returns The alternate mode field name or null if not a mode-specific field
+ */
+function getAlternateModeField(fieldName: string): string | null {
+	if (fieldName.startsWith("planMode")) {
+		return fieldName.replace("planMode", "actMode")
+	} else if (fieldName.startsWith("actMode")) {
+		return fieldName.replace("actMode", "planMode")
+	}
+	return null
+}
+
 /**
  * Updates API configuration using field mask
  * @param controller The controller instance
@@ -39,9 +53,9 @@ function parseFieldMask(updateMask: string[]): {
  */
 export async function updateApiConfiguration(controller: Controller, request: UpdateApiConfigurationRequestNew): Promise<Empty> {
 	try {
-		const { apiConfiguration, updateMask } = request
+		const { updates, updateMask } = request
 
-		if (!apiConfiguration) {
+		if (!updates) {
 			throw new Error("API configuration is required")
 		}
 
@@ -49,7 +63,7 @@ export async function updateApiConfiguration(controller: Controller, request: Up
 			throw new Error("Update mask is required and must contain at least one path")
 		}
 
-		const { options: protoOptions, secrets: protoSecrets } = apiConfiguration
+		const { options: protoOptions, secrets: protoSecrets } = updates
 
 		// Parse the field mask to determine which fields to update
 		const { options: maskOptionsFields, secrets: maskSecretsFields } = parseFieldMask(updateMask)
@@ -81,6 +95,10 @@ export async function updateApiConfiguration(controller: Controller, request: Up
 					throw new Error(`Field "${fieldName}" specified in mask but not found in options`)
 				}
 			}
+
+			// Check if mode-specific configurations should be kept separate
+			const separateModeConfigs = controller.stateManager.getGlobalSettingsKey("planActSeparateModelsSetting")
+
 			// Process entries that are in the mask
 			for (const [key, value] of Object.entries(protoOptions)) {
 				if (maskOptionsFields.has(key)) {
@@ -92,6 +110,20 @@ export async function updateApiConfiguration(controller: Controller, request: Up
 					} else {
 						options[key as keyof ApiHandlerOptions] = value
 					}
+
+					// If mode configs should be synced, also update the alternate mode field
+					if (!separateModeConfigs) {
+						const alternateField = getAlternateModeField(key)
+						if (alternateField) {
+							if (alternateField === "planModeApiProvider") {
+								options.planModeApiProvider = convertProtoToApiProvider(value)
+							} else if (alternateField === "actModeApiProvider") {
+								options.actModeApiProvider = convertProtoToApiProvider(value)
+							} else {
+								options[alternateField as keyof ApiHandlerOptions] = value
+							}
+						}
+					}
 				}
 			}
 		}

src/core/controller/state/captureOnboardingProgress.ts

@@ -0,0 +1,25 @@
+import { Empty } from "@shared/proto/cline/common"
+import { OnboardingProgressRequest } from "@shared/proto/cline/state"
+import { telemetryService } from "../../../services/telemetry"
+import type { Controller } from "../index"
+
+/**
+ * Captures the onboarding progress step
+ * @param controller The controller instance
+ * @param request The request containing the step number
+ * @returns Empty response
+ */
+export async function captureOnboardingProgress(_controller: Controller, request: OnboardingProgressRequest): Promise<Empty> {
+	try {
+		telemetryService.captureOnboardingProgress({
+			step: Number(request.step),
+			model: request.modelSelected,
+			action: request.action,
+			completed: !!request.completed,
+		})
+		return Empty.create({})
+	} catch (error) {
+		console.error("Failed to set welcome view completed:", error)
+		throw error
+	}
+}

src/core/hooks/hook-factory.ts

@@ -308,10 +308,49 @@ class StdioHookRunner<Name extends HookName> extends HookRunner<Name> {
 					return output
 				} catch (parseError) {
 					// Try to extract JSON from stdout (it might have debug output before/after)
-					const jsonMatch = stdout.match(/\{[\s\S]*\}/)
-					if (jsonMatch) {
+					// Scan from the end to find the last complete JSON object
+					// This handles cases where hooks output debug info before the actual JSON response
+
+					const lines = stdout.split("\n")
+					let jsonCandidate = ""
+					let braceCount = 0
+					let startCollecting = false
+
+					// Scan from the end to find the last complete JSON object
+					for (let i = lines.length - 1; i >= 0; i--) {
+						const line = lines[i].trimEnd()
+
+						// Count braces to track JSON object boundaries
+						for (let j = line.length - 1; j >= 0; j--) {
+							if (line[j] === "}") {
+								braceCount++
+								if (!startCollecting) {
+									startCollecting = true
+								}
+							} else if (line[j] === "{") {
+								braceCount--
+							}
+						}
+
+						if (startCollecting) {
+							jsonCandidate = line + "\n" + jsonCandidate
+						}
+
+						// If we've closed all braces, we have a complete JSON object
+						if (startCollecting && braceCount === 0) {
+							break
+						}
+					}
+
+					if (jsonCandidate.trim()) {
 						try {
-							const outputData = JSON.parse(jsonMatch[0])
+							// Trim everything before the first opening bracket
+							const trimmedCandidate = jsonCandidate.trim()
+							const firstBraceIndex = trimmedCandidate.indexOf("{")
+							const cleanedJson =
+								firstBraceIndex !== -1 ? trimmedCandidate.slice(firstBraceIndex) : trimmedCandidate
+
+							const outputData = JSON.parse(cleanedJson)
 
 							// Validate structure
 							const validation = validateHookOutput(outputData)

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

@@ -0,0 +1,107 @@
+You are Cline, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
+
+TOOL USE
+
+You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
+
+====
+
+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.
+
+====
+
+ACT MODE V.S. PLAN MODE
+
+In each user message, the environment_details will specify the current mode. There are two modes:
+
+- ACT MODE: In this mode, you have access to all tools EXCEPT the plan_mode_respond tool.
+ - In ACT MODE, you use tools to accomplish the user's task. Once you've completed the user's task, you use the attempt_completion tool to present the result of the task to the user.
+- PLAN MODE: In this special mode, you have access to the plan_mode_respond tool.
+ - In PLAN MODE, the goal is to gather information and get context to create a detailed plan for accomplishing the task, which the user will review and approve before they switch you to ACT MODE to implement the solution.
+ - In PLAN MODE, when you need to converse with the user or present a plan, you should use the plan_mode_respond tool to deliver your response directly.
+
+## What is PLAN MODE?
+
+- While you are usually in ACT MODE, the user may switch to PLAN MODE in order to have a back and forth with you to plan how to best accomplish the task. 
+- When starting in PLAN MODE, depending on the user's request, you may need to do some information gathering e.g. using read_file or search_files to get more context about the task. You may also ask the user clarifying questions with ask_followup_question to get a better understanding of the task.
+- Once you've gained more context about the user's request, you should architect a detailed plan for how you will accomplish the task. Present the plan to the user using the plan_mode_respond tool.
+- Then you might ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
+- Finally once it seems like you've reached a good plan, ask the user to switch you back to ACT MODE to implement the solution.
+
+====
+
+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.
+- When the user initially gives you a task, a recursive list of all filepaths in the current working directory ('/test/project') will be included in environment_details. This provides an overview of the project's file structure, offering key insights into the project from directory/file names (how developers conceptualize and organize their code) and file extensions (the language used). This can also guide decision-making on which files to explore further. If you need to further explore directories such as outside the current working directory, you can use the list_files tool. If you pass 'true' for the recursive parameter, it will list files recursively. Otherwise, it will list files at the top level, which is better suited for generic directories where you don't necessarily need the nested structure, like the Desktop.
+- You can use search_files to perform regex searches across files in a specified directory, outputting context-rich results that include surrounding lines. This is particularly useful for understanding code patterns, finding specific implementations, or identifying areas that need refactoring.
+- You can use the list_code_definition_names tool to get an overview of source code definitions for all files at the top level of a specified directory. This can be particularly useful when you need to understand the broader context and relationships between certain parts of the code. You may need to call this tool multiple times to understand various parts of the codebase related to the task.
+    - For example, when asked to make edits or improvements you might analyze the file structure in the initial environment_details to get an overview of the project, then use list_code_definition_names to get further insight using source code definitions for files located in relevant directories, then read_file to examine the contents of relevant files, analyze the code and suggest improvements or make necessary edits, then use the replace_in_file tool to implement changes. If you refactored code that could affect other parts of the codebase, you could use search_files to ensure you update other files as needed.
+- You can use the execute_command tool to run commands on the user's computer whenever you feel it can help accomplish the user's task. When you need to execute a CLI command, you must provide a clear explanation of what the command does. Prefer to execute complex CLI commands over creating executable scripts, since they are more flexible and easier to run. Interactive and long-running commands are allowed, since the commands are run in the user's VSCode terminal. The user may keep commands running in the background and you will be kept updated on their status along the way. Each command you execute is run in a new terminal instance.
+- You can use the browser_action tool to interact with websites (including html files and locally running development servers) through a Puppeteer-controlled browser when you feel it is necessary in accomplishing the user's task. This tool is particularly useful for web development tasks as it allows you to launch a browser, navigate to pages, interact with elements through clicks and keyboard input, and capture the results through screenshots and console logs. This tool may be useful at key stages of web development tasks-such as after implementing new features, making substantial changes, when troubleshooting issues, or to verify the result of your work. You can analyze the provided screenshots to ensure correct rendering or identify errors, and review console logs for runtime issues.
+	- For example, if asked to add a component to a react website, you might create the necessary files, use execute_command to run the site locally, then use browser_action to launch the browser, navigate to the local server, and verify the component renders & functions correctly before closing the browser.
+- You have access to MCP servers that may provide additional tools and resources. Each server may provide different capabilities that you can use to accomplish tasks more effectively.
+
+====
+
+FEEDBACK
+
+When user is providing you with feedback on how you could improve, you can let the user know to report new issue using the '/reportbug' slash command.
+
+====
+
+RULES
+
+- Your current working directory is: /test/project - this is where you will be using tools from.
+- Do not use the ~ character or $HOME to refer to the home directory. Use absolute paths instead.
+- MCP operations should be used one at a time, similar to other tool usage. Wait for confirmation of success before proceeding with additional operations.
+
+====
+
+SYSTEM INFORMATION
+
+Operating System: macOS
+IDE: TestIde
+Default Shell: /bin/zsh
+Home Directory: /Users/tester
+Current Working Directory: /Users/tester/dev/project
+
+====
+
+OBJECTIVE
+
+You accomplish a given task iteratively, breaking it down into clear steps and working through them methodically.
+
+1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
+2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
+3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Then, think about which of the provided tools is the most relevant tool to accomplish the user's task. Next, go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+5. If the task is not actionable, you may use the attempt_completion tool to explain to the user why the task cannot be completed, or provide a simple answer if that is what the user is looking for.
+
+====
+
+USER'S CUSTOM INSTRUCTIONS
+
+The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
+
+Prefer TypeScript
+
+Follow global rules
+
+Follow local rules

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

@@ -0,0 +1,105 @@
+You are Cline, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
+
+TOOL USE
+
+You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
+
+====
+
+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.
+
+====
+
+ACT MODE V.S. PLAN MODE
+
+In each user message, the environment_details will specify the current mode. There are two modes:
+
+- ACT MODE: In this mode, you have access to all tools EXCEPT the plan_mode_respond tool.
+ - In ACT MODE, you use tools to accomplish the user's task. Once you've completed the user's task, you use the attempt_completion tool to present the result of the task to the user.
+- PLAN MODE: In this special mode, you have access to the plan_mode_respond tool.
+ - In PLAN MODE, the goal is to gather information and get context to create a detailed plan for accomplishing the task, which the user will review and approve before they switch you to ACT MODE to implement the solution.
+ - In PLAN MODE, when you need to converse with the user or present a plan, you should use the plan_mode_respond tool to deliver your response directly.
+
+## What is PLAN MODE?
+
+- While you are usually in ACT MODE, the user may switch to PLAN MODE in order to have a back and forth with you to plan how to best accomplish the task. 
+- When starting in PLAN MODE, depending on the user's request, you may need to do some information gathering e.g. using read_file or search_files to get more context about the task. You may also ask the user clarifying questions with ask_followup_question to get a better understanding of the task.
+- Once you've gained more context about the user's request, you should architect a detailed plan for how you will accomplish the task. Present the plan to the user using the plan_mode_respond tool.
+- Then you might ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
+- Finally once it seems like you've reached a good plan, ask the user to switch you back to ACT MODE to implement the solution.
+
+====
+
+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.
+- When the user initially gives you a task, a recursive list of all filepaths in the current working directory ('/test/project') will be included in environment_details. This provides an overview of the project's file structure, offering key insights into the project from directory/file names (how developers conceptualize and organize their code) and file extensions (the language used). This can also guide decision-making on which files to explore further. If you need to further explore directories such as outside the current working directory, you can use the list_files tool. If you pass 'true' for the recursive parameter, it will list files recursively. Otherwise, it will list files at the top level, which is better suited for generic directories where you don't necessarily need the nested structure, like the Desktop.
+- You can use search_files to perform regex searches across files in a specified directory, outputting context-rich results that include surrounding lines. This is particularly useful for understanding code patterns, finding specific implementations, or identifying areas that need refactoring.
+- You can use the list_code_definition_names tool to get an overview of source code definitions for all files at the top level of a specified directory. This can be particularly useful when you need to understand the broader context and relationships between certain parts of the code. You may need to call this tool multiple times to understand various parts of the codebase related to the task.
+    - For example, when asked to make edits or improvements you might analyze the file structure in the initial environment_details to get an overview of the project, then use list_code_definition_names to get further insight using source code definitions for files located in relevant directories, then read_file to examine the contents of relevant files, analyze the code and suggest improvements or make necessary edits, then use the replace_in_file tool to implement changes. If you refactored code that could affect other parts of the codebase, you could use search_files to ensure you update other files as needed.
+- You can use the execute_command tool to run commands on the user's computer whenever you feel it can help accomplish the user's task. When you need to execute a CLI command, you must provide a clear explanation of what the command does. Prefer to execute complex CLI commands over creating executable scripts, since they are more flexible and easier to run. Interactive and long-running commands are allowed, since the commands are run in the user's VSCode terminal. The user may keep commands running in the background and you will be kept updated on their status along the way. Each command you execute is run in a new terminal instance.
+- You have access to MCP servers that may provide additional tools and resources. Each server may provide different capabilities that you can use to accomplish tasks more effectively.
+
+====
+
+FEEDBACK
+
+When user is providing you with feedback on how you could improve, you can let the user know to report new issue using the '/reportbug' slash command.
+
+====
+
+RULES
+
+- Your current working directory is: /test/project - this is where you will be using tools from.
+- Do not use the ~ character or $HOME to refer to the home directory. Use absolute paths instead.
+- MCP operations should be used one at a time, similar to other tool usage. Wait for confirmation of success before proceeding with additional operations.
+
+====
+
+SYSTEM INFORMATION
+
+Operating System: macOS
+IDE: TestIde
+Default Shell: /bin/zsh
+Home Directory: /Users/tester
+Current Working Directory: /Users/tester/dev/project
+
+====
+
+OBJECTIVE
+
+You accomplish a given task iteratively, breaking it down into clear steps and working through them methodically.
+
+1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
+2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
+3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Then, think about which of the provided tools is the most relevant tool to accomplish the user's task. Next, go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+5. If the task is not actionable, you may use the attempt_completion tool to explain to the user why the task cannot be completed, or provide a simple answer if that is what the user is looking for.
+
+====
+
+USER'S CUSTOM INSTRUCTIONS
+
+The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
+
+Prefer TypeScript
+
+Follow global rules
+
+Follow local rules

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

@@ -0,0 +1,81 @@
+You are Cline, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
+
+TOOL USE
+
+You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
+
+====
+
+ACT MODE V.S. PLAN MODE
+
+In each user message, the environment_details will specify the current mode. There are two modes:
+
+- ACT MODE: In this mode, you have access to all tools EXCEPT the plan_mode_respond tool.
+ - In ACT MODE, you use tools to accomplish the user's task. Once you've completed the user's task, you use the attempt_completion tool to present the result of the task to the user.
+- PLAN MODE: In this special mode, you have access to the plan_mode_respond tool.
+ - In PLAN MODE, the goal is to gather information and get context to create a detailed plan for accomplishing the task, which the user will review and approve before they switch you to ACT MODE to implement the solution.
+ - In PLAN MODE, when you need to converse with the user or present a plan, you should use the plan_mode_respond tool to deliver your response directly.
+
+## What is PLAN MODE?
+
+- While you are usually in ACT MODE, the user may switch to PLAN MODE in order to have a back and forth with you to plan how to best accomplish the task. 
+- When starting in PLAN MODE, depending on the user's request, you may need to do some information gathering e.g. using read_file or search_files to get more context about the task. You may also ask the user clarifying questions with ask_followup_question to get a better understanding of the task.
+- Once you've gained more context about the user's request, you should architect a detailed plan for how you will accomplish the task. Present the plan to the user using the plan_mode_respond tool.
+- Then you might ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
+- Finally once it seems like you've reached a good plan, ask the user to switch you back to ACT MODE to implement the solution.
+
+====
+
+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.
+- When the user initially gives you a task, a recursive list of all filepaths in the current working directory ('/test/project') will be included in environment_details. This provides an overview of the project's file structure, offering key insights into the project from directory/file names (how developers conceptualize and organize their code) and file extensions (the language used). This can also guide decision-making on which files to explore further. If you need to further explore directories such as outside the current working directory, you can use the list_files tool. If you pass 'true' for the recursive parameter, it will list files recursively. Otherwise, it will list files at the top level, which is better suited for generic directories where you don't necessarily need the nested structure, like the Desktop.
+- You can use search_files to perform regex searches across files in a specified directory, outputting context-rich results that include surrounding lines. This is particularly useful for understanding code patterns, finding specific implementations, or identifying areas that need refactoring.
+- You can use the list_code_definition_names tool to get an overview of source code definitions for all files at the top level of a specified directory. This can be particularly useful when you need to understand the broader context and relationships between certain parts of the code. You may need to call this tool multiple times to understand various parts of the codebase related to the task.
+    - For example, when asked to make edits or improvements you might analyze the file structure in the initial environment_details to get an overview of the project, then use list_code_definition_names to get further insight using source code definitions for files located in relevant directories, then read_file to examine the contents of relevant files, analyze the code and suggest improvements or make necessary edits, then use the replace_in_file tool to implement changes. If you refactored code that could affect other parts of the codebase, you could use search_files to ensure you update other files as needed.
+- You can use the execute_command tool to run commands on the user's computer whenever you feel it can help accomplish the user's task. When you need to execute a CLI command, you must provide a clear explanation of what the command does. Prefer to execute complex CLI commands over creating executable scripts, since they are more flexible and easier to run. Interactive and long-running commands are allowed, since the commands are run in the user's VSCode terminal. The user may keep commands running in the background and you will be kept updated on their status along the way. Each command you execute is run in a new terminal instance.
+- You can use the browser_action tool to interact with websites (including html files and locally running development servers) through a Puppeteer-controlled browser when you feel it is necessary in accomplishing the user's task. This tool is particularly useful for web development tasks as it allows you to launch a browser, navigate to pages, interact with elements through clicks and keyboard input, and capture the results through screenshots and console logs. This tool may be useful at key stages of web development tasks-such as after implementing new features, making substantial changes, when troubleshooting issues, or to verify the result of your work. You can analyze the provided screenshots to ensure correct rendering or identify errors, and review console logs for runtime issues.
+	- For example, if asked to add a component to a react website, you might create the necessary files, use execute_command to run the site locally, then use browser_action to launch the browser, navigate to the local server, and verify the component renders & functions correctly before closing the browser.
+- You have access to MCP servers that may provide additional tools and resources. Each server may provide different capabilities that you can use to accomplish tasks more effectively.
+
+====
+
+RULES
+
+- Your current working directory is: /test/project - this is where you will be using tools from.
+- Do not use the ~ character or $HOME to refer to the home directory. Use absolute paths instead.
+- MCP operations should be used one at a time, similar to other tool usage. Wait for confirmation of success before proceeding with additional operations.
+
+====
+
+SYSTEM INFORMATION
+
+Operating System: macOS
+IDE: TestIde
+Default Shell: /bin/zsh
+Home Directory: /Users/tester
+Current Working Directory: /Users/tester/dev/project
+
+====
+
+OBJECTIVE
+
+You accomplish a given task iteratively, breaking it down into clear steps and working through them methodically.
+
+1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
+2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
+3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Then, think about which of the provided tools is the most relevant tool to accomplish the user's task. Next, go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+5. If the task is not actionable, you may use the attempt_completion tool to explain to the user why the task cannot be completed, or provide a simple answer if that is what the user is looking for.
+
+====
+
+USER'S CUSTOM INSTRUCTIONS
+
+The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
+
+Prefer TypeScript
+
+Follow global rules
+
+Follow local rules

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

@@ -0,0 +1,107 @@
+You are Cline, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
+
+TOOL USE
+
+You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
+
+====
+
+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.
+
+====
+
+ACT MODE V.S. PLAN MODE
+
+In each user message, the environment_details will specify the current mode. There are two modes:
+
+- ACT MODE: In this mode, you have access to all tools EXCEPT the plan_mode_respond tool.
+ - In ACT MODE, you use tools to accomplish the user's task. Once you've completed the user's task, you use the attempt_completion tool to present the result of the task to the user.
+- PLAN MODE: In this special mode, you have access to the plan_mode_respond tool.
+ - In PLAN MODE, the goal is to gather information and get context to create a detailed plan for accomplishing the task, which the user will review and approve before they switch you to ACT MODE to implement the solution.
+ - In PLAN MODE, when you need to converse with the user or present a plan, you should use the plan_mode_respond tool to deliver your response directly.
+
+## What is PLAN MODE?
+
+- While you are usually in ACT MODE, the user may switch to PLAN MODE in order to have a back and forth with you to plan how to best accomplish the task. 
+- When starting in PLAN MODE, depending on the user's request, you may need to do some information gathering e.g. using read_file or search_files to get more context about the task. You may also ask the user clarifying questions with ask_followup_question to get a better understanding of the task.
+- Once you've gained more context about the user's request, you should architect a detailed plan for how you will accomplish the task. Present the plan to the user using the plan_mode_respond tool.
+- Then you might ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
+- Finally once it seems like you've reached a good plan, ask the user to switch you back to ACT MODE to implement the solution.
+
+====
+
+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.
+- When the user initially gives you a task, a recursive list of all filepaths in the current working directory ('/test/project') will be included in environment_details. This provides an overview of the project's file structure, offering key insights into the project from directory/file names (how developers conceptualize and organize their code) and file extensions (the language used). This can also guide decision-making on which files to explore further. If you need to further explore directories such as outside the current working directory, you can use the list_files tool. If you pass 'true' for the recursive parameter, it will list files recursively. Otherwise, it will list files at the top level, which is better suited for generic directories where you don't necessarily need the nested structure, like the Desktop.
+- You can use search_files to perform regex searches across files in a specified directory, outputting context-rich results that include surrounding lines. This is particularly useful for understanding code patterns, finding specific implementations, or identifying areas that need refactoring.
+- You can use the list_code_definition_names tool to get an overview of source code definitions for all files at the top level of a specified directory. This can be particularly useful when you need to understand the broader context and relationships between certain parts of the code. You may need to call this tool multiple times to understand various parts of the codebase related to the task.
+    - For example, when asked to make edits or improvements you might analyze the file structure in the initial environment_details to get an overview of the project, then use list_code_definition_names to get further insight using source code definitions for files located in relevant directories, then read_file to examine the contents of relevant files, analyze the code and suggest improvements or make necessary edits, then use the replace_in_file tool to implement changes. If you refactored code that could affect other parts of the codebase, you could use search_files to ensure you update other files as needed.
+- You can use the execute_command tool to run commands on the user's computer whenever you feel it can help accomplish the user's task. When you need to execute a CLI command, you must provide a clear explanation of what the command does. Prefer to execute complex CLI commands over creating executable scripts, since they are more flexible and easier to run. Interactive and long-running commands are allowed, since the commands are run in the user's VSCode terminal. The user may keep commands running in the background and you will be kept updated on their status along the way. Each command you execute is run in a new terminal instance.
+- You can use the browser_action tool to interact with websites (including html files and locally running development servers) through a Puppeteer-controlled browser when you feel it is necessary in accomplishing the user's task. This tool is particularly useful for web development tasks as it allows you to launch a browser, navigate to pages, interact with elements through clicks and keyboard input, and capture the results through screenshots and console logs. This tool may be useful at key stages of web development tasks-such as after implementing new features, making substantial changes, when troubleshooting issues, or to verify the result of your work. You can analyze the provided screenshots to ensure correct rendering or identify errors, and review console logs for runtime issues.
+	- For example, if asked to add a component to a react website, you might create the necessary files, use execute_command to run the site locally, then use browser_action to launch the browser, navigate to the local server, and verify the component renders & functions correctly before closing the browser.
+- You have access to MCP servers that may provide additional tools and resources. Each server may provide different capabilities that you can use to accomplish tasks more effectively.
+
+====
+
+FEEDBACK
+
+When user is providing you with feedback on how you could improve, you can let the user know to report new issue using the '/reportbug' slash command.
+
+====
+
+RULES
+
+- Your current working directory is: /test/project - this is where you will be using tools from.
+- Do not use the ~ character or $HOME to refer to the home directory. Use absolute paths instead.
+- MCP operations should be used one at a time, similar to other tool usage. Wait for confirmation of success before proceeding with additional operations.
+
+====
+
+SYSTEM INFORMATION
+
+Operating System: macOS
+IDE: TestIde
+Default Shell: /bin/zsh
+Home Directory: /Users/tester
+Current Working Directory: /Users/tester/dev/project
+
+====
+
+OBJECTIVE
+
+You accomplish a given task iteratively, breaking it down into clear steps and working through them methodically.
+
+1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
+2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
+3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Then, think about which of the provided tools is the most relevant tool to accomplish the user's task. Next, go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+5. If the task is not actionable, you may use the attempt_completion tool to explain to the user why the task cannot be completed, or provide a simple answer if that is what the user is looking for.
+
+====
+
+USER'S CUSTOM INSTRUCTIONS
+
+The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
+
+Prefer TypeScript
+
+Follow global rules
+
+Follow local rules

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

@@ -73,6 +73,34 @@ Params: path, recursive (optional).
 </list_files>
 Key: Rely on returned tool results instead of using list_files to “confirm” writes.
 
+**load_mcp_documentation** - Load documentation about creating MCP servers. This tool should be used when the user requests to create or install an MCP server.
+Parameters: None
+*Example:*
+<load_mcp_documentation>
+</load_mcp_documentation>
+
+**use_mcp_tool** - Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
+Parameters: server_name, tool_name, arguments
+*Example:*
+<use_mcp_tool>
+<server_name>server name here</server_name>
+<tool_name>tool name here</tool_name>
+<arguments>
+{
+  "param1": "value1",
+  "param2": "value2"
+}
+</arguments>
+</use_mcp_tool>
+
+**access_mcp_resource** - Request to access a resource provided by a connected MCP server. Resources represent data sources that can be used as context, such as files, API responses, or system information.
+Parameters: server_name, uri
+*Example:*
+<access_mcp_resource>
+<server_name>server name here</server_name>
+<uri>resource URI here</uri>
+</access_mcp_resource>
+
 **attempt_completion** — Final result (no questions). Use this tool only when all goals have been completed.
 Params: result, command (optional demonstration of completed work).  
 *Example:*
@@ -100,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.
@@ -225,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.
@@ -255,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

@@ -73,6 +73,34 @@ Params: path, recursive (optional).
 </list_files>
 Key: Rely on returned tool results instead of using list_files to “confirm” writes.
 
+**load_mcp_documentation** - Load documentation about creating MCP servers. This tool should be used when the user requests to create or install an MCP server.
+Parameters: None
+*Example:*
+<load_mcp_documentation>
+</load_mcp_documentation>
+
+**use_mcp_tool** - Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
+Parameters: server_name, tool_name, arguments
+*Example:*
+<use_mcp_tool>
+<server_name>server name here</server_name>
+<tool_name>tool name here</tool_name>
+<arguments>
+{
+  "param1": "value1",
+  "param2": "value2"
+}
+</arguments>
+</use_mcp_tool>
+
+**access_mcp_resource** - Request to access a resource provided by a connected MCP server. Resources represent data sources that can be used as context, such as files, API responses, or system information.
+Parameters: server_name, uri
+*Example:*
+<access_mcp_resource>
+<server_name>server name here</server_name>
+<uri>resource URI here</uri>
+</access_mcp_resource>
+
 **attempt_completion** — Final result (no questions). Use this tool only when all goals have been completed.
 Params: result, command (optional demonstration of completed work).  
 *Example:*
@@ -100,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.
@@ -222,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.
@@ -252,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-focus-chain.snap

@@ -73,6 +73,34 @@ Params: path, recursive (optional).
 </list_files>
 Key: Rely on returned tool results instead of using list_files to “confirm” writes.
 
+**load_mcp_documentation** - Load documentation about creating MCP servers. This tool should be used when the user requests to create or install an MCP server.
+Parameters: None
+*Example:*
+<load_mcp_documentation>
+</load_mcp_documentation>
+
+**use_mcp_tool** - Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
+Parameters: server_name, tool_name, arguments
+*Example:*
+<use_mcp_tool>
+<server_name>server name here</server_name>
+<tool_name>tool name here</tool_name>
+<arguments>
+{
+  "param1": "value1",
+  "param2": "value2"
+}
+</arguments>
+</use_mcp_tool>
+
+**access_mcp_resource** - Request to access a resource provided by a connected MCP server. Resources represent data sources that can be used as context, such as files, API responses, or system information.
+Parameters: server_name, uri
+*Example:*
+<access_mcp_resource>
+<server_name>server name here</server_name>
+<uri>resource URI here</uri>
+</access_mcp_resource>
+
 **attempt_completion** — Final result (no questions). Use this tool only when all goals have been completed.
 Params: result, command (optional demonstration of completed work).  
 *Example:*

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/__tests__/integration.test.ts

@@ -234,6 +234,12 @@ describe("Prompt System Integration Tests", () => {
 			providerId: "openai",
 			contextVariations,
 		},
+		{
+			modelGroup: ModelFamily.NATIVE_GPT_5,
+			modelIds: ["gpt-5-codex"],
+			providerId: "openai",
+			contextVariations,
+		},
 	]
 
 	// Generate snapshots for all model/context combinations
@@ -257,7 +263,8 @@ describe("Prompt System Integration Tests", () => {
 							...baseContext,
 							providerInfo: makeMockProviderInfo(modelId, providerId),
 							isTesting: true,
-							enableNativeToolCalls: modelGroup === ModelFamily.NATIVE_NEXT_GEN,
+							enableNativeToolCalls:
+								modelGroup === ModelFamily.NATIVE_NEXT_GEN || modelGroup === ModelFamily.NATIVE_GPT_5,
 						}
 						it(`should generate consistent prompt for ${providerId}/${modelId} with ${contextName} context`, async function () {
 							this.timeout(30000) // Allow more time for prompt generation
@@ -299,10 +306,9 @@ describe("Prompt System Integration Tests", () => {
 														`This is a new test case. Run with --update-snapshots to create the initial snapshot.`,
 												),
 											)
-										} else {
-											// Re-throw comparison errors
-											throw error
 										}
+										// Re-throw comparison errors
+										throw error
 									}
 								}
 							} catch (error) {
@@ -390,14 +396,8 @@ describe("Prompt System Integration Tests", () => {
 			this.timeout(30000)
 
 			const invalidContext = {} as SystemPromptContext
-
-			try {
-				const prompt = await getSystemPrompt(invalidContext)
-				expect(prompt).to.be.a("string")
-			} catch (error) {
-				// Error is acceptable for invalid context
-				expect(error).to.be.instanceOf(Error)
-			}
+			const { systemPrompt } = await getSystemPrompt(invalidContext)
+			expect(systemPrompt).to.be.a("string")
 		})
 
 		it("should handle undefined context properties", async function () {

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/registry/PromptRegistry.ts

@@ -1,5 +1,5 @@
 import { ModelFamily } from "@/shared/prompts"
-import { ClineTool } from "@/shared/tools"
+import type { ClineTool } from "@/shared/tools"
 import { ClineToolSet } from ".."
 import { getSystemPromptComponents } from "../components"
 import { registerClineToolSets } from "../tools"
@@ -68,18 +68,21 @@ export class PromptRegistry {
 	}
 
 	getModelFamily(context: SystemPromptContext) {
-		// Loop through all registered variants to find the first one that matches
-		for (const [id, v] of this.variants.entries()) {
-			try {
-				if (v.matcher(context)) {
-					return v.family
+		// Ensure providerInfo and model ID are available
+		if (context.providerInfo?.model?.id) {
+			// Loop through all registered variants to find the first one that matches
+			for (const [_, v] of this.variants.entries()) {
+				try {
+					if (v.matcher(context)) {
+						return v.family
+					}
+				} catch {
+					// Continue to next variant if matcher throws
 				}
-			} catch (error) {
-				console.warn(`Matcher function error for variant '${id}':`, error)
-				// Continue to next variant if matcher throws
 			}
 		}
-
+		// Fallback to generic variant if no match found
+		console.log("No matching variant found, falling back to generic")
 		return ModelFamily.GENERIC
 	}
 	/**

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

@@ -225,6 +225,15 @@ export function toolSpecInputSchema(tool: ClineToolSpec, context: SystemPromptCo
 	return toolInputSchema
 }
 
+const GOOGLE_TOOL_PARAM_MAP: Record<string, string> = {
+	string: "STRING",
+	number: "NUMBER",
+	integer: "NUMBER",
+	boolean: "BOOLEAN",
+	object: "OBJECT",
+	array: "STRING",
+}
+
 /**
  * Converts a ClineToolSpec into a Google Gemini function.
  * Docs: https://ai.google.dev/gemini-api/docs/function-calling
@@ -246,21 +255,38 @@ export function toolSpecFunctionDeclarations(tool: ClineToolSpec, context: Syste
 				continue
 			}
 
+			if (!param.name) {
+				continue
+			}
+
 			// Add to required array if parameter is required
 			if (param.required) {
 				required.push(param.name)
 			}
 
-			// Determine parameter type - use explicit type if provided.
-			// Default to string
-			const paramType: string = param.type || GoogleToolParamType.STRING
-
-			// Build parameter schema
 			const paramSchema: any = {
-				type: paramType,
-				items: paramType === GoogleToolParamType.ARRAY ? { type: GoogleToolParamType.STRING } : undefined,
-				description: replacer(param.instruction, context),
+				type: GOOGLE_TOOL_PARAM_MAP[param.type || "string"] || GoogleToolParamType.OBJECT,
 			}
+
+			if (param.properties) {
+				paramSchema.properties = {}
+				for (const [key, prop] of Object.entries<any>(param.properties)) {
+					// Skip $schema property
+					if (key === "$schema") {
+						continue
+					}
+					paramSchema.properties[key] = {
+						type: GOOGLE_TOOL_PARAM_MAP[prop.type || "string"] || GoogleToolParamType.OBJECT,
+						description: replacer(param.instruction, context),
+					}
+
+					// Handle enum values
+					if (prop.enum) {
+						paramSchema.properties[key].enum = prop.enum
+					}
+				}
+			}
+
 			properties[param.name] = paramSchema
 		}
 	}

src/core/prompts/system-prompt/tools/apply_patch.ts

@@ -18,7 +18,7 @@ import { TASK_PROGRESS_PARAMETER } from "../types"
 //     },
 // }
 
-const APPLY_PATCH_TOOL_DESC = `This is a custom utility that makes it more convenient to add, remove, move, or edit code files. \`apply_patch\` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the \`apply_patch\` command, you should pass a message of the following structure as "input":
+const APPLY_PATCH_TOOL_DESC = `This is a custom utility that makes it more convenient to add, remove, move, or edit code in a single file. \`apply_patch\` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the \`apply_patch\` command, you should pass a message of the following structure as "input":
 
 %%bash
 apply_patch <<"EOF"
@@ -29,7 +29,7 @@ EOF
 
 Where [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format.
 
-*** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete.
+*** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete. 
 For each snippet of code that needs to be changed, repeat the following:
 [context_before] -> See below for further instructions on context.
 - [old_code] -> Precede the old code with a minus sign.

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/overrides.ts

@@ -1,7 +1,10 @@
 import { SystemPromptSection } from "../../templates/placeholders"
 import type { SystemPromptContext } from "../../types"
 
-const GLM_TOOL_USE_TEMPLATE = `Begin every task by exploring the codebase (e.g., list_files, search_files, read_file) and outlining the required changes. Do not implement until exploration yields enough context to state objectives, approach, affected files, and risks. Briefly summarize the plan, then proceed with implementation.
+const GLM_TOOL_USE_TEMPLATE = (context: SystemPromptContext) => {
+	const hasMcpServers = (context.mcpHub?.getServers() || []).length > 0
+
+	return `Begin every task by exploring the codebase (e.g., list_files, search_files, read_file) and outlining the required changes. Do not implement until exploration yields enough context to state objectives, approach, affected files, and risks. Briefly summarize the plan, then proceed with implementation.
 
 Tool invocation policy: Invoke tools only in assistant messages; they will not execute if placed inside reasoning blocks. Use reasoning blocks solely for analysis/option-weighing; place all tool XML blocks in assistant messages to execute them.
 
@@ -74,6 +77,40 @@ Params: path, recursive (optional).
 </list_files>
 Key: Rely on returned tool results instead of using list_files to “confirm” writes.
 
+${
+	hasMcpServers
+		? `
+**load_mcp_documentation** - Load documentation about creating MCP servers. This tool should be used when the user requests to create or install an MCP server.
+Parameters: None
+*Example:*
+<load_mcp_documentation>
+</load_mcp_documentation>
+
+
+**use_mcp_tool** - Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
+Parameters: server_name, tool_name, arguments
+*Example:*
+<use_mcp_tool>
+<server_name>server name here</server_name>
+<tool_name>tool name here</tool_name>
+<arguments>
+{
+  "param1": "value1",
+  "param2": "value2"
+}
+</arguments>
+</use_mcp_tool>
+
+**access_mcp_resource** - Request to access a resource provided by a connected MCP server. Resources represent data sources that can be used as context, such as files, API responses, or system information.
+Parameters: server_name, uri
+*Example:*
+<access_mcp_resource>
+<server_name>server name here</server_name>
+<uri>resource URI here</uri>
+</access_mcp_resource>`
+		: ""
+}
+
 **attempt_completion** — Final result (no questions). Use this tool only when all goals have been completed.
 Params: result, command (optional demonstration of completed work).  
 *Example:*
@@ -100,6 +137,7 @@ Include options/trade-offs when helpful, ask if plan matches, then add the exact
 <needs_more_exploration>true or false (optional, but you MUST set to true if in <response> you need to read files or use other exploration tools)</needs_more_exploration>
 <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>`
+}
 
 const GLM_OBJECTIVE_TEMPLATE = `OBJECTIVE
 

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}}}