v3.60.0 Release Notes

- Fixes for Minimax model family - Fixes for Response chaining for OpenAI's Responses API
2026-09-05 05:02:27 +08:00 · 2026-02-13 08:55:15 -08:00
301 changed files with 20061 additions and 14895 deletions
@@ -32,18 +32,3 @@ rm node_modules
 rm webview-ui/node_modules
 npm run install:all
 '''
-
-[[actions]]
-name = "pull main"
-icon = "tool"
-command = '''
-git fetch origin main                                                                                                                                                             
-                                                                                                                                                                                
-if ! git merge-base --is-ancestor main origin/main; then                                                                                                                          
-  echo "Local main has commits not on origin/main. Aborting..."                                                                                                                     
-  exit 1                                                                                                                                                                          
-fi
-
-git update-ref refs/heads/main refs/remotes/origin/main
-echo "main updated to $(git rev-parse --short main)"
-'''
@@ -1,70 +0,0 @@
-name: Smoke Tests
-
-on:
-  push:
-    branches: [main]
-    paths:
-      - 'src/core/**'
-      - 'src/shared/**'
-      - 'proto/**'
-      - 'evals/**'
-      - '.github/workflows/cline-evals-regression.yml'
-  pull_request:
-    paths:
-      - 'src/core/**'
-      - 'src/shared/**'
-      - 'proto/**'
-      - 'evals/**'
-      - '.github/workflows/cline-evals-regression.yml'
-  workflow_dispatch:
-
-permissions:
-  contents: read
-
-concurrency:
-  group: smoke-tests-${{ github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  smoke-tests:
-    name: Smoke Tests
-    runs-on: ubuntu-latest
-    timeout-minutes: 15
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '22'
-          cache: 'npm'
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Build and install CLI
-        run: |
-          npm run protos
-          cd cli && npm install && npm run build && npm link
-          echo "$(npm config get prefix)/bin" >> $GITHUB_PATH
-
-      - name: Verify CLI
-        run: cline --version
-
-      - name: Run smoke tests
-        env:
-          CLINE_API_KEY: ${{ secrets.CLINE_API_KEY }}
-        run: |
-          cline auth -p cline -k "$CLINE_API_KEY" -m "anthropic/claude-sonnet-4.5"
-          npx tsx evals/smoke-tests/run-smoke-tests.ts --trials 1 --parallel
-
-      - name: Generate summary
-        if: always()
-        run: cat evals/smoke-tests/results/latest/summary.md >> $GITHUB_STEP_SUMMARY
-
-      - name: Upload results
-        uses: actions/upload-artifact@v4
-        if: always()
-        with:
-          name: smoke-test-results-${{ github.run_id }}
-          path: evals/smoke-tests/results/latest/
-          retention-days: 30
@@ -48,6 +48,3 @@ test-results
 .secrets

 *.tsbuildinfo
-
-# Smoke test results (generated)
-evals/smoke-tests/results/
@@ -1,3 +0,0 @@
-[submodule "evals/cline-bench"]
-	path = evals/cline-bench
-	url = https://github.com/cline/cline-bench.git
@@ -1,25 +1,5 @@
 # Changelog

-## [3.63.0]
-
-### Added
-
- added zai GLM 5 Free promo
-
-### Fixed
-
- Restore reasoning trace visibility in chat and improve the thinking row UX so reasoning is visible, then collapsible after completion.
-
-## [3.62.0]
-
-### Fixed
- Banners now display immediately when opening the extension instead of requiring user interaction first
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)
-
-## [3.61.0]
-
- UI/UX fixes with minimax model family
-
 ## [3.60.0]

 - Fixes for Minimax model family
@@ -1,18 +1,8 @@
 # cline

-## 2.2.3
-
-### Patch Changes
-
- c0020e1: Allows users to enter custom aws region when selecting bedrock as a provider in CLI
-
-### Fixed
-
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)
-
 ## [2.2.2]

- Allows users to enter custom aws region when selecting bedrock as a provider
+-  Allows users to enter custom aws region when selecting bedrock as a provider
 - Prevent Parent Container Scrolling In Dropdowns

 ## [2.2.1]
@@ -45,7 +45,7 @@ cline

 ### Use any API and Model

-Cline supports API providers like ChatGPT, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras, Groq, and Moonshot. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using a Cline Account, you'll always have access to the newest models as soon as they're available.
+Cline supports API providers like ChatGPT, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras and Groq. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using a Cline Account, you'll always have access to the newest models as soon as they're available.

 <!-- Transparent pixel to create line break after floating image -->

@@ -79,3 +79,4 @@ Get the same Cline experience with enterprise-grade controls: SSO (SAML/OIDC), g
 ## License

 [Apache 2.0 © 2026 Cline Bot Inc.](./LICENSE)
+
@@ -125,13 +125,13 @@ authentication wizard, or use quick setup flags.
 Options:
 .PP
 \f[B]\-p\f[R], \f[B]\-\-provider\f[R] \f[I]id\f[R] : Provider ID for
-quick setup (e.g., openai\-native, anthropic, openrouter, moonshot)
+quick setup (e.g., openai\-native, anthropic, openrouter)
 .PP
 \f[B]\-k\f[R], \f[B]\-\-apikey\f[R] \f[I]key\f[R] : API key for the
 provider
 .PP
 \f[B]\-m\f[R], \f[B]\-\-modelid\f[R] \f[I]id\f[R] : Model ID to
-configure (e.g., gpt\-4o, claude\-sonnet\-4\-5\-20250929, kimi\-k2.5)
+configure (e.g., gpt\-4o, claude\-sonnet\-4\-5\-20250929)
 .PP
 \f[B]\-b\f[R], \f[B]\-\-baseurl\f[R] \f[I]url\f[R] : Base URL (optional,
 for OpenAI\-compatible providers)
@@ -242,9 +242,6 @@ cline \-m claude\-sonnet\-4\-5\-20250929 \(dqRefactor this function\(dq

 \f[I]# Quick auth setup with model\f[R]
 cline auth \-p anthropic \-k sk\-ant\-xxxxx \-m claude\-sonnet\-4\-5\-20250929
-
-\f[I]# Quick auth setup for Moonshot\f[R]
-cline auth \-p moonshot \-k sk\-xxxxx \-m kimi\-k2.5
 .EE
 .SS Including Images
 .IP
@@ -312,9 +309,6 @@ cline auth \-p anthropic \-k sk\-ant\-api\-xxxxx
 \f[I]# Quick setup for OpenAI\f[R]
 cline auth \-p openai\-native \-k sk\-xxxxx \-m gpt\-4o

-\f[I]# Quick setup for Moonshot\f[R]
-cline auth \-p moonshot \-k sk\-xxxxx \-m kimi\-k2.5
-
 \f[I]# OpenAI\-compatible provider with custom base URL\f[R]
 cline auth \-p openai \-k your\-api\-key \-b https://api.example.com/v1
 .EE
@@ -1,6 +1,6 @@
 {
 	"name": "cline",
-	"version": "2.2.3",
+	"version": "2.2.2",
 	"description": "Autonomous coding agent CLI - capable of creating/editing files, running commands, using the browser, and more",
 	"main": "dist/cli.mjs",
 	"bin": {
@@ -28,8 +28,6 @@ import {
 	groqModels,
 	mistralDefaultModelId,
 	mistralModels,
-	moonshotDefaultModelId,
-	moonshotModels,
 	openAiCodexDefaultModelId,
 	openAiNativeDefaultModelId,
 	openAiNativeModels,
@@ -74,7 +72,6 @@ const providerModels: Record<string, { models: Record<string, unknown>; defaultI
 	bedrock: { models: bedrockModels, defaultId: bedrockDefaultModelId },
 	deepseek: { models: deepSeekModels, defaultId: deepSeekDefaultModelId },
 	mistral: { models: mistralModels, defaultId: mistralDefaultModelId },
-	moonshot: { models: moonshotModels, defaultId: moonshotDefaultModelId },
 	groq: { models: groqModels, defaultId: groqDefaultModelId },
 	xai: { models: xaiModels, defaultId: xaiDefaultModelId },
 }
@@ -114,11 +114,8 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete

 	// Filtered regions
 	const filteredRegions = useMemo(() => {
-		const search = regionSearch.toLowerCase().trim()
-		if (!search) {
-			return AWS_REGIONS
-		}
-		return AWS_REGIONS.filter((r) => r.toLowerCase().includes(search))
+		const search = regionSearch.toLowerCase()
+		return search ? AWS_REGIONS.filter((r) => r.includes(search)) : AWS_REGIONS
 	}, [regionSearch])

 	const {
@@ -173,18 +170,10 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
 		}
 	}, [step, authMethod, onCancel])

-	const getSelectedRegion = useCallback(() => {
-		if (filteredRegions.length > 0 && regionIndex >= 0 && regionIndex < filteredRegions.length) {
-			return filteredRegions[regionIndex]
-		}
-		// If no matches, use the search term as custom region
-		return regionSearch.trim() || "us-east-1"
-	}, [filteredRegions, regionIndex, regionSearch])
-
 	const finish = useCallback(() => {
 		const config: BedrockConfig = {
 			awsAuthentication: authMethod === "default" ? "credentials" : authMethod,
-			awsRegion: getSelectedRegion(),
+			awsRegion: filteredRegions[regionIndex] || "us-east-1",
 			awsUseCrossRegionInference: crossRegion,
 		}
 		if (authMethod === "profile") {
@@ -195,7 +184,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
 			if (sessionToken) config.awsSessionToken = sessionToken
 		}
 		onComplete(config)
-	}, [authMethod, profileName, accessKey, secretKey, sessionToken, getSelectedRegion, crossRegion, onComplete])
+	}, [authMethod, profileName, accessKey, secretKey, sessionToken, filteredRegions, regionIndex, crossRegion, onComplete])

 	// Handle input for auth_method, region, and options steps
 	useInput(
@@ -215,11 +204,11 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
 			} else if (step === "region") {
 				if (key.escape) {
 					goBack()
-				} else if (key.upArrow && filteredRegions.length > 0) {
+				} else if (key.upArrow) {
 					setRegionIndex((prev) => (prev > 0 ? prev - 1 : filteredRegions.length - 1))
-				} else if (key.downArrow && filteredRegions.length > 0) {
+				} else if (key.downArrow) {
 					setRegionIndex((prev) => (prev < filteredRegions.length - 1 ? prev + 1 : 0))
-				} else if (key.return && (filteredRegions.length > 0 || regionSearch.trim())) {
+				} else if (key.return && filteredRegions.length > 0) {
 					setStep("options")
 				} else if (key.backspace || key.delete) {
 					setRegionSearch((prev) => prev.slice(0, -1))
@@ -341,7 +330,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
 				<Text color="white">AWS Region</Text>
 				<Text> </Text>
 				<Box>
-					<Text color="gray">Search or enter custom region: </Text>
+					<Text color="gray">Search: </Text>
 					<Text color="white">{regionSearch}</Text>
 					<Text inverse> </Text>
 				</Box>
@@ -361,6 +350,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
 				{showRegionBottom && (
 					<Text color="gray">... {filteredRegions.length - regionVisibleStart - regionVisibleCount} more below</Text>
 				)}
+				{filteredRegions.length === 0 && <Text color="gray">No regions match "{regionSearch}"</Text>}
 				<Text> </Text>
 				<Text color="gray">Type to search, arrows to navigate, Enter to select, Esc to go back</Text>
 			</Box>
@@ -1,12 +0,0 @@
-import { describe, expect, it } from "vitest"
-import { getAllFeaturedModels } from "./featured-models"
-
-describe("featured models", () => {
-	it("includes display names for all featured models", () => {
-		const models = getAllFeaturedModels()
-
-		for (const model of models) {
-			expect(model.name).toBeTruthy()
-		}
-	})
-})
@@ -10,7 +10,7 @@ export interface FeaturedModel {
 	labels: string[]
 }

-export const FEATURED_MODELS: { recommended: FeaturedModel[]; free: FeaturedModel[] } = {
+export const FEATURED_MODELS = {
 	recommended: [
 		{
 			id: "anthropic/claude-opus-4.6",
@@ -30,33 +30,24 @@ export const FEATURED_MODELS: { recommended: FeaturedModel[]; free: FeaturedMode
 			description: "1M context window for large codebases",
 			labels: ["TRENDING"],
 		},
-	],
+	] as FeaturedModel[],
 	free: [
 		{
 			id: "minimax/minimax-m2.5",
-			name: "MiniMax M2.5",
 			description: "MiniMax-M2.5 is a lightweight, state-of-the-art LLM optimized for coding and agentic workflows",
 			labels: ["FREE"],
 		},
-		{
-			id: "z-ai/glm-5",
-			name: "Z-AI GLM5",
-			description: "Z.AI's latest GLM 5 model with strong coding and agent performance",
-			labels: ["FREE"],
-		},
 		{
 			id: "kwaipilot/kat-coder-pro",
-			name: "KAT Coder Pro",
 			description: "KwaiKAT's most advanced agentic coding model in the KAT-Coder series",
 			labels: ["FREE"],
 		},
 		{
 			id: "arcee-ai/trinity-large-preview:free",
-			name: "Trinity Large Preview",
 			description: "Arcee AI's advanced large preview model in the Trinity series",
 			labels: ["FREE"],
 		},
-	],
+	] as FeaturedModel[],
 }

 export function getAllFeaturedModels(): FeaturedModel[] {
@@ -790,9 +790,9 @@ program
 program
 	.command("auth")
 	.description("Authenticate a provider and configure what model is used")
-	.option("-p, --provider <id>", "Provider ID for quick setup (e.g., openai-native, anthropic, moonshot)")
+	.option("-p, --provider <id>", "Provider ID for quick setup (e.g., openai-native, anthropic)")
 	.option("-k, --apikey <key>", "API key for the provider")
-	.option("-m, --modelid <id>", "Model ID to configure (e.g., gpt-4o, claude-sonnet-4-5-20250929, kimi-k2.5)")
+	.option("-m, --modelid <id>", "Model ID to configure (e.g., gpt-4o, claude-sonnet-4-5-20250929)")
 	.option("-b, --baseurl <url>", "Base URL (optional, only for openai provider)")
 	.option("-v, --verbose", "Show verbose output")
 	.option("-c, --cwd <path>", "Working directory for the task")
@@ -202,15 +202,15 @@ If Cline can't access files or run commands:
    Learn about Cline CLI's core capabilities and use cases.
  </Card>
  
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
+    Master interactive mode, headless automation, and multi-instance workflows.
  </Card>
  
-  <Card title="Skills" icon="graduation-cap" href="/customization/skills">
+  <Card title="Skills" icon="graduation-cap" href="/features/skills">
    Understand how Cline's Skills work across all editors via ACP.
  </Card>
  
-  <Card title="Hooks" icon="link" href="/customization/hooks">
+  <Card title="Hooks" icon="link" href="/features/hooks/index">
    Learn how to enforce policies with Hooks in any editor.
  </Card>
 </Columns>
@@ -0,0 +1,482 @@
+---
+title: "CLI Reference (Deprecated)"
+description: "Command reference for Cline CLI versions earlier than 2.0.0 (deprecated). For the latest commands and options, see the current Cline CLI reference."
+---
+
+Complete command reference for Cline CLI. Use this for detailed documentation on all commands, options, and configuration.
+
+For quick help in your terminal:
+
+```bash
+cline --help          # Show all commands
+cline task --help     # Show task-specific commands
+man cline            # View the full manual page
+```
+
+## Manual Page
+
+The complete manual page for the Cline CLI:
+
+```
+CLINE(1)                         User Commands                        CLINE(1)
+
+NAME
+       cline - orchestrate and interact with Cline AI coding agents
+
+SYNOPSIS
+       cline [prompt] [options]
+
+       cline command [subcommand] [options] [arguments]
+
+DESCRIPTION
+       Try: cat README.md | cline "Summarize this for me:"
+
+       cline is a command-line interface for orchestrating multiple Cline AI
+       coding agents.  Cline is an autonomous AI agent who can read, write,
+       and execute code across your projects.  He operates through a
+       client-server architecture where Cline Core runs as a standalone
+       service, and the CLI acts as a scriptable interface for managing tasks,
+       instances, and agent interactions.
+
+       The CLI is designed for both interactive use and automation, making it
+       ideal for CI/CD pipelines, parallel task execution, and terminal-based
+       workflows.  Multiple frontends (CLI, VSCode, JetBrains) can attach to
+       the same Cline Core instance, enabling seamless task handoff between
+       environments.
+
+MODES OF OPERATION
+       Instant Task Mode
+              The simplest invocation: cline "prompt here" immediately spawns
+              an instance, creates a task, and enters chat mode.  This is
+              equivalent to running cline instance new && cline task new &&
+              cline task chat in sequence.
+
+       Subcommand Mode
+              Advanced usage with explicit control: cline <command>
+              [subcommand] [options] provides fine-grained control over
+              instances, tasks, authentication, and configuration.
+
+AGENT BEHAVIOR
+       Cline operates in two primary modes:
+
+       ACT MODE
+              Cline actively uses tools to accomplish tasks.  He can read
+              files, write code, execute commands, use a headless browser, and
+              more.  This is the default mode for task execution.
+
+       PLAN MODE
+              Cline gathers information and creates a detailed plan before
+              implementation.  He explores the codebase, asks clarifying
+              questions, and presents a strategy for user approval before
+              switching to ACT MODE.
+
+INSTANT TASK OPTIONS
+       When using the instant task syntax cline "prompt" the following options
+       are available:
+
+       -o, --oneshot
+              Full autonomous mode.  Cline completes the task and stops
+              following after completion.  Example: cline -o "what's 6 + 8?"
+
+       -s, --setting setting value
+              Override a setting for this task
+
+       -y, --no-interactive, --yolo
+              Enable fully autonomous mode.  Disables all interactivity:
+
+              • ask_followup_question tool is disabled
+
+              • attempt_completion happens automatically
+
+              • execute_command runs in non-blocking mode with timeout
+
+              • PLAN MODE automatically switches to ACT MODE
+
+       -m, --mode mode
+              Starting mode.  Options: act (default), plan
+
+       -w, --workspace path
+              Additional workspace paths.  Can be specified multiple times to
+              include multiple directories.  The current working directory is
+              always included as the first workspace.  Example: cline -w
+              /path/to/other/project "refactor shared code"
+
+GLOBAL OPTIONS
+       These options apply to all subcommands:
+
+       -F, --output-format format
+              Output format.  Options: rich (default), json, plain
+
+       -h, --help
+              Display help information for the command.
+
+       -v, --verbose
+              Enable verbose output for debugging.
+
+COMMANDS
+   Authentication
+       cline auth [provider] [key]
+
+       cline a [provider] [key]
+              Configure authentication for AI model providers.  Launches an
+              interactive wizard if no arguments provided.  If provider is
+              specified without a key, prompts for the key or launches the
+              appropriate OAuth flow.
+
+   Instance Management
+       Cline Core instances are independent agent processes that can run in
+       the background.  Multiple instances can run simultaneously, enabling
+       parallel task execution.
+
+       cline instance
+
+       cline i
+              Display instance management help.
+
+       cline instance new [-d|--default]
+
+       cline i n [-d|--default]
+              Spawn a new Cline Core instance.  Use --default to set it as
+              the default instance for subsequent commands.
+
+       cline instance list
+
+       cline i l
+              List all running Cline Core instances with their addresses and
+              status.
+
+       cline instance default address
+
+       cline i d address
+              Set the default instance to avoid specifying --address in task
+              commands.
+
+       cline instance kill address [-a|--all]
+
+       cline i k address [-a|--all]
+              Terminate a Cline Core instance.  Use --all to kill all running
+              instances.
+
+   Task Management
+       Tasks represent individual work items that Cline executes.  Tasks
+       maintain conversation history, checkpoints, and settings.
+
+       cline task [-a|--address ADDR]
+
+       cline t [-a|--address ADDR]
+              Display task management help.  The --address flag specifies
+              which Cline Core instance to use (e.g., localhost:50052).
+
+       cline task new prompt [options]
+
+       cline t n prompt [options]
+              Create a new task in the default or specified instance.
+              Options:
+
+              -s, --setting setting value
+                     Set task-specific settings
+
+              -y, --no-interactive, --yolo
+                     Enable autonomous mode
+
+              -m, --mode mode
+                     Starting mode (act or plan)
+
+       cline task open task-id [options]
+
+       cline t o task-id [options]
+              Resume a previous task from history.  Accepts the same options
+              as task new.
+
+       cline task list
+
+       cline t l
+              List all tasks in history with their id and snippet
+
+       cline task chat
+
+       cline t c
+              Enter interactive chat mode for the current task.  Allows
+              back-and-forth conversation with Cline.
+
+       cline task send [message] [options]
+
+       cline t s [message] [options]
+              Send a message to Cline.  If no message is provided, reads from
+              stdin.  Options:
+
+              -a, --approve
+                     Approve Cline's proposed action
+
+              -d, --deny
+                     Deny Cline's proposed action
+
+              -f, --file FILE
+                     Attach a file to the message
+
+              -y, --no-interactive, --yolo
+                     Enable autonomous mode
+
+              -m, --mode mode
+                     Switch mode (act or plan)
+
+       cline task view [-f|--follow] [-c|--follow-complete]
+
+       cline t v [-f|--follow] [-c|--follow-complete]
+              Display the current conversation.  Use --follow to stream
+              updates in real-time, or --follow-complete to follow until task
+              completion.
+
+       cline task restore checkpoint
+
+       cline t r checkpoint
+              Restore the task to a previous checkpoint state.
+
+       cline task pause
+
+       cline t p
+              Pause task execution.
+
+   Configuration
+       Configuration can be set globally.  Override these global settings for
+       a task using the --setting flag
+
+       cline config
+
+       cline c
+
+       cline config set key value
+
+       cline c s key value
+              Set a configuration variable.
+
+       cline config get key
+
+       cline c g key
+              Read a configuration variable.
+
+       cline config list
+
+       cline c l
+              List all configuration variables and their values.
+
+   Context Window Configuration
+       For local model providers, you can configure the context window size:
+
+       Ollama
+              cline config s ollama-api-options-ctx-num=32768
+
+       LM Studio
+              cline config s lm-studio-max-tokens=32768
+
+       For other providers (Anthropic, OpenRouter, etc.), the context window
+       is defined per model in the model metadata and is not user-settable.
+       Cline uses each model's built-in context limits automatically.
+
+TASK SETTINGS
+       Task settings are persisted in the ~/.cline/x/tasks directory.  When
+       resuming a task with cline task open, task settings are automatically
+       restored.
+
+       Common settings include:
+
+       yolo   Enable autonomous mode (true/false)
+
+       mode   Starting mode (act/plan)
+
+       hooks_enabled
+              Enable or disable hooks for the task (true/false)
+
+HOOKS INTEGRATION
+       Hooks let you inject custom logic into Cline's workflow at key moments.
+       They can validate operations before they execute, monitor tool usage,
+       and shape AI decisions. This allows you to integrate hooks into
+       automated workflows, CI/CD pipelines, and headless task execution.
+
+       Enable hooks for a task:
+
+              cline "prompt" -s hooks_enabled=true
+
+       Configure hooks globally:
+
+              cline config set hooks-enabled=true
+              cline config get hooks-enabled
+
+       Note: Hooks in the CLI are only supported on macOS and Linux.
+
+       For complete hooks documentation, see:
+       <https://docs.cline.bot/features/hooks/index>
+
+NOTES & EXAMPLES
+       The cline task send and cline task new commands support reading from
+       stdin, enabling powerful pipeline compositions:
+
+              cat requirements.txt | cline task send
+              echo "Refactor this code" | cline -y
+
+   Instance Management
+       Manage multiple Cline instances:
+
+              # Start a new instance and make it default
+              cline instance new --default
+
+              # List all running instances
+              cline instance list
+
+              # Kill a specific instance
+              cline instance kill localhost:50052
+
+              # Kill all CLI instances
+              cline instance kill --all-cli
+
+   Task History
+       Work with task history:
+
+              # List previous tasks
+              cline task list
+
+              # Resume a previous task
+              cline task open 1760501486669
+
+              # View conversation history
+              cline task view
+
+              # Start interactive chat with this task
+              cline task chat
+
+ARCHITECTURE
+       Cline operates on a three-layer architecture:
+
+       Presentation Layer
+              User interfaces (CLI, VSCode, JetBrains) that connect to Cline
+              Core via gRPC
+
+       Cline Core
+              The autonomous agent service handling task management, AI model
+              integration, state management, tool orchestration, and real-time
+              streaming updates
+
+       Host Provider Layer
+              Environment-specific integrations (VSCode APIs, JetBrains APIs,
+              shell APIs) that Cline Core uses to interact with the host
+              system
+
+BUGS
+       Report bugs at: <https://github.com/cline/cline/issues>
+
+       For real-time help, join the Discord community at:
+       <https://discord.gg/cline>
+
+SEE ALSO
+       Full documentation: <https://docs.cline.bot>
+
+AUTHORS
+       Cline is developed by the Cline Bot Inc. and the open source community.
+
+COPYRIGHT
+       Copyright © 2025 Cline Bot Inc. Licensed under the Apache License 2.0.
+```
+
+## JSON output (-F json)
+
+When you run a command with `-F json` (or `--output-format json`), Cline prints each client message as JSON.
+
+### ClineMessage schema
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `type` | `"ask" or "say"` | Yes | Top-level message category. |
+| `text` | `string` | Yes | Human-readable message content. |
+| `ts` | `number` | Yes | Unix epoch timestamp in milliseconds. |
+| `reasoning` | `string` | No | Omitted when empty. |
+| `say` | `string` | No | Omitted when empty. Present when `type` is `"say"`. |
+| `ask` | `string` | No | Omitted when empty. Present when `type` is `"ask"`. |
+| `partial` | `boolean` | No | Omitted when false. `true` for streaming updates. |
+| `images` | `string[]` | No | Omitted when empty. Image URIs when included with a message. |
+| `files` | `string[]` | No | Omitted when empty. File paths when attached to a message. |
+| `lastCheckpointHash` | `string` | No | Omitted when empty. Git checkpoint hash when available. |
+| `isCheckpointCheckedOut` | `boolean` | No | Omitted when false. `true` if Cline checked out a checkpoint. |
+| `isOperationOutsideWorkspace` | `boolean` | No | Omitted when false. `true` if an operation happened outside the workspace. |
+
+<Note>
+Most fields are optional and omitted when empty. If you parse this output, treat missing fields as “not present”, not as empty strings.
+</Note>
+
+### Example
+
+```json
+{
+  "type": "say",
+  "text": "Cline is about to run a command.",
+  "ts": 1760501486669,
+  "say": "command",
+  "partial": false
+}
+```
+
+### Shell Completion
+
+Generate autocompletion scripts for various shells:
+
+#### Bash
+
+```bash
+# Generate bash completion
+cline completion bash > /etc/bash_completion.d/cline
+
+# Or for user-level installation
+cline completion bash > ~/.local/share/bash-completion/completions/cline
+```
+
+#### Zsh
+
+```bash
+# Generate zsh completion
+cline completion zsh > "${fpath[1]}/_cline"
+
+# Or add to your .zshrc
+echo 'source <(cline completion zsh)' >> ~/.zshrc
+```
+
+#### Fish
+
+```bash
+# Generate fish completion
+cline completion fish > ~/.config/fish/completions/cline.fish
+```
+
+#### PowerShell
+
+```powershell
+# Generate PowerShell completion
+cline completion powershell > cline.ps1
+
+# Add to your PowerShell profile
+Add-Content $PROFILE "cline completion powershell | Out-String | Invoke-Expression"
+```
+
+### Version Command
+
+```bash
+# Show version information
+cline version
+```
+
+### Environment Variables
+
+#### CLINE_DIR
+
+Override the default Cline directory location:
+
+```bash
+# Override default Cline directory
+export CLINE_DIR=/custom/path
+
+# Default: ~/.cline
+```
+
+This directory is used for:
+- Instance registry database
+- Configuration files
+- Task history
+- Checkpoints
@@ -3,6 +3,8 @@ title: "CLI Reference"
 description: "Complete command reference for Cline CLI including all commands, flags, and configuration options"
 ---

+# CLI Reference
+
 This page documents all available commands, flags, and configuration options for Cline CLI. For quick help in your terminal, use:

 ```bash
@@ -314,7 +316,7 @@ When using `--json`, each message is output as a JSON object (one per line):

 Cline stores all data in `~/.cline/` by default:

-```text
+```
 ~/.cline/
 ├── data/                    # Configuration directory
 │   ├── globalState.json     # Global settings
@@ -414,8 +416,8 @@ cline auth -p openai -k your-key -b https://api.example.com/v1
    Keyboard shortcuts, slash commands, and file mentions.
  </Card>
  
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
+    Interactive mode, direct execution, and automation patterns.
  </Card>
  
  <Card title="Configuration" icon="gear" href="/cline-cli/configuration">
@@ -38,7 +38,7 @@ Rules help Cline understand your project's conventions, coding standards, and pr

 ### Workflows Tab

-View and manage [workflows](/customization/workflows):
+View and manage [workflows](/features/slash-commands/workflows/index):

 - List available workflows
 - View workflow definitions
@@ -46,7 +46,7 @@ View and manage [workflows](/customization/workflows):

 ### Hooks Tab

-Configure [hooks](/customization/hooks) for custom logic integration:
+Configure [hooks](/features/hooks/index) for custom logic integration:

 - Enable/disable hooks globally
 - View configured hook scripts
@@ -58,7 +58,7 @@ Hooks must be enabled via settings. Use `cline config` to toggle `hooks-enabled`

 ### Skills Tab

-Manage [skills](/customization/skills) that extend Cline's capabilities:
+Manage [skills](/features/skills) that extend Cline's capabilities:

 - View available skills
 - Enable/disable specific skills
@@ -68,7 +68,7 @@ Manage [skills](/customization/skills) that extend Cline's capabilities:

 Cline stores configuration in `~/.cline/data/`:

-```text
+```
 ~/.cline/
 ├── data/                    # Configuration directory
 │   ├── globalState.json     # Global settings
@@ -268,8 +268,8 @@ cline auth  # Re-authenticate
 ## Next Steps

 <Columns cols={2}>
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
+    Learn about interactive mode, direct execution, and automation patterns.
  </Card>
  
  <Card title="CLI Reference" icon="terminal" href="/cline-cli/cli-reference">
@@ -1,457 +0,0 @@
---
-title: "Getting Started"
-description: "Run Cline AI coding agents directly in your terminal with an interactive CLI or automated workflows"
---
-
-## What is Cline CLI?
-
-Cline CLI brings the full power of Cline to your terminal. Whether you prefer an interactive experience or automated workflows for CI/CD pipelines, the CLI adapts to your needs.
-
-The CLI supports macOS, Linux, and Windows, and works with all the same AI providers as the VS Code extension.
-
-## Two Ways to Use Cline CLI
-
-The CLI operates in two distinct modes, automatically selecting the appropriate one based on how you invoke it:
-
-### Interactive Mode
-
-Interactive mode is designed for **hands-on development sessions** where you want to collaborate with Cline in real-time. It provides a rich terminal interface that feels like chatting with an AI assistant.
-
-**When it activates:** Running `cline` without arguments, or when stdin is a TTY (terminal).
-
-```bash
-cline
-```
-
-Key features:
-
- **Real-time conversation** - Type messages, see Cline's responses, and iterate on tasks
- **Visual feedback** - Animated welcome screen, syntax-highlighted code, and progress indicators
- **File mentions** with `@` - Reference workspace files with fuzzy search autocomplete
- **Slash commands** with `/` - Quick access to `/settings`, `/history`, `/models`, and workflows
- **Keyboard shortcuts** - `Tab` to toggle Plan/Act, `Shift+Tab` for auto-approve all
- **Session summaries** - See tasks completed, files modified, and token usage on exit
- **Settings panel** - Configure providers, models, and features without leaving the CLI
-
-Interactive mode keeps you in control. You review Cline's plan, approve or modify actions, and guide the conversation.
-
-[Learn more about interactive mode →](/cline-cli/interactive-mode)
-
-### Headless Mode (Non-Interactive)
-
-Headless mode is designed for **automation, scripting, and CI/CD pipelines** where human interaction isn't possible or desired.
-
-**When it activates:** Using the `-y`/`--yolo` flag, `--json` flag, piping input/output, or when stdin is not a TTY.
-
-```bash
-# Headless with auto-approval (YOLO mode)
-cline -y "Run tests and fix any failures"
-
-# Headless with JSON output for parsing
-cline --json "List all TODO comments" | jq '.text'
-
-# Headless via piped input
-cat README.md | cline "Summarize this document"
-
-# Chain multiple headless commands
-git diff | cline -y "explain these changes" | cline -y "write a commit message"
-```
-
-Key features:
-
- **No visual interface** - Clean text or JSON output suitable for scripting
- **Automatic execution** - With `-y`, Cline approves all actions and runs autonomously
- **Process control** - Exits automatically when the task completes
- **Piped workflows** - Read from stdin, write to stdout, chain with other commands
- **Machine-readable output** - Use `--json` to get structured output for parsing
-
-<Warning>
-Headless mode with `-y` gives Cline full autonomy. Run on a clean git branch so you can easily revert changes if needed.
-</Warning>
-
-### Mode Detection Summary
-
-Cline automatically detects which mode to use based on your invocation. This table shows how different command patterns trigger each mode, helping you predict behavior in scripts and interactive sessions.
-
-| Invocation | Mode | Reason |
-|------------|------|--------|
-| `cline` | Interactive | No arguments, TTY connected |
-| `cline "task"` | Interactive | TTY connected |
-| `cline -y "task"` | Headless | YOLO flag forces headless |
-| `cline --json "task"` | Headless | JSON flag forces headless |
-| `cat file \| cline "task"` | Headless | stdin is piped |
-| `cline "task" > output.txt` | Headless | stdout is redirected |
-
-[Learn more about headless mode →](/cline-cli/three-core-flows)
-
-## Supported Model Providers
-
-Cline CLI supports all providers available in the VS Code extension:
-
- **Anthropic** (Claude)
- **OpenAI** (GPT-4o, GPT-4)
- **OpenAI Codex** (ChatGPT subscription)
- **OpenRouter**
- **AWS Bedrock**
- **Google Gemini**
- **X AI (Grok)**
- **Cerebras**
- **DeepSeek**
- **Ollama** (local models)
- **LM Studio** (local models)
- **OpenAI Compatible** (any compatible API)
-
-During setup, authenticate with `cline auth` to configure your preferred provider. [See authentication →](#authenticate)
-
-## What You Can Build
-
-### Automated Code Maintenance
-
-Keep your codebase healthy with automated fixes. Cline scans for issues and applies corrections across multiple files.
-
-```bash
-cline -y "Fix all ESLint errors in src/"
-```
-Finds and fixes linting violations throughout your source directory.
-
-```bash
-cline -y "Update all deprecated React lifecycle methods"
-```
-Migrates legacy code patterns to modern equivalents (e.g., `componentWillMount` → `useEffect`).
-
-```bash
-cline -y "Update dependencies with known vulnerabilities"
-```
-Identifies outdated packages with security issues and updates them to safe versions.
-
-### CI/CD Integration
-
-Integrate Cline into your continuous integration pipelines for automated code review and documentation.
-
-```bash
-git diff origin/main | cline -y "Review these changes for issues"
-```
-Pipes your PR diff to Cline for automated code review, catching bugs and style issues before merge.
-
-```bash
-git log --oneline v1.0..v1.1 | cline -y "Write release notes"
-```
-Generates human-readable release notes from your commit history between two tags.
-
-```bash
-cline -y "Run tests and fix failures" --timeout 600
-```
-Executes your test suite, analyzes failures, and attempts fixes with a 10-minute timeout.
-
-### Development Workflows
-
-From quick edits to complex refactors, Cline adapts to your workflow.
-
-```bash
-cline
-```
-Launches interactive mode for exploratory development and back-and-forth collaboration.
-
-```bash
-cline "Refactor this function to use async/await"
-```
-Executes a focused task directly from the command line with approval prompts at key steps.
-
-```bash
-cline "Based on @src/api.ts, add error handling to all endpoints"
-```
-Uses file mentions (`@`) to give Cline context about specific files in your workspace.
-
-### Custom Shell Pipelines
-
-Chain Cline with other CLI tools to build powerful automation workflows.
-
-```bash
-gh pr diff 123 | cline -y "Review this PR"
-```
-Fetches a GitHub PR diff and pipes it directly to Cline for review.
-
-```bash
-cline --json "List all TODO comments" | jq '.text'
-```
-Outputs structured JSON that you can process with tools like `jq` for scripting.
-
-```bash
-git diff | cline -y "explain" | cline -y "write a haiku about these changes"
-```
-Chains multiple Cline invocations together for creative multi-step workflows.
-
-## Features at a Glance
-
-| Feature | Interactive Mode | Non-Interactive Mode |
-|---------|------------------|----------------------|
-| Interactive chat | ✓ | - |
-| File mentions (@) | ✓ | ✓ (inline) |
-| Slash commands (/) | ✓ | - |
-| Settings panel | ✓ | `cline config` |
-| Plan/Act toggle | ✓ (Tab) | `-p` / `-a` flags |
-| Auto-approve | ✓ (Shift+Tab) | `-y` flag |
-| Session summary | ✓ | - |
-| JSON output | - | `--json` |
-| Piped input | - | ✓ |
-
---
-
-## Installation & Setup
-
-In just a few minutes, you can install the CLI, authenticate with your preferred AI provider, and start running tasks from any directory on your machine.
-
-### Prerequisites
-
-Cline CLI requires **Node.js version 20 or higher**. We recommend Node.js 22 for the best experience.
-
-Check your Node.js version:
-
-```bash
-node --version
-```
-
-If you need to install or update Node.js, visit [nodejs.org](https://nodejs.org) or use a version manager like [nvm](https://github.com/nvm-sh/nvm).
-
-### Install Cline CLI
-
-Install globally via npm:
-
-```bash
-npm install -g cline
-```
-
-Verify the installation:
-
-```bash
-cline version
-```
-
-<Tip>
-To install a specific version, use `npm install -g cline@2.0.0`. Check [npm](https://www.npmjs.com/package/cline) for available versions.
-</Tip>
-
-### Authenticate
-
-After installation, run the authentication wizard:
-
-```bash
-cline auth
-```
-
-This launches an interactive wizard with multiple options. Choose the method that works best for your workflow.
-
-#### Option 1: Sign in with Cline (Recommended)
-
-Select **"Sign in with Cline"** to authenticate with your Cline account via OAuth. Your browser opens automatically to complete sign-in.
-
-#### Option 2: Sign in with ChatGPT Subscription
-
-If you have a ChatGPT Plus or Pro subscription, select **"Sign in with ChatGPT Subscription"**. This uses OpenAI's Codex OAuth to authenticate with your existing subscription.
-
-#### Option 3: Import from Existing Tools
-
-Already using another AI coding CLI? Cline can import your existing configuration:
-
- **Import from Codex CLI** - Imports credentials from `~/.codex/auth.json`
- **Import from OpenCode** - Imports configuration from `~/.local/share/opencode/auth.json`
-
-#### Option 4: Bring Your Own API Key
-
-Select **"Bring your own API key"** to manually configure any supported provider. Or skip the wizard entirely with flags:
-
-```bash
-# Anthropic (Claude)
-cline auth -p anthropic -k sk-ant-api-xxxxx -m claude-sonnet-4-5-20250929
-
-# OpenAI
-cline auth -p openai-native -k sk-xxxxx -m gpt-4o
-
-# OpenRouter
-cline auth -p openrouter -k sk-or-xxxxx -m anthropic/claude-sonnet-4-5-20250929
-
-# OpenAI-compatible provider with custom base URL
-cline auth -p openai -k your-api-key -b https://api.example.com/v1
-```
-
-**Quick Setup Flags:**
-
-| Flag | Description |
-|------|-------------|
-| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`) |
-| `-k, --apikey <key>` | Your API key |
-| `-m, --modelid <id>` | Model ID (e.g., `claude-sonnet-4-5-20250929`, `gpt-4o`) |
-| `-b, --baseurl <url>` | Base URL for OpenAI-compatible providers |
-
-<Tip>
-Flags are especially useful for scripting, CI/CD environments, or setting up multiple machines.
-</Tip>
-
-#### Supported Providers
-
-| Provider | Provider ID | Notes |
-|----------|-------------|-------|
-| Anthropic | `anthropic` | Direct Claude API access |
-| OpenAI | `openai-native` | GPT-4o, GPT-4, etc. |
-| OpenAI Codex | `openai-codex` | ChatGPT subscription OAuth |
-| OpenRouter | `openrouter` | Access multiple providers |
-| AWS Bedrock | `bedrock` | Claude via AWS |
-| Google Gemini | `gemini` | Gemini Pro, etc. |
-| X AI (Grok) | `xai` | Grok models |
-| Cerebras | `cerebras` | Fast inference |
-| DeepSeek | `deepseek` | DeepSeek models |
-| Ollama | `ollama` | Local models |
-| LM Studio | `lmstudio` | Local models |
-| OpenAI Compatible | `openai` | Any OpenAI-compatible API |
-
-### Verify Your Setup
-
-Confirm everything is working with a simple test:
-
-```bash
-cline "What is 2 + 2?"
-```
-
-If Cline responds with an answer, your installation and authentication are complete.
-
-Check your current configuration:
-
-```bash
-cline config
-```
-
-### Quick Start
-
-Now you're ready to use Cline. Choose how you want to work:
-
-#### Interactive Mode
-
-Launch the interactive CLI for development:
-
-```bash
-cline
-```
-
-You'll see the Cline welcome screen. Type your task and press Enter. Use:
- `Tab` to toggle between Plan and Act modes
- `Shift+Tab` to enable auto-approve
- `/help` for available commands
-
-[Learn more about interactive mode →](/cline-cli/interactive-mode)
-
-#### Direct Task Execution
-
-Run a task directly from your shell:
-
-```bash
-cline "Add error handling to utils.js"
-```
-
-For non-interactive execution (perfect for scripts and CI/CD):
-
-```bash
-cline -y "Run tests and fix any failures"
-```
-
-[Learn more about headless mode →](/cline-cli/three-core-flows)
-
-### Switching Providers
-
-To change your configured provider at any time:
-
-```bash
-cline auth
-```
-
-You can also use the settings panel in interactive mode:
-
-```bash
-cline
-# Then type: /settings
-# Navigate to the API tab
-```
-
-### Updating
-
-Check for updates and install the latest version:
-
-```bash
-cline update
-```
-
-Or update manually via npm:
-
-```bash
-npm update -g cline
-```
-
-### Troubleshooting
-
-#### Command Not Found
-
-If `cline` is not found after installation:
-
-1. Ensure npm global bin is in your PATH:
-   ```bash
-   npm bin -g
-   ```
-
-2. Add the path to your shell configuration (`.bashrc`, `.zshrc`, etc.):
-   ```bash
-   export PATH="$PATH:$(npm bin -g)"
-   ```
-
-3. Restart your terminal or source your shell config.
-
-#### Permission Errors
-
-If you get permission errors during installation:
-
-```bash
-# Option 1: Use a Node version manager (recommended)
-# nvm, fnm, or volta handle permissions automatically
-
-# Option 2: Fix npm permissions
-# See: https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally
-```
-
-#### OAuth Flow Issues
-
-If the browser doesn't open automatically during OAuth:
-1. Copy the URL from the terminal
-2. Paste it in your browser manually
-3. Complete the sign-in flow
-4. Return to the terminal
-
-#### API Key Validation
-
-If your API key is rejected:
-1. Verify the key is correct and hasn't expired
-2. Check that you've selected the correct provider
-3. Ensure your API account has the necessary permissions
-
-**Provider-specific tips:**
- **Anthropic**: Keys start with `sk-ant-`
- **OpenAI**: Keys start with `sk-`
- **AWS Bedrock**: Requires AWS credentials configured separately. See [AWS Bedrock documentation](/provider-config/aws-bedrock/api-key).
-
-### Uninstallation
-
-To remove Cline CLI:
-
-```bash
-npm uninstall -g cline
-```
-
-To also remove configuration data:
-
-```bash
-rm -rf ~/.cline
-```
-
-## Next Steps
-
- **[Interactive Mode](/cline-cli/interactive-mode)** - Master the interactive CLI with shortcuts and slash commands
- **[Headless Mode](/cline-cli/three-core-flows)** - Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows
- **[Configuration](/cline-cli/configuration)** - Configure settings, rules, workflows, and environment variables
- **[CLI Reference](/cline-cli/cli-reference)** - Complete command documentation with all flags and options
@@ -74,9 +74,6 @@ cline auth -p openai-native -k sk-xxxxx -m gpt-4o
 # OpenRouter
 cline auth -p openrouter -k sk-or-xxxxx -m anthropic/claude-sonnet-4-5-20250929

-# Moonshot
-cline auth -p moonshot -k sk-xxxxx -m kimi-k2.5
-
 # OpenAI-compatible provider with custom base URL
 cline auth -p openai -k your-api-key -b https://api.example.com/v1
 ```
@@ -85,7 +82,7 @@ cline auth -p openai -k your-api-key -b https://api.example.com/v1

 | Flag | Description |
 |------|-------------|
-| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`, `moonshot`) |
+| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`) |
 | `-k, --apikey <key>` | Your API key |
 | `-m, --modelid <id>` | Model ID (e.g., `claude-sonnet-4-5-20250929`, `gpt-4o`) |
 | `-b, --baseurl <url>` | Base URL for OpenAI-compatible providers |
@@ -107,7 +104,6 @@ Flags are especially useful for scripting, CI/CD environments, or setting up mul
 | X AI (Grok) | `xai` | Grok models |
 | Cerebras | `cerebras` | Fast inference |
 | DeepSeek | `deepseek` | DeepSeek models |
-| Moonshot | `moonshot` | Kimi models via Moonshot AI |
 | Ollama | `ollama` | Local models |
 | LM Studio | `lmstudio` | Local models |
 | OpenAI Compatible | `openai` | Any OpenAI-compatible API |
@@ -161,7 +157,7 @@ For non-interactive execution (perfect for scripts and CI/CD):
 cline -y "Run tests and fix any failures"
 ```

-[Learn more about headless mode →](/cline-cli/three-core-flows)
+[Learn more about CLI workflows →](/cline-cli/three-core-flows)

 ## Switching Providers

@@ -264,8 +260,8 @@ rm -rf ~/.cline
    Master the interactive CLI with shortcuts and slash commands.
  </Card>
  
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
+    Learn interactive mode, direct execution, and automation patterns.
  </Card>
  
  <Card title="Configuration" icon="gear" href="/cline-cli/configuration">
@@ -65,7 +65,7 @@ Keyboard shortcuts are the primary way to navigate and control the interactive C

 Reference files from your workspace by typing `@` followed by the filename:

-```text
+```
@src/utils.ts can you add error handling to this file?
 ```

@@ -79,7 +79,7 @@ File search uses ripgrep for fast, fuzzy matching. You can type partial paths li

 Include multiple files in a single message:

-```text
+```
 Compare @src/old-api.ts with @src/new-api.ts and list the breaking changes
 ```

@@ -100,9 +100,9 @@ Type `/` to see available commands. Slash commands provide quick access to setti

 ### Workflow Commands

-If you have [workflows](/customization/workflows) configured, they appear as additional slash commands. For example, if you have a workflow named `code-review`, you can invoke it with:
+If you have [workflows](/features/slash-commands/workflows/index) configured, they appear as additional slash commands. For example, if you have a workflow named `code-review`, you can invoke it with:

-```text
+```
 /code-review
 ```

@@ -120,7 +120,7 @@ Access the settings panel with `/settings`. Navigate between tabs using arrow ke

 ## Plan and Act Modes

-Cline operates in two modes, toggled with `Tab`. These modes work the same way in the CLI as they do in the VS Code extension. For a deeper explanation of how Plan and Act modes work, see the [Plan and Act documentation](/core-workflows/plan-and-act).
+Cline operates in two modes, toggled with `Tab`. These modes work the same way in the CLI as they do in the VS Code extension. For a deeper explanation of how Plan and Act modes work, see the [Plan and Act documentation](/features/plan-and-act).

 ### Plan Mode

@@ -211,7 +211,7 @@ Use terminal multiplexers like tmux or split terminals to run multiple Cline ins

 Give Cline context about what you're working on:

-```text
+```
 I'm building a REST API with Express. The routes are in @src/routes/ and models in @src/models/. Help me add user authentication.
 ```

@@ -219,7 +219,7 @@ I'm building a REST API with Express. The routes are in @src/routes/ and models

 When you're unsure about the best approach:

-```text
+```
 [Tab to Plan mode]
 How should I structure the database schema for a multi-tenant SaaS app?
 ```
@@ -228,7 +228,7 @@ How should I structure the database schema for a multi-tenant SaaS app?

 The interactive CLI maintains conversation context. Build on previous messages:

-```text
+```
 > Add a login endpoint
 [Cline creates the endpoint]

@@ -242,8 +242,8 @@ The interactive CLI maintains conversation context. Build on previous messages:
 ## Next Steps

 <Columns cols={2}>
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
+    Learn about interactive mode, direct execution, and automation patterns.
  </Card>
  
  <Card title="Configuration" icon="gear" href="/cline-cli/configuration">
@@ -15,15 +15,6 @@ Ready to get started? Check out the [installation guide](/cline-cli/installation

 ## Two Ways to Use Cline CLI

-<Columns cols={2}>
-  <Card title="Interactive Mode" icon="terminal" href="/cline-cli/interactive-mode">
-    **For hands-on development.** Launch `cline` in your terminal and collaborate with Cline in real-time — chat, review plans, approve actions, and iterate on tasks with a rich visual interface.
-  </Card>
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    **For automation & CI/CD.** Run `cline -y "task"` to let Cline work autonomously — no interaction needed. Pipe input/output, get JSON results, and chain commands in scripts and pipelines.
-  </Card>
-</Columns>
-
 The CLI operates in two distinct modes, automatically selecting the appropriate one based on how you invoke it:

 ### Interactive Mode
@@ -95,7 +86,7 @@ Cline automatically detects which mode to use based on your invocation. This tab
 | `cat file \| cline "task"` | Headless | stdin is piped |
 | `cline "task" > output.txt` | Headless | stdout is redirected |

-[Learn more about headless mode →](/cline-cli/three-core-flows)
+[Learn more about CLI workflows →](/cline-cli/three-core-flows)

 ## Supported Model Providers

@@ -219,8 +210,8 @@ Chains multiple Cline invocations together for creative multi-step workflows.
    Master the interactive CLI with keyboard shortcuts and slash commands.
  </Card>
  
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
+    Learn interactive mode, direct execution, and automation patterns.
  </Card>
  
  <Card title="Configuration" icon="gear" href="/cline-cli/configuration">
@@ -231,7 +222,7 @@ Chains multiple Cline invocations together for creative multi-step workflows.
    Run Cline as an ACP agent in JetBrains, Neovim, Zed, and more.
  </Card>
  
-  <Card title="CLI Samples" icon="flask" href="/cline-cli/samples/overview">
-    Real-world examples of headless workflows and automation patterns.
+  <Card title="Use in Other Editors" icon="code" href="/cline-cli/acp-editor-integrations">
+    Run Cline as an ACP agent in JetBrains, Neovim, Zed, and more.
  </Card>
 </Columns>
@@ -3,6 +3,8 @@ 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.


@@ -271,7 +273,7 @@ git push

 Once set up, simply mention `@cline` in any issue comment:

-```text
+```
@cline what's causing this error?

@cline analyze the root cause
@@ -3,6 +3,8 @@ 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>
@@ -201,7 +203,7 @@ fi
 This is where the magic happens:

 ```bash
-# Ask Cline for its analysis, showing only the summary
+# 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' | \
@@ -378,4 +380,4 @@ This pattern can be adapted for many other automation scenarios, from pull reque

 - [CLI Installation Guide](https://docs.cline.bot/cline-cli/installation)
 - [CLI Reference Documentation](https://docs.cline.bot/cline-cli/cli-reference)
- [Headless Mode](https://docs.cline.bot/cline-cli/three-core-flows)
+- [Three Core Flows](https://docs.cline.bot/cline-cli/three-core-flows)
@@ -3,8 +3,14 @@ title: "GitHub PR Review"
 description: "Automatically review Pull Requests with AI using Cline CLI in GitHub Actions."
 ---

+# GitHub PR Review Sample
+
 Automate code review for every Pull Request. Detailed analysis, security checks, and code suggestions provided by Cline running autonomously in GitHub Actions.

+<Frame>
+  <img src="https://storage.googleapis.com/cline_public_images/cli-pr-review.png" alt="Cline PR Review Comment" width="600" />
+</Frame>
+
 ## The Workflow

 When a PR is opened or marked ready for review, this workflow:
@@ -3,21 +3,26 @@ title: "Model Orchestration"
 description: "Use multiple AI models strategically: optimize costs, reduce bias, and leverage model-specific strengths in your workflows"
 ---

+# Model Orchestration
+
 Cline CLI's `--config` and `--thinking` flags enable sophisticated multi-model workflows. Instead of using a single model for all tasks, you can route different work to different models based on cost, capability, and specialization.

 ## Why Orchestrate Multiple Models?

 **Cost Optimization**
-
-By routing work to the right model for the job, you can dramatically reduce API costs. Fast, inexpensive models like Haiku and Gemini Flash handle simple tasks such as summarization, while expensive models like Opus and O1 are reserved for complex reasoning and planning. This approach can reduce costs by 10-100x on routine operations.
+- Use fast, cheap models (Haiku, Gemini Flash) for simple tasks like summarization
+- Reserve expensive models (Opus, O1) for complex reasoning and planning
+- Reduce API costs by 10-100x on routine operations

 **Bias Reduction**
-
-Different models catch different issues, so cross-validating solutions with multiple AI perspectives helps reduce blind spots that come from relying on a single model. In code reviews especially, combining viewpoints surfaces problems that any one model might miss.
+- Different models catch different issues in code reviews
+- Cross-validate solutions with multiple AI perspectives
+- Reduce blind spots from single-model thinking

 **Specialization**
-
-Certain models excel in specific domains: Codex and DeepSeek are strong at code generation, while GPT-4 and Claude shine at documentation and prose. Security analysis in particular benefits from combining multiple model viewpoints, since each brings different training data and heuristics to the table.
+- Some models excel at code (Codex, DeepSeek)
+- Others are better at documentation (GPT-4, Claude)
+- Security analysis benefits from multiple viewpoints

 ## Pattern 1: CI/CD Code Review

@@ -208,8 +213,8 @@ cat *-sec.md | cline -y "find security issues all 3 reviews mentioned"
    Complete documentation for --config and --thinking flags
  </Card>
  
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
+    Learn about interactive mode, headless automation, and multi-instance workflows
  </Card>
  
  <Card title="Model Selection Guide" icon="brain" href="/core-features/model-selection-guide">
@@ -53,4 +53,4 @@ This section provides sample implementations that demonstrate various Cline CLI

 - [CLI Installation Guide](/cline-cli/installation)
 - [CLI Reference Documentation](/cline-cli/cli-reference)
- [Headless Mode](/cline-cli/three-core-flows)
+- [Three Core Flows](/cline-cli/three-core-flows)
@@ -3,6 +3,8 @@ title: "Worktree Workflows"
 description: "Use Git worktrees with Cline CLI to run parallel tasks, test different approaches, and pipe context between isolated environments"
 ---

+# Worktree Workflows
+
 Git worktrees let you have multiple branches checked out simultaneously in different folders. Combined with Cline CLI's `--cwd` flag, this enables powerful parallel development workflows and isolated experimentation.

 <Tip>
@@ -267,7 +269,7 @@ git worktree remove ~/cline-worktrees/feature-auth
    Complete documentation for --cwd and all other CLI flags
  </Card>
  
-  <Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
-    Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
+  <Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
+    Learn about interactive mode, task mode, and plain text workflows
  </Card>
 </Columns>
@@ -1,62 +1,72 @@
 ---
-title: "Headless Mode"
-description: "Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows"
+title: "CLI Workflows"
+description: "Learn the three ways to use Cline CLI: interactive mode, direct task execution, and automation"
 ---

-Headless mode runs Cline without an interactive interface — perfect for automation, scripting, and CI/CD pipelines where human interaction isn't possible or desired. Cline executes tasks, produces clean text or JSON output, and exits when complete.
-
-For collaborative, conversational development, see [Interactive Mode](/cline-cli/interactive-mode) instead.
+Cline CLI supports three primary workflows, each optimized for different use cases. Choose the approach that best fits your needs.

 <Note>
-**Migrating from an older CLI version?** Instance commands (`cline instance new/list/kill`) have been removed in Cline CLI 2.0. The new architecture is simpler — just use `cline -y "task"` for headless execution.
+**Migrating from an older CLI version?** Instance commands (`cline instance new/list/kill`) have been removed in Cline CLI 2.0. The new architecture is simpler. Just run `cline` for interactive mode or `cline "task"` for direct execution.
 </Note>

-## When Headless Mode Activates
+## 1. Interactive Mode

-Cline automatically enters headless mode when any of these conditions are met:
+The interactive CLI provides the richest experience for interactive development.

-| Invocation | Reason |
-|------------|--------|
-| `cline -y "task"` | `-y`/`--yolo` flag forces headless |
-| `cline --json "task"` | `--json` flag forces headless |
-| `cat file \| cline "task"` | stdin is piped |
-| `cline "task" > output.txt` | stdout is redirected |
-
-If none of these apply (e.g., running `cline` or `cline "task"` in a terminal), Cline launches in [interactive mode](/cline-cli/interactive-mode).
-
-## YOLO Mode (Fully Autonomous)
-
-The `-y` or `--yolo` flag enables fully autonomous operation — Cline approves all actions and runs without prompts:
+### Getting Started

 ```bash
-cline -y "Run the test suite and fix any failures"
+cline
 ```

-In YOLO mode:
- All actions are auto-approved
- Output is plain text (non-interactive)
- Process exits automatically when complete
- Perfect for CI/CD and scripts
+This launches an interactive session in your current directory. Type your task, and Cline will analyze and execute it.

-<Warning>
-YOLO mode gives Cline full autonomy. Run on a clean git branch so you can easily revert changes if needed.
-</Warning>
+### Key Features

-### Mode Selection
+**Plan/Act Mode Toggle** - Press `Tab` to switch between modes:
+- **Plan Mode**: Cline analyzes your request and presents a strategy
+- **Act Mode**: Cline executes actions directly

-Control whether Cline plans first or acts immediately:
+**Auto-approve Toggle** - Press `Shift+Tab` to enable automatic approval for all actions.
+
+**Slash Commands** - Type `/` for quick access to:
+- `/settings` - Configure providers, models, and features
+- `/models` - Quick model switching
+- `/history` - Browse and resume previous tasks
+- `/clear` - Start a fresh task
+- `/help` - Show available commands
+
+**File Mentions** - Type `@` to reference workspace files:
+```
+@src/utils.ts add error handling to this file
+```
+
+**Session Summary** - When you exit with `Ctrl+C`, Cline displays a summary of your session including tasks completed, files modified, and token usage.
+
+### When to Use Interactive Mode
+
+- Exploring a new codebase
+- Complex refactoring that requires back-and-forth
+- Learning how Cline approaches problems
+- Tasks where you want to review before executing
+
+[Full Interactive Mode Guide →](/cline-cli/interactive-mode)
+
+## 2. Direct Task Execution
+
+Execute tasks directly from the command line without entering interactive mode.
+
+### Basic Usage

 ```bash
-# Start in Plan mode (analyze before acting)
-cline -y -p "Design a REST API for user management"
-
-# Start in Act mode (default)
-cline -y -a "Fix the typo in README.md"
+cline "Add unit tests to utils.js"
 ```

-## Piping Context
+Cline analyzes your task, creates a plan, and executes it. You'll be prompted for approval at key decision points.

-Pipe file contents or command output into Cline to provide context:
+### Piping Context
+
+Pipe file contents or command output into Cline:

 ```bash
 # Explain a file
@@ -67,16 +77,11 @@ git diff | cline "Review these changes and suggest improvements"

 # Analyze command output
 npm test 2>&1 | cline "Analyze these test failures and fix them"
-
-# Pipe a GitHub PR diff
-gh pr diff 123 | cline -y "Review this PR"
 ```

-When stdin is piped, Cline automatically enters headless mode — the piped content becomes part of the task context.
+### Chaining Cline Commands

-## Chaining Commands
-
-Pipe Cline's output into another Cline instance for multi-step workflows:
+Pipe Cline's output into another Cline instance for creative workflows:

 ```bash
 # Explain changes, then write a commit message
@@ -89,9 +94,59 @@ cline -y "create a fibonacci function" | cline -y "write unit tests for this cod
 git diff | cline -y "explain" | cline -y "write a haiku about this"
 ```

-## JSON Output
+### Including Images

-Use `--json` for machine-readable output that's easy to parse in scripts:
+Attach images to your task:
+
+```bash
+cline task -i screenshot.png "Fix the layout issue shown in this screenshot"
+
+# Or reference inline
+cline "Fix the UI shown in @./design-mockup.png"
+```
+
+### Mode Selection
+
+```bash
+# Start in Plan mode (analyze before acting)
+cline -p "Design a REST API for user management"
+
+# Start in Act mode (default)
+cline -a "Fix the typo in README.md"
+```
+
+### When to Use Direct Execution
+
+- Quick, well-defined tasks
+- Tasks with sufficient context in the prompt
+- Scripting and shell workflows
+- When you don't need interactive conversation
+
+## 3. Automation & CI/CD
+
+For fully autonomous operation in scripts, CI/CD pipelines, and automated workflows.
+
+### YOLO Mode (Yes Mode)
+
+The `-y` or `--yolo` flag enables fully autonomous operation:
+
+```bash
+cline -y "Run the test suite and fix any failures"
+```
+
+In YOLO mode:
+- All actions are auto-approved
+- Output is plain text (non-interactive)
+- Process exits automatically when complete
+- Perfect for CI/CD and scripts
+
+<Warning>
+Run YOLO mode on a clean git branch or directory. You get speed in exchange for oversight, so be ready to revert if needed.
+</Warning>
+
+### JSON Output
+
+Use `--json` for machine-readable output:

 ```bash
 cline --json "List all TODO comments in the codebase" | jq '.text'
@@ -109,36 +164,25 @@ JSON output follows the same format as task files in `~/.cline/data/tasks/<id>/u
 | `reasoning` | `string` | (Optional) Model reasoning |
 | `partial` | `boolean` | (Optional) Streaming flag |

-## Including Images
+### Timeout Control

-Attach images to your headless task:
-
-```bash
-cline -y -i screenshot.png "Fix the layout issue shown in this screenshot"
-
-# Or reference inline
-cline -y "Fix the UI shown in @./design-mockup.png"
-```
-
-## Timeout Control
-
-Set a maximum execution time to prevent runaway tasks:
+Set a maximum execution time:

 ```bash
 cline -y --timeout 600 "Run full test suite"
 ```

-## Environment Variables
+### Environment Variables

-Control Cline behavior via environment variables — useful for CI/CD where you can't use interactive configuration.
+Control Cline behavior via environment variables:

-**CLINE_DIR** — Custom configuration directory:
+**CLINE_DIR** - Custom configuration directory:
 ```bash
 export CLINE_DIR=/path/to/config
 cline -y "your task"
 ```

-**CLINE_COMMAND_PERMISSIONS** — Restrict allowed commands:
+**CLINE_COMMAND_PERMISSIONS** - Restrict allowed commands:
 ```bash
 export CLINE_COMMAND_PERMISSIONS='{"allow": ["npm *", "git *"], "deny": ["rm -rf *"]}'
 cline -y "your task"
@@ -146,8 +190,6 @@ cline -y "your task"

 See [Configuration](/cline-cli/configuration#environment-variables) for full documentation.

-## CI/CD Integration
-
 ### GitHub Actions Example

 Automate PR reviews with Cline:
@@ -190,7 +232,7 @@ jobs:

 ### Shell Script Example

-Create a reusable code review script:
+Create a code review script:

 ```bash
 #!/bin/bash
@@ -210,24 +252,30 @@ fi
 echo "$DIFF" | cline -y --json "Review this code diff for issues" | jq -r '.text'
 ```

-## Common Use Cases
+### When to Use Automation Mode

-| Use Case | Example |
-|----------|---------|
-| Code review | `git diff \| cline -y "Review these changes"` |
-| Fix test failures | `cline -y "Run tests and fix any failures"` |
-| Generate release notes | `git log --oneline v1.0..v1.1 \| cline -y "Write release notes"` |
-| Fix lint errors | `cline -y "Fix all ESLint errors in src/"` |
-| Update dependencies | `cline -y "Update dependencies with known vulnerabilities"` |
-| Migrate code patterns | `cline -y "Update all deprecated React lifecycle methods"` |
-| PR automation | `gh pr diff 123 \| cline -y "Review this PR"` |
-| Batch processing | `cline -y --json "List all TODO comments" \| jq '.text'` |
+- CI/CD pipelines
+- Scheduled maintenance tasks
+- Batch processing
+- Any workflow requiring non-interactive execution
+
+## Choosing the Right Flow
+
+| Use Case | Recommended Flow |
+|----------|------------------|
+| Exploring a new codebase | Interactive Mode |
+| Complex refactoring | Interactive Mode (Plan first) |
+| Quick file edits | Direct Execution |
+| Code review | Direct Execution with pipe |
+| CI/CD integration | Automation (`-y` flag) |
+| Scheduled tasks | Automation (`-y` flag) |
+| Learning Cline | Interactive Mode |

 ## Next Steps

 <Columns cols={2}>
  <Card title="Interactive Mode" icon="terminal" href="/cline-cli/interactive-mode">
-    For hands-on development with keyboard shortcuts, slash commands, and file mentions.
+    Master keyboard shortcuts, slash commands, and file mentions.
  </Card>
  
  <Card title="CLI Reference" icon="book" href="/cline-cli/cli-reference">
@@ -238,7 +286,7 @@ echo "$DIFF" | cline -y --json "Review this code diff for issues" | jq -r '.text
    Environment variables, rules, and advanced settings.
  </Card>
  
-  <Card title="CLI Samples" icon="flask" href="/cline-cli/samples/overview">
-    Real-world examples of headless workflows and automation patterns.
+  <Card title="YOLO Mode" icon="zap" href="/features/yolo-mode">
+    Deep dive into autonomous execution and safety considerations.
  </Card>
 </Columns>
@@ -1,316 +0,0 @@
---
-title: "Documentation Templates"
-sidebarTitle: "Templates"
-description: "Templates for different types of Cline documentation"
---
-
-Use these templates as starting points for new documentation. Each template is designed for a specific purpose. Choose the one that best fits what you're documenting.
-
-## Choosing a Template
-
-| If you're documenting... | Use this template |
-|--------------------------|-------------------|
-| What a feature does and how to use it | Feature Doc |
-| How to accomplish a specific task | How-To Guide |
-| Technical specifications or API details | Reference Doc |
-| A complete project walkthrough | Tutorial |
-
-## Feature Doc
-
-Use this template when explaining a Cline feature. Focus on what it does, how to use it, and real examples.
-
-````text
---
-title: "Feature Name"
-sidebarTitle: "Feature Name"
---
-
-[One sentence explaining what this feature does.]
-
-<Frame>
-  <img src="..." alt="Feature in action" />
-</Frame>
-
-[1-2 paragraphs explaining the feature in plain terms. What problem does it 
-solve? Why would someone use it?]
-
-## How It Works
-
-[Explain the mechanics without jargon. What happens when you use this feature?]
-
-## Using [Feature Name]
-
-[Show how to access and use it. Include the exact UI path.]
-
-### [Option or Variation 1]
-
-[Details with examples]
-
-### [Option or Variation 2]
-
-[Details with examples]
-
-## Inspiration
-
-[Share how you personally use this feature. Use "I" voice. Give 2-3 real 
-examples that spark imagination about what's possible.]
-
-<Note>
-  [Important caveat, limitation, or requirement]
-</Note>
-````
-
-### Example: Checkpoints Feature
-
-Here's how the [Checkpoints](/core-workflows/checkpoints) doc follows this pattern:
-
- Opens with one clear sentence about what checkpoints do
- Shows a screenshot of the feature in action
- Explains how checkpoints work under the hood
- Shows exact steps to create and restore checkpoints
- Includes real examples of when checkpoints save the day
-
-## How-To Guide
-
-Use this template when showing how to accomplish a specific task. Focus on clear steps and troubleshooting.
-
-````text
---
-title: "How to [Accomplish Task]"
-sidebarTitle: "[Short Title]"
-description: "[One sentence describing what the reader will learn]"
---
-
-[Brief intro explaining what problem this guide solves and what you'll end up 
-with after following it.]
-
-## Prerequisites
-
-[What the reader needs before starting. Keep it short. Link to other docs 
-rather than explaining setup here.]
-
- Cline installed and configured
- [Other requirement]
-
-## Steps
-
-<Steps>
-  <Step title="[First Action]">
-    [Clear instructions. Show exactly what to click or type.]
-    
-    ```bash
-    example command if needed
-    ```
-  </Step>
-  <Step title="[Second Action]">
-    [Next step. Include screenshots for complex UI interactions.]
-    
-    <Frame>
-      <img src="..." alt="What you should see" />
-    </Frame>
-  </Step>
-  <Step title="[Final Action]">
-    [Complete the task. Show the expected result.]
-  </Step>
-</Steps>
-
-## Troubleshooting
-
-Common issues and how to fix them:
-
- **Problem description**: Solution in one or two sentences.
- **Another problem**: Another solution.
-
-## Next Steps
-
-<Card title="Related Feature" icon="arrow-right" href="/path/to/related">
-  Continue learning with this related guide.
-</Card>
-````
-
-### Example: Your First Project
-
-The [Your First Project](/getting-started/your-first-project) guide follows this pattern:
-
- Clear goal stated upfront
- Prerequisites listed briefly
- Step-by-step instructions with the Steps component
- Troubleshooting section for common issues
-
-## Reference Doc
-
-Use this template for technical specifications, API documentation, or detailed configuration options.
-
-````text
---
-title: "[Component/API] Reference"
-sidebarTitle: "[Short Title]"
-description: "[What this reference covers]"
---
-
-[Brief description of what this reference documents and when you'd need it.]
-
-## Overview
-
-[High-level explanation. What is this component? What role does it play?]
-
-## [Category 1]
-
-### [Item Name]
-
-[What it does in one sentence.]
-
-| Property | Type | Default | Description |
-|----------|------|---------|-------------|
-| `propertyName` | `string` | `"default"` | What this property controls |
-| `anotherProp` | `boolean` | `false` | What this does |
-
-**Example:**
-
-```typescript
-// Show practical usage
-const example = {
-  propertyName: "custom value",
-  anotherProp: true
-}
-```
-
-### [Another Item]
-
-[Continue for each item in this category.]
-
-## [Category 2]
-
-[Continue with other categories as needed.]
-
-## Examples
-
-[Show 2-3 complete, practical examples that combine multiple concepts.]
-
-### [Example 1 Title]
-
-```typescript
-// Complete working example
-```
-
-### [Example 2 Title]
-
-```typescript
-// Another complete example
-```
-
-## Related
-
- [Related Doc 1](/path/to/doc) - Brief description
- [Related Doc 2](/path/to/doc) - Brief description
-````
-
-### Example: Cline Tools Guide
-
-The [Cline Tools Guide](/tools-reference/all-cline-tools) follows this pattern:
-
- Overview of the tool system
- Each tool documented with parameters and examples
- Practical examples showing tools in context
-
-## Tutorial
-
-Use this template for comprehensive project walkthroughs where users build something from start to finish.
-
-````text
---
-title: "[Build/Create X] Tutorial"
-sidebarTitle: "[Short Title]"
-description: "[What the reader will build]"
---
-
-In this tutorial, you'll build [specific outcome]. By the end, you'll have 
-[tangible result you can see/use].
-
-<Frame>
-  <img src="..." alt="Preview of what you'll build" />
-</Frame>
-
-## What You'll Learn
-
- [Skill or concept 1]
- [Skill or concept 2]
- [Skill or concept 3]
-
-## Prerequisites
-
-[Required setup. Link to installation guides rather than repeating them.]
-
- [Prerequisite 1]
- [Prerequisite 2]
-
-## Part 1: [First Major Section]
-
-[Introduction to this section. What are we doing and why?]
-
-### [Subsection]
-
-[Detailed walkthrough with code blocks and explanations.]
-
-```typescript
-// Code that the reader should write or understand
-```
-
-[Explain what the code does and why.]
-
-## Part 2: [Second Major Section]
-
-[Continue building on Part 1.]
-
-### [Subsection]
-
-[More detailed walkthrough.]
-
-## Part 3: [Final Section]
-
-[Complete the project.]
-
-## Summary
-
-You built [what they built]. Along the way, you learned:
-
- [Key takeaway 1]
- [Key takeaway 2]
- [Key takeaway 3]
-
-## Next Steps
-
-<CardGroup cols={2}>
-  <Card title="Go Deeper" icon="book" href="/path/to/advanced">
-    Learn more advanced techniques.
-  </Card>
-  <Card title="Related Tutorial" icon="code" href="/path/to/related">
-    Build something else with similar concepts.
-  </Card>
-</CardGroup>
-````
-
-### Example Structure
-
-A good tutorial:
- Shows the end result upfront so readers know what they're building
- Breaks the work into logical parts
- Explains the "why" alongside the "how"
- Ends with clear next steps
-
-## Quick Tips
-
-When using these templates:
-
-1. **Delete sections you don't need.** Templates are starting points, not rigid structures.
-
-2. **Add sections that make sense.** If your doc needs something not in the template, add it.
-
-3. **Keep the reader moving forward.** Every section should lead naturally to the next.
-
-4. **Test your own instructions.** Follow your guide from scratch to catch missing steps.
-
-<Tip>
-  Use the `/write-docs` workflow to generate documentation from these templates automatically. 
-  Cline helps you fill in each section based on your project.
-</Tip>
@@ -1,200 +0,0 @@
---
-title: "Documentation Guide"
-sidebarTitle: "Documentation Guide"
-description: "How to write and contribute to Cline documentation"
---
-
-Cline's documentation lives in the `docs/` directory and uses [Mintlify](https://mintlify.com) for rendering. This guide covers how to write docs that match Cline's established style.
-
-## Using the Documentation Workflow
-
-The fastest way to create documentation is using the `/write-docs` workflow. Type `/write-docs` in Cline and describe what you want to document. Cline guides you through a 4-step process:
-
-1. **Research**: Examine existing docs structure and patterns
-2. **Scope**: Clarify audience, doc type, and key use cases
-3. **Outline**: Select a template and create structure
-4. **Write**: Generate documentation following style guidelines
-
-The workflow file lives at `.clinerules/workflows/write-docs.md` and contains templates, style rules, and examples.
-
-## Documentation Principles
-
-### Write for Developers
-
-Your audience is developers who value their time. Get to the point. Every sentence should either help them understand something or help them do something.
-
-```markdown
-# Good
-Switch to bash in Cline Settings → Terminal → Default Terminal Profile.
-
-# Bad
-Users who are experiencing issues may find it helpful to navigate to the 
-Cline settings menu where they can locate the terminal configuration 
-options and subsequently modify the default terminal profile setting.
-```
-
-### Show Real Examples
-
-Abstract descriptions don't help anyone. Show actual code, real file paths, and concrete implementations.
-
-```markdown
-# Good
-I use `/deep-planning` whenever I'm building features that touch multiple 
-parts of the codebase. For example, when adding authentication, Cline 
-mapped every endpoint and created a migration plan that avoided breaking changes.
-
-# Bad
-The deep planning feature can be utilized for various complex tasks 
-that may require careful consideration and planning.
-```
-
-### Use Active Voice
-
-Cline does things. Files don't get created by Cline, Cline creates files.
-
-```markdown
-# Good
-Cline reads your project files and builds context automatically.
-
-# Bad
-Project files are read and context is built automatically.
-```
-
-### Use Neutral Pronouns for Cline
-
-Refer to Cline as "it" not "he". Cline is software, not a person.
-
-```markdown
-# Good
-When Cline encounters an error, it suggests fixes.
-
-# Bad
-When Cline encounters an error, he suggests fixes.
-```
-
-## File Format
-
-All documentation uses MDX format with YAML frontmatter:
-
-```yaml
---
-title: "Full Page Title"
-sidebarTitle: "Shorter Nav Title"  # optional
-description: "One sentence for SEO"  # optional but recommended
---
-```
-
-### Adding New Pages
-
-After creating a new `.mdx` file, add it to `docs/docs.json` in the appropriate navigation group:
-
-```json
-{
-  "group": "Features",
-  "pages": [
-    "features/existing-page",
-    "features/your-new-page"
-  ]
-}
-```
-
-## Mintlify Components
-
-Use these components appropriately throughout your docs.
-
-### Frame
-
-Wrap all images and videos:
-
-```jsx
-<Frame>
-  <img 
-    src="https://storage.googleapis.com/cline_public_images/docs/assets/filename.png" 
-    alt="Descriptive alt text" 
-  />
-</Frame>
-```
-
-### Callouts
-
-Use sparingly and purposefully:
-
-```jsx
-<Tip>Helpful suggestions that improve the experience.</Tip>
-<Note>Important information the reader needs to know.</Note>
-<Warning>Something that could cause problems if ignored.</Warning>
-```
-
-### Steps
-
-For sequential procedures:
-
-```jsx
-<Steps>
-  <Step title="Install the Extension">
-    Search for "Cline" in the VS Code marketplace.
-  </Step>
-  <Step title="Configure Your Model">
-    Open settings and add your API key.
-  </Step>
-</Steps>
-```
-
-### Cards
-
-For navigation and feature overviews:
-
-```jsx
-<CardGroup cols={2}>
-  <Card title="Getting Started" icon="rocket" href="/getting-started/installing-cline">
-    Install Cline and set up your first project.
-  </Card>
-  <Card title="Features" icon="wand-magic-sparkles" href="/core-workflows/plan-and-act">
-    Explore what Cline can do.
-  </Card>
-</CardGroup>
-```
-
-## Style Rules
-
-Quick reference for consistent documentation:
-
-| Do | Don't |
-|---|---|
-| Use "use" | Use "utilize" |
-| Keep sentences under 25 words | Write run-on sentences |
-| Use bullet points for lists | Write walls of text |
-| Show where things are in the UI | Assume users can find features |
-| Cross-link related docs | Leave readers stranded |
-| Use code blocks with language tags | Use inline code for long snippets |
-
-### Avoid These Patterns
-
- Em dashes and emojis
- Starting with "This document explains..."
- The **Bold Text**: description pattern
- Explaining obvious things
- Passive voice
-
-## Previewing Changes
-
-Run the docs locally to preview your changes:
-
-```bash
-cd docs
-npm install  # first time only
-npm run dev
-```
-
-Open `http://localhost:3000` to see your changes in real time.
-
-## Related Resources
-
-<CardGroup cols={2}>
-  <Card title="Documentation Templates" icon="file-lines" href="/contributing/doc-templates">
-    Templates for different documentation types.
-  </Card>
-  <Card title="Workflows" icon="diagram-project" href="/customization/workflows">
-    Learn about Cline's workflow system.
-  </Card>
-</CardGroup>
@@ -1,6 +1,6 @@
 ---
 title: "Model Selection Guide"
-description: "Choose the right AI model for your workflow based on reliability, speed, cost, and context window size."
+description: "Last updated: August 20, 2025."
 ---

 New models drop constantly, so this guide focuses on what's working well with Cline right now. We'll keep it updated as the landscape shifts.
@@ -59,17 +59,12 @@ Choose your preferred AI provider from the dropdown menu.
 | **Cline** | Easiest setup | No API keys needed, access to multiple models including stealth models |
 | **OpenRouter** | Value seekers | Multiple models, competitive pricing |
 | **Anthropic** | Reliability | Claude models, most dependable tool usage |
-| **OpenAI** | Latest tech | GPT-5, o3, o4-mini models |
-| **OpenAI Codex** | ChatGPT subscribers | Use your ChatGPT subscription — no API key needed |
-| **Google Gemini** | Large context | Gemini 3/2.5 with up to 2M context |
-| **DeepSeek** | Budget reasoning | V3.2, R1 models at low cost |
-| **Alibaba Qwen** | Open source coding | Qwen3 Coder with 1M context |
-| **Moonshot** | Agentic coding | Kimi K2.5 with 262K context |
-| **Cerebras** | Speed | Up to 2,600 tokens/sec |
+| **OpenAI** | Latest tech | GPT models |
+| **Google Gemini** | Large context | Google's AI models |
 | **AWS Bedrock** | Enterprise | Advanced features |
 | **Ollama** | Privacy | Run models locally |

-See the [full provider list](/getting-started/authorizing-with-cline) for all 30+ supported providers including xAI Grok, Mistral, Groq, Fireworks, Together, Baseten, SambaNova, Nebius, Hugging Face, and more.
+See the [full provider list](/provider-config) for more options including Cerebras, Vertex AI, Azure, and more.

 <Info>
 **Recommended for beginners:** Start with **Cline** as your provider - no API key management needed, instant access to multiple models, and occasional free inferencing through partner providers.
@@ -86,19 +81,6 @@ The next step depends on which provider you selected.
 - You'll be redirected to [app.cline.bot](https://app.cline.bot) to authenticate
 - After signing in, return to your IDE

-<Note>
-  For detailed information about the Cline authentication flow, OAuth tokens, and troubleshooting, see [Authorizing with Cline](/getting-started/authorizing-with-cline).
-</Note>
-
-#### If you selected **OpenAI Codex** as your provider:
-
- **No API key needed!** If you have a ChatGPT subscription (Plus, Pro, or Team), you can use it directly in Cline
- Click **"Sign in with OpenAI"** to authenticate via your browser
- Once authorized, all models available on your OpenAI plan will appear automatically
- Usage is governed by your ChatGPT subscription — no separate API billing
-
-See the full [OpenAI Codex setup guide](/provider-config/openai-codex) for details.
-
 #### If you selected any other provider:

 You'll need to get an API key from your chosen provider:
@@ -108,7 +90,7 @@ You'll need to get an API key from your chosen provider:
   - **OpenRouter**: [openrouter.ai/keys](https://openrouter.ai/keys)
   - **OpenAI**: [platform.openai.com/api-keys](https://platform.openai.com/api-keys)
   - **Google**: [aistudio.google.com/apikey](https://aistudio.google.com/apikey)
-   - **Others**: See [Provider Setup Guide](/getting-started/authorizing-with-cline)
+   - **Others**: See [Provider Setup Guide](/provider-config)

 2. **Generate a new API key** on the provider's website

@@ -186,7 +168,8 @@ Selecting the right model involves balancing several factors. Use this framework

 ## Model Comparison Resources

-For detailed model comparisons and performance metrics, see:
+For detailed model comparisons, pricing, and performance metrics, see:
+- [**Model Comparison & Pricing**](/model-config/model-comparison) - Complete pricing tables and performance benchmarks
 - [**Context Window Guide**](/model-config/context-windows) - Understanding and optimizing context usage

 ## Open Source vs Closed Source
@@ -212,9 +195,8 @@ For detailed model comparisons and performance metrics, see:
 | Huge context windows | Gemini 2.5 Pro or Claude Sonnet 4.5 |
 | Open source | Qwen3 Coder, Z AI GLM 4.5, or Kimi K2 |
 | Latest tech | GPT-5 |
-| To use your ChatGPT subscription | [OpenAI Codex](/provider-config/openai-codex) — sign in with your OpenAI account, no API key needed |
 | Speed | Qwen3 Coder on Cerebras (fastest available) |

 ## What Others Are Using

-Check [Vercel's leaderboard](https://vercel.com/ai-gateway/leaderboards) to see real usage patterns from the community.
+Check [OpenRouter's Cline usage stats](https://openrouter.ai/apps?url=https%3A%2F%2Fcline.bot%2F) to see real usage patterns from the community.
@@ -1,95 +0,0 @@
---
-title: "Checkpoints"
-sidebarTitle: "Checkpoints"
-description: "Roll back code changes while keeping your conversation. Experiment freely."
---
-
-Checkpoints let you undo code changes without losing your conversation. Every time Cline modifies a file or runs a command, it saves a snapshot of your project files. You can restore to any checkpoint, keeping the context you've built while reverting the code.
-
-This changes how you work with Cline. Instead of carefully reviewing every change before approving, you can let Cline move fast and roll back if something goes wrong. The cost of a mistake drops to nearly zero.
-
-<Tip>
-Checkpoints are enabled by default. See [Enable or Disable Checkpoints](#enable-or-disable-checkpoints) if you need to turn them off.
-</Tip>
-
-## How It Works
-
-Cline maintains a shadow Git repository separate from your project's actual Git history. After each tool use (file edits, commands, etc.), Cline commits the current state of your files to this shadow repo. Your main Git repository stays untouched.
-
-This means:
-
- Your Git history remains clean and under your control
- Checkpoints capture everything, including files not tracked by Git
- You can restore to any point in a task without affecting commits you've made
- Checkpoints persist across editor sessions
-
-Each checkpoint captures the complete file state at that moment. If Cline edits three files in sequence, you get three checkpoints and can restore to any of them independently.
-
-## Enable or Disable Checkpoints
-
-Checkpoints are enabled by default. To toggle them:
-
-1. Open Cline settings (gear icon in the Cline sidebar)
-2. Scroll to the "Feature Settings" section
-3. Toggle "Enable Checkpoints"
-
-<Note>
-For very large repositories, checkpoints may use significant storage and slow down Cline as it commits file snapshots after each tool use. Consider disabling them if you notice performance issues.
-</Note>
-
-## Viewing and Comparing Changes
-
-After each tool use, a checkpoint indicator appears in your conversation. Look for a bookmark icon labeled "Checkpoint" with a dotted line connecting to **Compare** and **Restore** buttons.
-
-Click **Compare** to open a diff view showing exactly what changed at that checkpoint. This opens in your editor's diff viewer, letting you see additions, deletions, and modifications across all affected files.
-
-This is useful when Cline makes changes you want to understand before deciding whether to keep them. You can review the diff, then either continue or restore to undo.
-
-## Restoring Checkpoints
-
-Click **Restore** next to any step to open the restore menu. You have three options:
-
-| Option | What It Does | When to Use It |
-|--------|--------------|----------------|
-| **Restore Files** | Reverts your project's files to the snapshot at this checkpoint | Undoing code changes while keeping the conversation |
-| **Restore Task Only** | Deletes messages after this point, does not affect files | Trying a different prompt while keeping current code |
-| **Restore Files & Task** | Reverts files and deletes messages after this point | Starting over completely from a known good state |
-
-The right choice depends on what went wrong:
-
- If the conversation is productive but the code changes broke something, use **Restore Files**. Cline keeps all the context you've discussed and can try a different implementation.
-
- If Cline's code changes are good but the conversation went off track, use **Restore Task Only**. You keep the files and can guide the conversation differently.
-
- If you want to start over from a clean slate, use **Restore Files & Task**. This resets both your files and the conversation to that checkpoint.
-
-## When to Use Checkpoints
-
-| Scenario | Recommended Action |
-|----------|-------------------|
-| Cline refactored code and broke something | Restore Files, ask for a different approach |
-| Experimenting with multiple solutions | Compare each checkpoint, restore to the best one |
-| Cline misunderstood your intent | Restore Files & Task, rephrase your request |
-| Want to try a different prompt | Restore Task Only, keep the files, resubmit |
-| Reviewing changes before committing to Git | Use Compare to inspect, then commit manually |
-| Testing risky changes | Let Cline proceed, restore if it fails |
-
-## Working with Auto-Approve
-
-Checkpoints make [auto-approve](/features/auto-approve) practical. Without checkpoints, auto-approve feels risky because Cline can make many changes before you notice a problem. With checkpoints, you can let Cline work autonomously and roll back if needed.
-
-A typical workflow:
-
-1. Enable auto-approve for file edits and commands
-2. Let Cline work through your task quickly
-3. Review the final result
-4. If something is wrong, restore to the last good checkpoint
-5. Give Cline more specific guidance
-
-This approach is faster than reviewing every change individually, and checkpoints provide the safety net.
-
-## Checkpoints and Message Editing
-
-The message editing feature integrates with checkpoints. When you edit a previous message and select "Restore All," Cline restores your files to the checkpoint at that point before resubmitting your edited message.
-
-This lets you fix a poorly worded prompt and undo all the changes that resulted from it in one action.
@@ -1,120 +0,0 @@
---
-title: "Plan & Act Mode"
-sidebarTitle: "Plan & Act Mode"
-description: "Think first, then build. Cline's dual-mode system for structured development."
---
-
-Plan & Act modes separate thinking from doing. Plan mode lets you explore and strategize without changing files. Act mode executes against your plan.
-
-<Tip>
-	**New to Plan & Act?** Watch [Plan & Act Deep Dive](https://youtu.be/b7o6URFPp64) to see it in action.
-</Tip>
-
-## Plan Mode
-
-Plan mode is where you and Cline figure out what you're building and how. In this mode, Cline can read your codebase, run searches, and discuss strategy, but cannot modify any files or execute commands.
-
-This constraint is intentional. It keeps the conversation focused on understanding and planning, without the distraction of implementation details. You can explore freely, ask questions, and iterate on the approach before committing to changes.
-
-Use Plan mode to:
-
- Explore unfamiliar codebases before making changes
- Discuss architecture decisions and tradeoffs
- Identify edge cases and potential issues upfront
- Create a clear implementation strategy
- Review code and understand complex workflows
-
-## Act Mode
-
-Once you have a plan, switch to Act mode. Cline retains the full context from your planning session and can now modify files, run commands, and execute your strategy.
-
-The conversation history carries over when you switch modes. Cline remembers everything you discussed in Plan mode, so you don't need to repeat yourself. This makes the transition seamless.
-
-<Note>
-	While you can start directly in Act mode, planning first is highly recommended. The planning phase intentionally builds context that Cline needs to implement changes effectively. Without it, Cline may lack the understanding required to make the right decisions.
-</Note>
-
-## Typical Workflow
-
-1. Start in Plan mode and describe what you want to build
-2. Let Cline explore relevant files and understand the codebase
-3. Discuss the approach, considering edge cases and potential issues
-4. When confident in the plan, switch to Act mode
-5. Cline implements the solution based on your planning session
-
-For complex projects, you may cycle between modes multiple times. Return to Plan mode when you hit unexpected complexity or need to rethink the approach, then switch back to Act mode to continue implementation.
-
-## When to Use Each Mode
-
-| Scenario | Recommended Mode |
-|----------|-----------------|
-| Starting new features where the approach isn't obvious | Plan |
-| Debugging tricky issues where you're unsure what's wrong | Plan |
-| Making architectural decisions affecting multiple files | Plan |
-| Understanding complex workflows before modifying them | Plan |
-| Code review and security analysis | Plan |
-| Learning a new codebase | Plan |
-| Implementing a solution you've already planned | Act |
-| Making routine changes with a clear approach | Act |
-| Following established patterns in the codebase | Act |
-| Running tests and making adjustments | Act |
-| Quick fixes where the solution is obvious | Act |
-
-## Using Different Models for Each Mode
-
-You can configure separate models for Plan and Act modes. This is useful when you want to use a stronger reasoning model for planning and a faster model for implementation.
-
-To enable this:
-
-1. Open Cline Settings
-2. Enable "Use different models for Plan and Act"
-3. Select your preferred model for each mode
-
-When enabled, switching between Plan and Act mode automatically switches to the configured model for that mode. Your model selection is preserved when you switch back.
-
-**Example configurations:**
-
-| Use Case | Plan Mode | Act Mode |
-|----------|-----------|----------|
-| Cost optimization | GLM 4.6 | Grok Code Fast |
-| Maximum quality | Claude Opus | Claude Sonnet |
-| Speed-focused | Gemini 3 Flash | Cerebras |
-
-## Using `/deep-planning`
-
-For complex tasks that need thorough analysis, use the `/deep-planning` slash command. This triggers an extended planning session where Cline:
-
-1. Explores the codebase systematically
-2. Identifies all affected files and dependencies
-3. Creates a detailed implementation plan
-4. Asks clarifying questions before proceeding
-
-The deep planning prompt is optimized for each model family, so it adapts to the strengths of whatever model you're using. See the [Deep Planning docs](/features/deep-planning) for more details.
-
-## Choosing the Right Approach by Task Size
-
-### Small tasks: Act mode only
-
-For quick fixes like typos, simple bug fixes, or following established patterns, start directly in Act mode. Planning adds overhead when the solution is obvious.
-
-**Examples:** Fix a typo, add a missing import, update a config value, rename a variable.
-
-### Medium tasks: Plan → Act
-
-For most development work, start in Plan mode to understand the scope and approach, then switch to Act mode to implement. This is the sweet spot for features that touch a few files and have some complexity.
-
-**Examples:** Add a new API endpoint, implement a UI component, fix a bug that requires investigation, refactor a single module.
-
-### Large tasks: Use `/deep-planning`
-
-For complex features that span multiple files, require architectural decisions, or will take multiple sessions to complete, use the `/deep-planning` slash command. This creates a detailed implementation plan that Cline can reference throughout the work.
-
-**Examples:** Add a new feature across frontend and backend, major refactoring across the codebase, implementing a new system or integration, multi-step migrations.
-
-## Tips
-
- Have Cline write a markdown file summarizing the plan for future reference
- Use [file mentions](/core-workflows/working-with-files) to point Cline at relevant files during planning
- Switch back to Plan mode when encountering unexpected complexity rather than pushing through
- Enable [Checkpoints](/core-workflows/checkpoints) before Act mode so you can roll back if needed
- For large tasks, ask Cline to create a todo list during planning that you can track in Act mode
@@ -1,160 +0,0 @@
---
-title: "Tasks"
-sidebarTitle: "Tasks"
-description: "Organize your work with tasks - self-contained sessions that capture your conversations, code changes, and decisions."
---
-
-Every interaction with Cline happens within a task. Tasks are self-contained work sessions that capture your entire conversation, code changes, command executions, and decisions.
-
-## What are Tasks?
-
-A task begins when you submit a prompt to Cline. Your prompt defines the goal, and Cline works toward it through conversation, code changes, and tool use. The quality of your initial prompt directly affects how well Cline performs - clear, specific prompts lead to better results.
-
-Each task:
-
- Starts with your prompt and builds context through the conversation
- Has a unique identifier and dedicated storage directory
- Contains the full conversation history
- Tracks token usage, API costs, and execution time
- Can be interrupted and resumed across sessions
- Creates [checkpoints](/core-workflows/checkpoints) for file changes through Git-based snapshots
-
-<Tip>
-Want to get better results from Cline? Learn how to write effective prompts in our [Prompt Module](https://cline.bot/learn).
-</Tip>
-
-## Scoping Your Tasks
-
-Each task carries its own context: the conversation history, decisions made, and understanding built up over the session. How you scope your tasks directly affects how well Cline can help you.
-
-Think of it this way: **one task = one goal**. "Implement user authentication" is one task. "Fix an unrelated CSS bug" is a separate task, even if you notice it while working on auth.
-
-A focused task produces better results. When a task tries to cover too many unrelated goals, the context becomes cluttered and responses become less relevant.
-
-<Note>
-If you're unsure, err on the side of starting fresh. You can always find previous sessions in your task history.
-</Note>
-
-### Context Window
-
-Every AI model has a context window - a limit on how much information it can process at once. Think of it as Cline's working memory for the current task.
-
-As you work, the context window fills up with:
- Your prompts and Cline's responses
- File contents Cline reads or edits
- Command outputs and tool results
- System instructions that guide Cline's behavior (including [Cline Rules](/customization/cline-rules))
-
-When the context window approaches its limit, Cline automatically compresses older parts of the conversation to make room. This means very long tasks may lose some earlier details, though Cline preserves the most important context.
-
-This is why task scoping matters: a focused task keeps relevant information in the context window. A sprawling task fills the window with noise, pushing out useful context.
-
-If your starting context seems high even for simple prompts, add a [`.clineignore`](/customization/clineignore) file to exclude dependencies, build artifacts, and other files Cline doesn't need. This can dramatically reduce your baseline token usage.
-
-<Tip>
-For long-running tasks, enable [Auto-Compact](/features/auto-compact) to intelligently manage context as you work.
-</Tip>
-
-### New Task vs. Continue
-
-Knowing when to start fresh versus continue can feel unclear at first. As you work with Cline more, you'll develop an intuition for it. Use this table as a starting point:
-
-| Scenario | Action | Why |
-|----------|--------|-----|
-| Switching to a different feature | **New task** | Clean context, focused responses |
-| Building on work Cline just completed | **Continue** | Shared understanding preserved |
-| Cline keeps going off-track | **New task** | Fighting context wastes time |
-| Iterating on the same files | **Continue** | Conversation history helps |
-| Explaining what to ignore | **New task** | Cluttered context hurts quality |
-| Refining Cline's last output | **Continue** | Momentum and decisions preserved |
-
-To start a new task, click the **+** button in the Cline sidebar or use the `/newtask` command. Your file changes are preserved through [checkpoints](/core-workflows/checkpoints), and you can reference previous tasks from history anytime.
-
-## Understanding Task Costs
-
-Every cloud-based AI model charges for usage based on tokens, the units of text the model processes. Cline tracks these costs automatically and displays them in the task header so you can monitor spending as you work.
-
-### How Costs Are Calculated
-
-When you interact with Cline, the model processes:
-
- **Input tokens**: Your prompts, file contents, conversation history, and system instructions
- **Output tokens**: The model's responses, code suggestions, and tool calls
-
-Cloud providers charge per million tokens, with output tokens typically costing more than input. Some providers also support **prompt caching**, which reduces costs when the same context (like your cline rules or large files) appears in multiple requests. Cline automatically tracks cache savings when available.
-
-The estimated cost shown in the task header updates after each API request. This estimate uses the pricing information from your selected provider and may vary slightly from your final bill depending on how your provider rounds or bills usage.
-
-### When You Pay
-
-You pay for AI usage when using cloud providers like Anthropic, OpenAI, OpenRouter, or Google. Costs vary significantly:
-
-| Provider Type | Billing Model |
-|--------------|---------------|
-| **Cline Provider** | Pay-per-use with credits you purchase |
-| **Direct API keys** | Billed by your provider (Anthropic, OpenAI, etc.) |
-| **OpenRouter/Requesty** | Aggregated billing across multiple models |
-| **Local models** | Free (you provide the hardware) |
-
-If you're using your own API keys, check your provider's pricing page for current rates. Prices change frequently and vary by model.
-
-### Free Options
-
-Not ready to pay? Cline offers several free paths:
-
- **Free models**: Search "free" in the model selector when using the Cline provider. These models display a **FREE** tag and work well for learning and experimentation.
- **Free tiers**: Some providers offer limited free usage when you use your own API key.
- **Local models**: Run models on your own hardware with zero per-request costs.
-
-### Self-Hosted Models
-
-Running models locally means no API costs, ever. Your only expense is the hardware to run them.
-
-To run local models effectively, you need:
-
- **32GB RAM minimum** for entry-level models (4-bit quantization)
- **64GB RAM** for better quality (8-bit quantization)
- **128GB+ RAM** for cloud-competitive performance
-
-The trade-off is speed. Local models run at 5-20 tokens per second on typical hardware, compared to hundreds of tokens per second from cloud APIs. They also require more setup and configuration.
-
-<Tip>
-If you have the hardware, local models offer unlimited experimentation with complete privacy. See [Running Models Locally](/running-models-locally/overview) to get started.
-</Tip>
-
-For most users, starting with free cloud models and moving to paid options as needed provides the best balance of cost, speed, and capability. Check [Selecting Your Model](/getting-started/authorizing-with-cline) for guidance on choosing the right option for your workflow.
-
-
-## Task History
-
-Every task you work on is saved automatically to your local machine. You can revisit past conversations, resume interrupted work, or reference successful approaches from earlier sessions.
-
-### Finding Your History
-
-Click the **History** button in the Cline sidebar (clock icon at the top-right) to open the history view. You'll see all your past tasks with their initial prompt, timestamp, and token usage. Each task card expands to show a preview of the conversation.
-
-### Searching Tasks
-
-Use the search bar at the top of the history view to find specific tasks. The fuzzy search looks across everything: your prompts, Cline's responses, code snippets, and file names. 
-
-Sort results by:
- **Newest/Oldest** for chronological browsing
- **Most Expensive/Most Tokens** to find resource-heavy tasks
- **Most Relevant** when searching for specific content
- **Favorites** to show only starred tasks
-
-<Tip>
-Use favorites strategically. Star tasks that represent successful patterns, good prompts, or complex work you might want to reference later. Favorited tasks are protected from deletion.
-</Tip>
-
-## Resuming Tasks
-
-Cline can resume interrupted tasks with full context:
-
-1. Open the task from history
-2. Cline loads the complete conversation
-3. File states are checked against [checkpoints](/core-workflows/checkpoints)
-4. The task continues with awareness of the interruption
-5. Provide additional context if needed
-
-This works across sessions. Even if you close the editor and return days later, Cline can pick up where you left off.
@@ -1,75 +0,0 @@
---
-title: "Using Commands"
-sidebarTitle: "Using Commands"
-description: "Built-in slash commands to manage context, plan implementations, and create reusable workflows."
---
-
-Cline provides slash commands in chat that help you manage your conversation and plan complex implementations.
-
-<Tip>
-**New to slash commands?** Watch our [quick video walkthrough](https://youtu.be/MxS5Jerpf-o) to see these commands in action.
-</Tip>
-
-## Slash Commands
-
-Type `/` in the chat input to see available slash commands:
-
-| Command | What It Does |
-|---------|--------------|
-| `/newtask` | Start fresh task with distilled context from current conversation |
-| `/smol` | Compress conversation history while preserving essential context |
-| `/newrule` | Create a rule file to teach Cline your preferences |
-| `/deep-planning` | Investigate codebase, plan thoroughly, then create implementation task |
-| `/explain-changes` | Generate AI explanations for any git diff (VS Code only) |
-| `/reportbug` | Report a bug with diagnostic info |
-
-### /newtask
-
-`/newtask` works like a developer handoff. It packages what matters (overall plan, work accomplished, relevant files, next steps) into a fresh task with a clean context window, leaving behind the noise of tool calls and implementation details.
-
-I use `/newtask` when working through complex implementations. If I've completed 3 steps of a 10-step process and my context is already 75% full, I use `/newtask` to extract key decisions, file changes, and progress without all the noise.
-
-### /smol
-
-`/smol` (or its alias `/compact`) compresses your conversation history while preserving essential context. Unlike `/newtask` which creates a new task, `/smol` condenses your current conversation into a comprehensive summary, freeing up context window space while allowing you to continue working in the same task.
-
-Use `/smol` when you're deep into a debugging session or brainstorming and need to continue in the same task without losing the insights you've gained. For more details, see [Smol Command](#smol).
-
-### /newrule
-
-`/newrule` creates a rule file that teaches Cline your preferences. Cline will guide you through setting up guidelines for communication style, coding standards, project context, and workflows. The rule is saved to your `.clinerules` directory and automatically loaded for future conversations.
-
-Use `/newrule` when you find yourself repeating the same instructions across tasks. For more about rules, see [Cline Rules](/customization/cline-rules).
-
-### /deep-planning
-
-Transform Cline into a meticulous architect who investigates your codebase, asks clarifying questions, and creates a comprehensive implementation plan before writing any code. Deep planning follows a four-step process:
-
-1. **Silent Investigation** - Cline explores your codebase structure and patterns
-2. **Discussion** - Targeted questions about requirements and approach
-3. **Plan Creation** - Generates `implementation_plan.md` with detailed specifications
-4. **Task Creation** - Creates a new task with trackable implementation steps
-
-Use `/deep-planning` for features touching multiple parts of your codebase, architectural changes, or complex integrations. For detailed documentation, see [Deep Planning](/features/deep-planning).
-
-### /explain-changes
-
-<Note>
-This command is only available in VS Code.
-</Note>
-
-`/explain-changes` generates AI-powered explanations for any git diff. You can explain the last commit, uncommitted work, staged changes, specific commits, branches, PRs, or any range of changes.
-
-Use `/explain-changes` when reviewing code, onboarding to a new codebase, or understanding what changed. For the full list of use cases and examples, see [Explain Changes Command](#explain-changes).
-
-### /reportbug
-
-`/reportbug` collects diagnostic information and helps you report issues with Cline. It gathers relevant context like your configuration, recent errors, and system details to make bug reports more useful for the development team.
-
-Use `/reportbug` when you encounter unexpected behavior, crashes, or bugs you want to report.
-
-## Custom Workflows
-
-Beyond the built-in slash commands, you can create your own workflow files that work the same way. Store Markdown files in `.clinerules/workflows/` and invoke them with `/your-workflow.md`.
-
-For a complete guide on creating and managing custom workflows, see [Workflows](/customization/workflows).
@@ -1,145 +0,0 @@
---
-title: "Adding Context"
-sidebarTitle: "Adding Context"
-description: "Use @ mentions and drag & drop to bring files, terminal output, errors, git changes, and web content into your conversations."
---
-
-Cline works best when it has the right context, not just more context. @ mentions let you pull in exactly the files, errors, terminal output, or documentation that matter for your task. No copying, no pasting, no context switching.
-
-You can add context two ways:
- Type `@` in the chat input and select what you want
- Click the **+** button in the bottom left to browse files, images, or mentions
-
-<Tip>
-**Want to learn more about managing context?** Watch [Adding Context with @ Mentions](https://youtu.be/7j6R75Dvj1Y) to see it in action.
-</Tip>
-
-## Quick Reference
-
-| What you want | Syntax | Example |
-|---------------|--------|---------|
-| File content | `@/path/to/file` | `@/src/index.ts` |
-| Folder contents | `@/path/to/folder/` | `@/src/components/` |
-| Workspace errors | `@problems` | `@problems` |
-| Terminal output | `@terminal` | `@terminal` |
-| Uncommitted changes | `@git-changes` | `@git-changes` |
-| Specific commit | `@<commit-hash>` | `@a1b2c3d` |
-| Web page | `@<url>` | `@https://react.dev/learn` |
-
-## File Mentions
-
-Reference any file with `@/path/to/file`. Cline sees the complete file content, including imports, related functions, and surrounding context.
-
-```text
-Can you refactor the error handling in @/src/api/users.ts?
-```
-
-## Folder Mentions
-
-Reference entire directories with `@/path/to/folder/` (note the trailing slash). Cline sees the folder structure and all file contents.
-
-```text
-Explain how the components in @/src/components/auth/ work together.
-```
-
-<Note>
-In multi-root workspaces, prefix paths with the workspace name: `@workspace-name:/path/to/file`
-</Note>
-
-## Problem Mentions
-
-Use `@problems` to share all errors and warnings from your workspace's Problems panel.
-
-```text
-@problems Can you fix these TypeScript errors?
-```
-
-## Terminal Mentions
-
-Use `@terminal` to share recent terminal output. Perfect for debugging build errors or test failures.
-
-```text
-@terminal The build is failing. What's wrong?
-```
-
-## Git Mentions
-
-Reference uncommitted changes with `@git-changes`:
-
-```text
-@git-changes Review my changes before I commit.
-```
-
-Reference specific commits with `@<commit-hash>` (7-40 character hex):
-
-```text
-What did @a1b2c3d change?
-```
-
-## URL Mentions
-
-Reference web content with `@https://example.com`. Cline fetches the page content.
-
-```text
-Implement the pattern described in @https://react.dev/learn/scaling-up-with-reducer-and-context
-```
-
-## Combining Mentions
-
-Combine multiple @ mentions for comprehensive context:
-
-```text
-I'm getting these errors: @problems
-
-Here's my component: @/src/components/Form.jsx
-And the API endpoint: @/src/api/users.js
-
-The error happens when I submit: @terminal
-
-I think this commit might have caused it: @a1b2c3d
-```
-
-## Drag & Drop
-
-Drag files directly into the chat input to add them to your conversation.
-
-<Note>
-In VS Code, hold **Shift** while dragging files into the chat input.
-</Note>
-
-Dragging workspace files automatically creates file mentions. You can also drag files from Finder or File Explorer directly into Cline.
-
-### Supported File Types
-
-Cline supports text files from your workspace, plus images, PDFs, CSVs, and Excel files from your file system.
-
-<Note>
-Images require a multimodal model. Check the model selector to see which models support image inputs.
-</Note>
-
-## Context Menu Commands
-
-Right-click on selected code to access Cline without typing. This is the fastest way to get help with specific code since it automatically includes the selected text and its file location as context.
-
-### Code Editor Commands
-
-| Command | When to Use |
-|---------|-------------|
-| **Add to Cline** | Ask questions about code, get suggestions, or start a conversation with specific code as context |
-| **Fix with Cline** | Quick fixes for errors, bugs, or issues in the selected code |
-| **Explain with Cline** | Understand unfamiliar code, complex logic, or code you're reviewing |
-| **Improve with Cline** | Get refactoring suggestions, performance improvements, or cleaner implementations |
-
-**Fix with Cline** also appears in the lightbulb menu (Quick Fix) when your cursor is on an error or warning, making it easy to fix issues inline.
-
-### Terminal Commands
-
-Right-click in the terminal to "Add to Cline" and get help with:
- Build errors and failed commands
- Test failures and stack traces
- Configuration issues
- Any terminal output you need help interpreting
-
-### Source Control Commands
-
-In the Source Control panel, use "Generate Commit Message" to create AI-powered commit messages from your staged changes. Cline analyzes the diff and writes a descriptive commit message following conventional commit patterns.
@@ -1,396 +0,0 @@
---
-title: "Rules"
-sidebarTitle: "Rules"
-description: "Define specific instructions and coding standards for Cline."
---
-
-Rules are markdown files that provide persistent instructions across all conversations. Instead of repeating the same preferences every time you start a new task, rules let you define them once and have Cline follow them automatically.
-
-Use rules when you want Cline to:
- Follow your team's coding standards (naming conventions, file organization, error handling patterns)
- Understand project-specific context (tech stack, architecture decisions, dependencies)
- Apply consistent documentation or testing requirements
- Remember constraints like "don't modify files in /legacy" or "always use TypeScript"
-
-<Tip>
-  **New to Rules?** Watch [Cline Rules Explained](https://youtu.be/xQwsy2vkK5M) to see them in action.
-</Tip>
-
-
-## Supported Rule Types
-
-Cline recognizes rules from multiple sources, so you can use existing rule files from other tools:
-
-| Rule Type | Location | Description |
-|-----------|----------|-------------|
-| Cline Rules | `.clinerules/` | Primary rule format |
-| Cursor Rules | `.cursorrules` | Automatically detected |
-| Windsurf Rules | `.windsurfrules` | Automatically detected |
-| AGENTS.md | `AGENTS.md` | [Standard format](https://agents.md/) for cross-tool compatibility |
-
-All detected rule types appear in the Rules panel, where you can toggle them individually.
-
-
-## Where Rules Live
-
-Rules can be stored in two locations: your project workspace or globally on your system.
-
-**Workspace rules** go in `.clinerules/` at your project root. Use these for team standards, project-specific constraints, and anything you want to share with collaborators via version control.
-
-**Global rules** go in your system's Cline Rules directory. Use these for personal preferences that apply across all projects.
-
-```text
-your-project/
-├── .clinerules/              # Workspace rules
-│   ├── coding.md             # Coding standards
-│   ├── testing.md            # Test requirements
-│   └── architecture.md       # Structural decisions
-├── src/
-└── ...
-```
-
-Cline processes all `.md` and `.txt` files inside `.clinerules/`, combining them into a unified set of rules. Numeric prefixes (like `01-coding.md`) help organize files but are optional.
-
-When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules. See [Storage Locations](/customization/overview#storage-locations) for more guidance.
-
-### Global Rules Directory
-
-| Operating System | Default Location |
-|------------------|------------------|
-| Windows | `Documents\Cline\Rules` |
-| macOS | `~/Documents/Cline/Rules` |
-| Linux/WSL | `~/Documents/Cline/Rules` |
-
-<Note>
-Linux/WSL users: If you don't find global rules in `~/Documents/Cline/Rules`, check `~/Cline/Rules`.
-</Note>
-
-
-## Creating Rules
-
-<Steps>
-  <Step title="Open the Rules menu">
-    Click the scale icon at the bottom of the Cline panel, to the left of the model selector.
-  </Step>
-  <Step title="Create a new rule file">
-    Click "New rule file..." and enter a filename (e.g., `coding-standards`). The file will be created with a `.md` extension.
-  </Step>
-  <Step title="Write your rule">
-    Add your instructions in markdown format. Keep each rule file focused on a single concern.
-  </Step>
-</Steps>
-
-You can also use the [`/newrule` slash command](/core-workflows/using-commands#newrule) to have Cline create a rule interactively.
-
-### Toggling Rules
-
-Every rule has a toggle to enable or disable it. This gives you fine-grained control over which rules apply to your current task without deleting the rule file.
-
-For example, you might have a strict testing rule that you want to disable when prototyping, or a client-specific rule you only need when working on that client's features.
-
-## Writing Effective Rules
-
-### Structure
-
-Rules work best when they're scannable and specific. Use markdown structure to organize instructions:
-
-```markdown
-# Rule Title
-
-Brief context about why this rule exists (optional but helpful).
-
-## Category 1
- Specific instruction
- Another instruction with example: `like this`
- Reference to file: see /src/utils/example.ts
-
-## Category 2
- More instructions
- Include the "why" when it's not obvious
-```
-
-Cline reads rules as context, so formatting matters. Headers help Cline understand the scope of each instruction. Bullet points make individual requirements clear. Code examples show exactly what you want.
-
-### Best Practices
-
-**Be specific, not vague.** "Use descriptive variable names" is too broad. "Use camelCase for variables, PascalCase for classes, UPPER_SNAKE for constants" gives Cline something concrete to follow.
-
-**Include the why.** When a rule might seem arbitrary, explain the reason. "Don't modify files in /legacy (this code is scheduled for removal in Q2)" helps Cline make better decisions in edge cases.
-
-**Point to examples.** If your codebase already demonstrates the pattern you want, reference it. "Follow the error handling pattern in /src/utils/errors.ts" is more effective than describing the pattern from scratch.
-
-**Keep rules current.** Outdated rules confuse Cline and waste context. If a constraint no longer applies, remove it. If your tech stack changes, update the rules.
-
-**One concern per file.** Split rules by topic: `coding.md` for style, `testing.md` for test requirements, `architecture.md` for structural decisions. This makes it easy to toggle specific rules on or off.
-
-<Warning>
-Rules consume context tokens. Avoid lengthy explanations or pasting entire style guides. Keep rules concise and link to external documentation when detailed reference is needed.
-</Warning>
-
-## Example
-
-```markdown
-# Project Guidelines
-
-## Code Style
- Use TypeScript for all new files
- Prefer composition over inheritance
- Use repository pattern for data access
- Follow error handling pattern in /src/utils/errors.ts
-
-## Documentation
- Update relevant docs when modifying features
- Keep README.md in sync with new capabilities
-
-## Testing
- Unit tests required for business logic
- Integration tests for API endpoints
- E2E tests for critical user flows
-```
-
-
-## Conditional Rules
-
-Conditional rules let you scope rules to specific parts of your codebase. Rules activate only when you're working with matching files, keeping your context focused and relevant.
-
- **Without conditionals**: every rule loads for every request.
- **With conditionals**, rules activate only when your current files match their defined scope.
-
-For example, documentation style rules should only appear when you're editing docs, not when you're writing application code or tests.
-
-As your rule library grows, loading every rule for every request wastes context tokens and can dilute Cline's focus. Conditional rules solve this by giving Cline only the instructions that matter for the files you're actually touching. This means faster, more accurate responses. Your frontend rules won't compete for attention when you're deep in backend code, and your testing standards appear exactly when you're writing tests. It's the difference between handing someone an entire policy manual versus the one page they need right now.
-
-### How It Works
-
-Conditional rules use YAML frontmatter at the top of your rule files. When Cline processes a request, it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule's conditions, and activates matching rules.
-
-<Note>
-When a conditional rule activates, you'll see a notification: **"Conditional rules applied: workspace:frontend-rules.md"**
-</Note>
-
-### Writing Conditional Rules
-
-Add YAML frontmatter to the top of any rule file in your `.clinerules/` directory:
-
-```yaml
---
-paths:
-  - "src/components/**"
-  - "src/hooks/**"
---
-
-# React Component Guidelines
-
-When creating or modifying React components:
- Use functional components with React hooks
- Extract reusable logic into custom React hooks
- Keep components focused on a single responsibility
-```
-
-The `---` markers delimit the frontmatter. Everything after the closing `---` is your rule content.
-
-#### The `paths` Conditional
-
-Currently, `paths` is the supported conditional. It takes an array of glob patterns:
-
-```yaml
---
-paths:
-  - "src/**"           # All files under src/
-  - "*.config.js"      # Config files in root
-  - "packages/*/src/"  # Monorepo package sources
---
-```
-
-**Glob pattern syntax:**
-
- `*` matches any characters except `/`
- `**` matches any characters including `/` (recursive)
- `?` matches a single character
- `[abc]` matches any character in the brackets
- `{a,b}` matches either pattern
-
-| Pattern | Matches |
-|---------|---------|
-| `src/**/*.ts` | All TypeScript files under `src/` |
-| `*.md` | Markdown files in root only |
-| `**/*.test.ts` | Test files anywhere in the project |
-| `packages/{web,api}/**` | Files in web or api packages |
-| `src/components/*.tsx` | TSX files directly in components (not nested) |
-
-#### Behavior Details
-
-**Multiple patterns**: A rule activates if any pattern matches any file in your context.
-
-```yaml
---
-paths:
-  - "frontend/**"
-  - "mobile/**"
---
-# Activates when working in frontend OR mobile
-```
-
-**No frontmatter**: Rules without frontmatter are always active.
-
-**Empty paths array**: `paths: []` means the rule never activates. Use this to temporarily disable a rule.
-
-**Invalid YAML**: If frontmatter can't be parsed, Cline fails open. The rule activates with raw content visible to help debugging.
-
-### What Counts as "Current Context"
-
-Cline evaluates rules based on:
-
-1. **Your message**: File paths mentioned in your prompt (e.g., "update `src/App.tsx`")
-2. **Open tabs**: Files currently open in your editor
-3. **Visible files**: Files visible in your active editor panes
-4. **Edited files**: Files Cline has created, modified, or deleted during the task
-5. **Pending operations**: Files Cline is about to edit
-
-Conditional rules can activate on your first message, when relevant files are open, or mid-task when Cline starts working with matching files.
-
-<Tip>
-Be explicit about file paths in your prompts. "Update `src/services/user.ts`" reliably triggers path-based rules; "update the user service" may not.
-</Tip>
-
-### Practical Examples
-
-Copy these patterns and adapt them to your project structure.
-
-#### Frontend vs Backend Rules
-
-Keep frontend and backend rules separate to avoid noise. Frontend rules only load when working with UI code, backend rules only load when working with API or service code.
-
-```yaml
-# .clinerules/frontend.md
---
-paths:
-  - "src/components/**"
-  - "src/pages/**"
-  - "src/hooks/**"
---
-
-# Frontend Guidelines
-
- Use Tailwind CSS for styling
- Prefer server components where possible
- Keep client components small and focused
-```
-
-```yaml
-# .clinerules/backend.md
---
-paths:
-  - "src/api/**"
-  - "src/services/**"
-  - "src/db/**"
---
-
-# Backend Guidelines
-
- Use dependency injection for services
- All database queries go through repositories
- Return typed errors, not thrown exceptions
-```
-
-#### Test File Rules
-
-Enforce testing standards automatically. This rule activates only when you're writing or modifying tests, so testing guidance appears exactly when you need it.
-
-```yaml
-# .clinerules/testing.md
---
-paths:
-  - "**/*.test.ts"
-  - "**/*.spec.ts"
-  - "**/__tests__/**"
---
-
-# Testing Standards
-
- Use descriptive test names: "should [expected behavior] when [condition]"
- One assertion per test when possible
- Mock external dependencies, not internal modules
- Use factories for test data, not fixtures
-```
-
-#### Documentation Rules
-
-Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you're writing code.
-
-```yaml
-# .clinerules/docs.md
---
-paths:
-  - "docs/**"
-  - "**/*.md"
-  - "**/*.mdx"
---
-
-# Documentation Guidelines
-
- Use sentence case for headings
- Include code examples for all features
- Keep paragraphs short (3-4 sentences max)
- Link to related documentation
-```
-
-### Combining with Rule Toggles
-
-Conditional rules work alongside the rule toggle UI. Toggle off a conditional rule to disable it entirely (it won't activate even if paths match). Toggle on to let it activate when conditions are met.
-
-This provides two levels of control: manual toggles and automatic condition-based activation.
-
-### Tips for Effective Conditional Rules
-
-**Start Broad, Then Narrow.** Begin with broader patterns and refine as you learn what works:
-
-```yaml
-# Start here
-paths:
-  - "src/**"
-
-# Then narrow down
-paths:
-  - "src/features/auth/**"
-```
-
-**Use Descriptive Filenames.** Name your rule files to indicate their scope:
-
-```text
-.clinerules/
-├── api-endpoints.md      # Rules for API code
-├── database-models.md    # Rules for DB layer
-├── react-components.md   # Rules for React
-└── universal.md          # No frontmatter = always active
-```
-
-**Keep Universal Rules Separate.** Put always-on rules (coding standards, project conventions) in files without frontmatter. Reserve conditional rules for context-specific guidance.
-
-**Test Your Patterns.** Not sure if a pattern matches? Create a simple test rule:
-
-```yaml
---
-paths:
-  - "your/pattern/here/**"
---
-TEST: This rule should activate for your/pattern/here files.
-```
-
-Then work with a file in that path and check if you see the activation notification.
-
-### Troubleshooting Conditional Rules
-
-**Rule not activating:**
- Check that file paths in your context match the glob pattern
- Verify the rule is toggled on in the rules panel
- Ensure YAML frontmatter has proper `---` delimiters
-
-**Rule activating unexpectedly:**
- Review glob patterns. `**` is recursive and may match more than intended
- Check for open files that match the pattern
- File paths mentioned in your message also count as context
-
-**Frontmatter showing in output:**
- YAML couldn't be parsed
- Check for syntax errors (unquoted special characters, improper indentation)
@@ -1,110 +0,0 @@
---
-title: ".clineignore"
-sidebarTitle: ".clineignore"
-description: "Control which files and directories Cline can access in your project."
---
-
-The `.clineignore` file tells Cline which files and directories to skip when analyzing your codebase. It works like `.gitignore`: create a file named `.clineignore` in your project root, add patterns for files you want excluded, and Cline will ignore them.
-
-## Why It Matters
-
-Without a `.clineignore`, Cline may load your entire project into context, including dependencies, build artifacts, and generated files. This wastes tokens, increases costs, and can push useful context out of the window.
-
-Adding a `.clineignore` can cut your starting context from 200k+ tokens to under 50k. That means faster responses, lower costs, and the ability to use smaller, cheaper models effectively.
-
-## Creating a .clineignore
-
-Create a file named `.clineignore` in your project root:
-
-```text
-# Dependencies
-node_modules/
-**/node_modules/
-
-# Build outputs
-/build/
-/dist/
-/.next/
-/out/
-
-# Testing artifacts
-/coverage/
-
-# Environment variables
-.env
-.env.*
-
-# Large data files
-*.csv
-*.xlsx
-*.sqlite
-
-# Generated/minified code
-*.min.js
-*.map
-```
-
-## Pattern Syntax
-
-`.clineignore` uses the same pattern syntax as `.gitignore`:
-
-| Pattern | Matches |
-|---------|---------|
-| `node_modules/` | The `node_modules` directory |
-| `**/node_modules/` | `node_modules` at any depth |
-| `*.csv` | All CSV files |
-| `/build/` | The `build` directory at the project root only |
-| `*.env.*` | Files like `.env.local`, `.env.production` |
-| `!important.csv` | Exception: do not ignore this file |
-
-Lines starting with `#` are comments. Blank lines are ignored.
-
-## What to Exclude
-
-Start with these categories and adjust for your project:
-
-**Almost always exclude:**
- Package manager directories (`node_modules/`, `vendor/`, `.venv/`)
- Build outputs (`dist/`, `build/`, `.next/`, `out/`)
- Coverage reports (`coverage/`)
- Lock files if large (`package-lock.json`, `yarn.lock`)
-
-**Exclude if present:**
- Large data files (`.csv`, `.xlsx`, `.sqlite`, `.parquet`)
- Binary assets (images, fonts, videos)
- Generated code (API clients, protobuf outputs, minified bundles)
- Environment files with secrets (`.env`, `.env.local`)
-
-**Keep accessible:**
- Source code you actively work on
- Configuration files Cline needs to understand (`tsconfig.json`, `package.json`)
- Documentation and READMEs
- Test files (Cline often needs these for context)
-
-## How It Works
-
-When Cline scans your project to build context, it checks each file path against your `.clineignore` patterns. Matching files are excluded from:
-
- The file listing Cline sees when starting a task
- Automatic context gathering during conversations
- Search results when Cline looks for relevant code
-
-You can still reference ignored files explicitly using [@ mentions](/core-workflows/working-with-files). If you type `@/node_modules/some-package/index.js`, Cline will read that specific file even though `node_modules/` is in your `.clineignore`. The ignore rules control automatic loading, not explicit access.
-
-<Note>
-`.clineignore` is separate from `.gitignore`. Files tracked by Git but irrelevant to Cline (like large test fixtures or data files) should go in `.clineignore` even if they're not in `.gitignore`.
-</Note>
-
-## Tips
-
- Add `.clineignore` early in your project. It's easier to start with broad exclusions and narrow them than to debug why context is bloated later.
- Check your token usage in the task header after adding a `.clineignore`. The difference is often dramatic.
- If Cline seems to be missing context about a file, check whether it's being excluded by your ignore patterns.
- For monorepos or multi-root workspaces, each workspace root can have its own `.clineignore`. See [Multi-Root Workspaces](/features/multiroot-workspace) for details.
-
-## Related
-
- [Cline Rules](/customization/cline-rules) - Define persistent instructions for Cline
- [Task Management](/core-workflows/task-management#context-window) - Understand how context windows work
- [Auto-Compact](/features/auto-compact) - Automatic context compression during long tasks
- [Memory Bank](/features/memory-bank) - Structured documentation for cross-session context
@@ -1,470 +0,0 @@
---
-title: "Hooks"
-sidebarTitle: "Hooks"
-description: "Inject custom logic into Cline's workflow to validate operations and shape Cline's decisions."
---
-
-Hooks are scripts that run at key moments in Cline's workflow. Because they execute at known points with consistent inputs and outputs, hooks bring determinism to the non-deterministic nature of AI models by enforcing guardrails, validations, and context injection. You can validate operations before they execute, monitor tool usage, and shape how Cline makes decisions.
-
-## What You Can Build
-
- Stop operations before they cause problems (like creating `.js` files in a TypeScript project)
- Run linters or custom validators before files get saved
- Prevent operations that violate security policies
- Track everything for analytics or compliance
- Trigger external tools or services at the right moments
- Add context to the conversation based on what Cline is doing
-
-## Hook Types
-
-Cline supports 8 hook types that run at different points in the task lifecycle:
-
-| Hook Type | When It Runs | 
-|-----------|--------------|
-| TaskStart | When you start a new task |
-| TaskResume | When you resume an interrupted task |
-| TaskCancel | When you cancel a running task |
-| TaskComplete | When a task finishes successfully |
-| PreToolUse | Before Cline executes a tool (read_file, write_to_file, etc.) |
-| PostToolUse | After a tool execution completes |
-| UserPromptSubmit | When you submit a message to Cline |
-| PreCompact | Before Cline truncates conversation history to free up context |
-
-## Hook Lifecycle
-
-```mermaid
-flowchart TD
-    %% Styling
-    classDef hook fill:#FFB74D,stroke:#E65100,stroke-width:2px,color:black,rx:5,ry:5;
-    classDef state fill:#E1F5FE,stroke:#0277BD,stroke-width:2px,color:black;
-    classDef action fill:#FFFFFF,stroke:#333,stroke-width:1px,color:black,stroke-dasharray: 5 5;
-
-    %% Entry Points
-    Start((Start)) --> CheckType{New or<br/>Resume?}
-    
-    %% Initialization Hooks
-    CheckType -- New Task --> H_Start[TaskStart]:::hook
-    CheckType -- Resume --> H_Resume[TaskResume]:::hook
-    
-    %% Main Loop
-    H_Start --> Loop(Task Active Loop):::state
-    H_Resume --> Loop
-
-    subgraph Conversation Cycle
-        direction TB
-        Loop -- User sends message --> H_Submit[UserPromptSubmit]:::hook
-        H_Submit --> Thinking[Cline Processes Context]:::state
-        
-        %% Context Compaction Path
-        Thinking -. Context Limit Reached .-> H_Compact[PreCompact]:::hook
-        H_Compact -.-> Thinking
-        
-        %% Tool Execution Path
-        Thinking -- Decides to use tool --> H_PreTool[PreToolUse]:::hook
-        H_PreTool -- Allowed --> ToolExec[Tool Executes]:::action
-        H_PreTool -- Cancelled --> Thinking
-        ToolExec --> H_PostTool[PostToolUse]:::hook
-        H_PostTool --> Thinking
-    end
-
-    %% Termination Paths
-    Thinking -- Task Successfully Finished --> H_Complete[TaskComplete]:::hook
-    Loop -- User Cancels Task --> H_Cancel[TaskCancel]:::hook
-    
-    %% End
-    H_Complete --> End((End))
-    H_Cancel --> End
-```
-
-The diagram shows the complete hook lifecycle:
-
-1. **Entry**: When you start a task, either **TaskStart** (new task) or **TaskResume** (interrupted task) runs first
-2. **Conversation Cycle**: Each time you send a message, **UserPromptSubmit** runs, then Cline processes your request
-3. **Tool Execution**: When Cline decides to use a tool, **PreToolUse** runs first-if allowed, the tool executes, then **PostToolUse** runs
-4. **Context Management**: If the conversation approaches context limits, **PreCompact** runs before truncation
-5. **Exit**: The task ends with either **TaskComplete** (success) or **TaskCancel** (user cancellation)
-
-Orange nodes represent hooks where you can inject custom logic. The cycle repeats as you continue the conversation.
-
-## Hook Locations
-
-Hooks can be stored globally or in a project workspace. See [Storage Locations](/customization/overview#storage-locations) for guidance on when to use each.
-
- **Global hooks**: `~/Documents/Cline/Hooks/`
- **Project hooks**: `.clinerules/hooks/` in your repo (can be committed to version control)
-
-When both global and workspace hooks exist for the same hook type, both run. Global hooks execute first, then workspace hooks. If either returns `cancel: true`, the operation stops.
-
-## Creating a Hook
-
-<Steps>
-  <Step title="Open the Hooks tab">
-    Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Hooks tab.
-  </Step>
-  <Step title="Create a new hook">
-    Click **"New hook..."** dropdown and select a hook type (e.g., PreToolUse, TaskStart).
-  </Step>
-  <Step title="Review the hook's code">
-    Click the pencil icon to open and edit the hook script. Cline generates a template with examples.
-  </Step>
-  <Step title="Enable the hook">
-    Toggle the switch to activate the hook once you understand what it does.
-  </Step>
-</Steps>
-
-<Warning>
-Always review a hook's code before enabling it. Hooks execute automatically during your workflow and can block operations or run shell commands.
-</Warning>
-
-## Quick Start: Your First Hook
-
-Let's create a simple hook that logs every file Cline reads or writes. You'll see results in seconds.
-
-### The Hook
-
-Create a file called `file-logger` in your hooks directory with this content:
-
-```bash
-#!/bin/bash
-# Logs all file operations to ~/cline-activity.log
-
-INPUT=$(cat)
-TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
-FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // "N/A"')
-
-# Log to file
-echo "$(date '+%H:%M:%S') - $TOOL: $FILE_PATH" >> ~/cline-activity.log
-
-# Always allow the operation
-echo '{"cancel":false}'
-```
-
-### Setup
-
-<Steps>
-  <Step title="Create the hook file">
-    Save the script above as `~/Documents/Cline/Hooks/file-logger` (macOS/Linux) or create it through the Hooks UI.
-  </Step>
-  <Step title="Make it executable">
-    Run `chmod +x ~/Documents/Cline/Hooks/file-logger` in your terminal.
-  </Step>
-  <Step title="Enable it">
-    In Cline's Hooks tab, find "file-logger" under PreToolUse hooks and toggle it on.
-  </Step>
-</Steps>
-
-### Test It
-
-Ask Cline to read any file in your project: "What's in package.json?"
-
-Then check the log:
-
-```bash
-cat ~/cline-activity.log
-```
-
-You'll see entries like:
-```text
-14:23:45 - read_file: /path/to/package.json
-14:23:47 - search_files: /path/to/src
-```
-
-### Customize It
-
-Try modifying the hook to:
- Filter specific file types (only log `.ts` files)
- Add the task ID to each log entry
- Send notifications for write operations
- Block operations on certain paths
-
-The sections below explain how hooks receive input and return output, plus more examples.
-
-## How Hooks Work
-
-Hooks are executable scripts that receive JSON input via stdin and return JSON output via stdout.
-
-### Input Structure
-
-Every hook receives a JSON object with common fields plus hook-specific data:
-
-```json
-{
-  "taskId": "abc123",
-  "clineVersion": "3.17.0",
-  "timestamp": 1736654400000,
-  "workspacePath": "/path/to/project",
-  
-  // Hook-specific field (name matches hook type in camelCase)
-  "taskStart": {
-    "task": "Add authentication to the API"
-  }
-}
-```
-
-The hook-specific field name matches the hook type:
- `taskStart`, `taskResume`, `taskCancel`, `taskComplete` contain `{ task: string }`
- `preToolUse` contains `{ tool: string, parameters: object }`
- `postToolUse` contains `{ tool: string, parameters: object, result: string, success: boolean, durationMs: number }`
- `userPromptSubmit` contains `{ prompt: string }`
- `preCompact` contains `{ conversationLength: number, estimatedTokens: number }`
-
-### Output Structure
-
-Hooks return a JSON object to stdout:
-
-```json
-{
-  "cancel": false,
-  "contextModification": "Optional text to add to the conversation",
-  "errorMessage": ""
-}
-```
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `cancel` | boolean | If `true`, stops the operation (blocks the tool, cancels the task start, etc.) |
-| `contextModification` | string | Optional text that gets injected into the conversation as context for Cline |
-| `errorMessage` | string | Shown to the user if `cancel` is `true` |
-
-### Context Modification
-
-The `contextModification` field lets hooks inject information into the conversation. This is useful for:
-
- Adding project-specific context when a task starts
- Providing validation results that Cline should consider
- Injecting environment information before tool execution
-
-For example, a PreToolUse hook could add: `"Note: This file is auto-generated. Edits may be overwritten."`
-
-## Hook Reference
-
-### Task Lifecycle Hooks
-
-#### TaskStart
-
-Runs when you start a new task. Use it to:
- Log task start time for analytics
- Add project context to the conversation
- Check prerequisites before work begins
- Notify external systems (Slack, issue trackers)
-
-```bash
-#!/bin/bash
-INPUT=$(cat)
-TASK=$(echo "$INPUT" | jq -r '.taskStart.task')
-echo "[TaskStart] Starting: $TASK" >&2
-echo '{"cancel":false,"contextModification":"","errorMessage":""}'
-```
-
-#### TaskResume
-
-Runs when you resume an interrupted task (instead of TaskStart). Use it to:
- Check for changes since the task was paused
- Refresh context with latest project state
- Notify that work is resuming
-
-#### TaskCancel
-
-Runs when you cancel a running task. Use it to:
- Clean up temporary files or resources
- Notify external systems about cancellation
- Log cancellation for analytics
-
-#### TaskComplete
-
-Runs when a task completes successfully. Use it to:
- Run tests or validation after changes
- Generate reports or summaries
- Notify stakeholders
- Trigger CI/CD pipelines
-
-### Tool Hooks
-
-#### PreToolUse
-
-Runs before any tool executes. This is the most powerful hook for validation and safety. Use it to:
- Block dangerous operations
- Validate parameters before execution
- Add context about the file or resource being accessed
- Log tool usage
-
-The input includes the tool name and its parameters:
-
-```json
-{
-  "preToolUse": {
-    "tool": "write_to_file",
-    "parameters": {
-      "path": "src/config.ts",
-      "content": "..."
-    }
-  }
-}
-```
-
-Example that blocks `.js` files in a TypeScript project:
-
-```bash
-#!/bin/bash
-INPUT=$(cat)
-TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
-FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')
-
-if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
-  echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
-  exit 0
-fi
-
-echo '{"cancel":false}'
-```
-
-#### PostToolUse
-
-Runs after a tool completes (success or failure). Use it to:
- Audit tool usage
- Validate results
- Trigger follow-up actions
- Monitor performance
-
-The input includes execution results:
-
-```json
-{
-  "postToolUse": {
-    "tool": "execute_command",
-    "parameters": { "command": "npm test" },
-    "result": "All tests passed",
-    "success": true,
-    "durationMs": 3450
-  }
-}
-```
-
-<Note>
-PostToolUse hooks can return `cancel: true` to stop the task, but they cannot undo the tool execution that already happened.
-</Note>
-
-### Other Hooks
-
-#### UserPromptSubmit
-
-Runs when you send a message to Cline. Use it to:
- Log prompts for analytics
- Add context based on prompt content
- Validate or sanitize prompts
-
-#### PreCompact
-
-Runs before Cline truncates conversation history to stay within context limits. Use it to:
- Archive important conversation parts before they're removed
- Log compaction events
- Add a summary of what's being removed
-
-The input includes context metrics:
-
-```json
-{
-  "preCompact": {
-    "conversationLength": 45,
-    "estimatedTokens": 125000
-  }
-}
-```
-
-## Examples
-
-### TypeScript Enforcement
-
-Block creation of `.js` files in a TypeScript project:
-
-```bash
-#!/bin/bash
-# PreToolUse hook
-
-INPUT=$(cat)
-TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
-FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')
-
-if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
-  echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
-  exit 0
-fi
-
-echo '{"cancel":false}'
-```
-
-### Tool Usage Logging
-
-Log all tool executions to a file:
-
-```bash
-#!/bin/bash
-# PostToolUse hook
-
-INPUT=$(cat)
-TOOL=$(echo "$INPUT" | jq -r '.postToolUse.tool')
-SUCCESS=$(echo "$INPUT" | jq -r '.postToolUse.success')
-DURATION=$(echo "$INPUT" | jq -r '.postToolUse.durationMs')
-
-echo "$(date -Iseconds) | $TOOL | success=$SUCCESS | ${DURATION}ms" >> ~/.cline-tool-log.txt
-
-echo '{"cancel":false}'
-```
-
-### Add Project Context on Task Start
-
-Inject project-specific information when a task begins:
-
-```bash
-#!/bin/bash
-# TaskStart hook
-
-INPUT=$(cat)
-WORKSPACE=$(echo "$INPUT" | jq -r '.workspacePath')
-
-# Read project info if available
-if [[ -f "$WORKSPACE/.project-context" ]]; then
-  CONTEXT=$(cat "$WORKSPACE/.project-context")
-  echo "{\"cancel\":false,\"contextModification\":\"Project context: $CONTEXT\"}"
-else
-  echo '{"cancel":false}'
-fi
-```
-
-## CLI Support
-
-Hooks are available in the [Cline CLI](/cline-cli/getting-started):
-
-```bash
-# Enable hooks for a task
-cline "What does this repo do?" -s hooks_enabled=true
-
-# Configure hooks globally
-cline config set hooks-enabled=true
-```
-
-<Note>
-CLI hooks are only supported on macOS and Linux.
-</Note>
-
-## Troubleshooting
-
-**Hook not running?**
- Check that the file is executable (`chmod +x hookname`)
- Verify the hook is enabled (toggle is on in the Hooks tab)
- Check that Hooks are enabled globally in Settings
-
-**Hook output not parsed?**
- Ensure output is valid JSON on a single line to stdout
- Use stderr (`>&2`) for debug logging, not stdout
- Check for trailing characters or newlines before the JSON
-
-**Hook blocking unexpectedly?**
- Review the hook's logic and test with sample input
- Check both global and workspace hooks (both run if they exist)
-
-## Related Features
-
- [Rules](/customization/cline-rules) define high-level guidance that hooks can enforce programmatically
- [Checkpoints](/core-workflows/checkpoints) let you roll back if a hook didn't catch an issue
- [Auto-Approve](/features/auto-approve) works well with hooks as safety nets
@@ -1,86 +0,0 @@
---
-title: "Overview"
-sidebarTitle: "Overview"
-description: "Understand how Rules, Skills, Workflows, Hooks, and .clineignore work together to customize Cline."
---
-
-Out of the box, Cline is a general-purpose AI assistant. Customizations transform it into an expert on your codebase, your team's conventions, and your workflows. Instead of repeating the same instructions every task, you define them once and Cline follows them automatically.
-
-Cline offers five systems for this: Rules, Skills, Workflows, Hooks, and .clineignore. Each serves a different purpose and activates at different times.
-
-## Quick Comparison
-
-| Feature | Purpose | When Active | Best For |
-|---------|---------|-------------|----------|
-| **[Rules](/customization/cline-rules)** | Define how Cline behaves | Always (or contextually) | Coding standards, project constraints, team conventions |
-| **[Skills](/customization/skills)** | Domain expertise loaded on-demand | Triggered by matching requests | Specialized knowledge, complex procedures, institutional expertise |
-| **[Workflows](/customization/workflows)** | Step-by-step task automation | Invoked with `/workflow.md` | Repetitive processes, release procedures, setup scripts |
-| **[Hooks](/customization/hooks)** | Inject custom logic at key moments | Automatically on specific events | Validation, enforcement, monitoring, automation triggers |
-| **[.clineignore](/customization/clineignore)** | Control file access | Always | Excluding dependencies, build artifacts, large data files |
-
-## Understanding Each Tool
-
-**[Rules](/customization/cline-rules)** are always-on guidance. Use them when you want Cline to consistently follow certain patterns: coding standards, naming conventions, architectural constraints, or project-specific context. Rules shape *how* Cline works across all tasks. For example, a rule might say "always use TypeScript" or "follow the repository pattern for data access."
-
-**[Skills](/customization/skills)** are domain expertise that loads only when relevant. Use them when you have extensive knowledge that would waste context if always active. Cline sees skill descriptions at startup and activates the full instructions only when your request matches. A data analysis skill might include pandas patterns, visualization preferences, and output formats that Cline only loads when you're working with data files.
-
-**[Workflows](/customization/workflows)** are explicit task scripts you invoke on demand. Use them when you have a repeatable multi-step process that should run the same way every time. Type `/release.md` and Cline executes your release sequence: bump version, run tests, update changelog, commit, tag, push. Workflows define *what* to do, step by step.
-
-**[Hooks](/customization/hooks)** are programmatic guardrails that run automatically at key moments. Use them when you need to validate, enforce, or extend Cline's behavior with custom code. A hook might block `.js` file creation in a TypeScript project, run linters before saves, or notify external services after deployments.
-
-**[.clineignore](/customization/clineignore)** controls which files and directories Cline can access. Use it to exclude dependencies, build artifacts, generated files, and large data files from Cline's context. This reduces token usage, lowers costs, and keeps Cline focused on the code that matters. It works like `.gitignore`: add patterns to a `.clineignore` file in your project root and matching files are automatically excluded.
-
-### Example: A Release Process
-
-Consider how all five work together for releasing a new version:
-
-1. **Rules** ensure Cline follows your team's commit message format and versioning policy
-2. **Skills** offer deep knowledge about your CI/CD system that Cline loads when deployment questions arise
-3. **Workflows** provide the explicit `/release.md` sequence: bump version, update changelog, tag, push
-4. **Hooks** validate that tests pass before allowing any commit or that the changelog was actually updated
-5. **.clineignore** keeps build artifacts, `node_modules/`, and generated files out of Cline's context so it stays focused
-
-## Storage Locations
-
-All five systems support both global and project-specific configurations:
-
-| System | Global Location | Project Location |
-|--------|-----------------|------------------|
-| Rules | `~/Documents/Cline/Rules/` | `.clinerules/` |
-| Skills | `~/.cline/skills/` | `.cline/skills/` |
-| Workflows | `~/Documents/Cline/Workflows/` | `.clinerules/workflows/` |
-| Hooks | `~/Documents/Cline/Hooks/` | `.clinerules/hooks/` |
-| .clineignore | N/A | `.clineignore` |
-
-### When to Use Each
-
-**Start with project storage.** Most customizations belong in your project's directory because they're tied to that specific codebase. Team coding standards, deployment workflows, and architectural constraints all live with the code they describe. This also means your customizations travel with the repository, so collaborators get them automatically and changes can be reviewed in pull requests.
-
-**Use global storage for personal preferences.** If you find yourself adding the same customization to every project, move it to global storage. Your preferred communication style, personal productivity workflows, and tools you use everywhere belong here. Global customizations apply to all projects but stay out of version control, so they won't affect your teammates.
-
-When names conflict, project-specific configurations take precedence (except for Skills, where global takes precedence). This lets you override global defaults for specific projects when needed.
-
-## Security Considerations
-
-<Warning>
-Always review customizations before adding them to your projects. Only use customizations from sources you trust.
-</Warning>
-
-Customizations are powerful. They shape how Cline writes code, execute commands automatically, and influence every interaction. Treat customization files with the same scrutiny you'd give any code running in your environment.
-
-### Best Practices
-
-Review any customization file before adding it to your project or global configuration. Understand what it does and why.
-
-When downloading customizations from GitHub repositories, community shares, or other external sources, verify the source:
- Is the author reputable?
- Has the community reviewed it?
- Does the code do what it claims?
-
-Look for dangerous commands:
- Shell commands that delete files (`rm`, `del`)
- Commands that transmit data (`curl`, `wget` with POST)
- File operations outside your project directory
- Commands that modify system configuration
-
-Keep your customizations in version control so you can track changes, review diffs, and roll back if something goes wrong. When creating hooks, use the most restrictive event triggers necessary. Don't run hooks on every file save if you only need them before commits.
@@ -1,261 +0,0 @@
---
-title: "Skills"
-sidebarTitle: "Skills"
-description: "Modular instruction sets that extend Cline's capabilities for specific tasks."
---
-
-Skills are modular instruction sets that extend Cline's capabilities for specific tasks. Each skill packages detailed guidance, workflows, and optional resources that Cline loads only when relevant to your request.
-
-Install multiple skills and Cline only loads what it needs. A deployment skill stays dormant until you ask about deploying. Unlike [rules](/customization/cline-rules) (which are always active), skills load on-demand so they don't consume context when you're working on something unrelated.
-
-<Note>
-Skills is an experimental feature. Enable it in **Settings → Features → Enable Skills**.
-</Note>
-
-## How Skills Work
-
-Skills use progressive loading to maximize efficiency:
-
-| Level | When Loaded | Token Cost | Content |
-|-------|-------------|------------|---------|
-| Metadata | Always (at startup) | ~100 tokens per skill | `name` and `description` from YAML frontmatter |
-| Instructions | When skill is triggered | Under 5k tokens | SKILL.md body with instructions and guidance |
-| Resources | As needed | Effectively unlimited | Bundled files accessed via `read_file` or executed scripts |
-
-When you send a message, Cline sees a list of available skills with their descriptions. If your request matches a skill's description, Cline activates it using the `use_skill` tool, which loads the full instructions from SKILL.md.
-
-## Skill Structure
-
-Every skill is a directory containing a `SKILL.md` file with YAML frontmatter.
-
-```text title="Skill directory structure"
-my-skill/
-├── SKILL.md          # Required: main instructions
-├── docs/             # Optional: additional documentation
-│   └── advanced.md
-└── scripts/          # Optional: utility scripts
-    └── helper.sh
-```
-
-The `SKILL.md` file has two parts: metadata and instructions.
-
-```markdown title="SKILL.md"
---
-name: my-skill
-description: Brief description of what this skill does and when to use it.
---
-
-# My Skill
-
-Detailed instructions for Cline to follow when this skill is activated.
-
-## Steps
-1. First, do this
-2. Then do that
-3. For advanced usage, see [advanced.md](docs/advanced.md)
-```
-
-Required fields:
- `name` must exactly match the directory name
- `description` tells Cline when to use this skill (max 1024 characters)
-
-## Creating a Skill
-
-<Steps>
-  <Step title="Open the Skills menu">
-    Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Skills tab.
-  </Step>
-  <Step title="Create a new skill">
-    Click "New skill..." and enter a name for your skill (e.g., `aws-deploy`). Cline creates a skill directory with a template `SKILL.md` file.
-  </Step>
-  <Step title="Write your skill instructions">
-    Edit the `SKILL.md` file:
-    - Update the `description` field to specify when this skill should trigger
-    - Add detailed instructions in the body
-    - Optionally add supporting files in `docs/`, `templates/`, or `scripts/` subdirectories
-  </Step>
-</Steps>
-
-You can also create skills manually by creating the directory structure in your file system. Place skill directories in `.cline/skills/` (workspace) or `~/.cline/skills/` (global) and Cline will detect them automatically.
-
-Put the important information first in your SKILL.md. Cline reads the file sequentially, so front-load the common cases. Use clear section headers like "## Error Handling" or "## Configuration" so Cline can scan for relevant sections.
-
-### Toggling Skills
-
-Every skill has a toggle to enable or disable it. This lets you control which skills are active without deleting the skill directory. Skills are enabled by default when discovered.
-
-For example, you might disable a CI/CD skill when working on local development, or enable a client-specific skill only when working on that client's project.
-
-## Writing Your SKILL.md
-
-### Naming Conventions
-
-The skill name appears in the `name` field and must match the directory name exactly. Use lowercase with hyphens (kebab-case) and be descriptive about what the skill does.
-
-Good names:
- `aws-cdk-deploy`
- `pr-review-checklist`
- `database-migration`
- `api-client-generator`
-
-Avoid:
- `aws` (too vague)
- `my_skill` (underscores, not descriptive)
- `DeployToAWS` (use kebab-case, not PascalCase)
- `misc-helpers` (too generic)
-
-### Writing Effective Descriptions
-
-The description determines when Cline activates the skill. A vague description means the skill won't trigger when you expect it to.
-
-Good descriptions are specific and actionable:
-
-```yaml
-description: Deploy applications to AWS using CDK. Use when deploying, updating infrastructure, or managing AWS resources.
-
-description: Generate release notes from git commits. Use when preparing releases, writing changelogs, or summarizing recent changes.
-
-description: Analyze CSV and Excel data files. Use when exploring datasets, generating statistics, or creating visualizations from tabular data.
-```
-
-Weak descriptions leave too much ambiguity:
-
-```yaml
-description: Helps with AWS stuff.
-
-description: Data analysis helper.
-
-description: Useful for releases.
-```
-
-Start with what the skill does (action verbs), include trigger phrases users might say, and mention specific file types, tools, or domains. Test your descriptions by trying different phrasings of requests to see if the skill triggers.
-
-### Keeping Skills Focused
-
-Keep SKILL.md under 5k tokens. If your skill needs more content, split it into separate files in a `docs/` directory and reference them from the main instructions. Cline loads referenced files only when needed.
-
-Include real examples. Show what commands to run, what output to expect, and what the result should look like. Abstract instructions are harder to follow than concrete examples.
-
-## Where Skills Live
-
-Skills can be stored globally or in a project workspace. See [Storage Locations](/customization/overview#storage-locations) for guidance on when to use each.
-
-Project skills:
- `.cline/skills/` (recommended)
- `.clinerules/skills/`
- `.claude/skills/`
-
-Global skills:
- `~/.cline/skills/` (macOS/Linux)
- `C:\Users\USERNAME\.cline\skills\` (Windows)
-
-When a global skill and project skill have the same name, the global skill takes precedence. This lets you keep general-purpose skills globally while using project-specific skills in `.cline/skills/` so the whole team can use them.
-
-Version control your project skills by committing `.cline/skills/`. Your team can share, review, and improve them together.
-
-## Bundling Supporting Files
-
-Skills can include additional files that Cline accesses only when needed.
-
-```text title="Directory structure"
-complex-skill/
-├── SKILL.md
-├── docs/
-│   ├── setup.md
-│   └── troubleshooting.md
-├── templates/
-│   └── config.yaml
-└── scripts/
-    └── validate.py
-```
-
-### docs/
-
-Use docs for information that's too detailed for SKILL.md or only relevant in specific situations:
- Advanced configuration options
- Troubleshooting guides for edge cases
- Reference material (API schemas, database schemas)
- Platform-specific instructions
-
-A deployment skill might have `docs/aws.md`, `docs/gcp.md`, and `docs/azure.md`. Cline loads only the relevant platform guide based on your request.
-
-### templates/
-
-Use templates when your skill creates configuration files, boilerplate code, or structured documents:
- Config files (Terraform, Docker Compose, CI/CD pipelines)
- Code scaffolding (component templates, test fixtures)
- Documentation templates (README, API docs)
-
-A project setup skill could include `templates/dockerfile`, `templates/docker-compose.yml`, and `templates/.env.example` that Cline customizes for each new project.
-
-### scripts/
-
-Use scripts for deterministic operations where you want consistent behavior:
- Validation (linting configs, checking prerequisites)
- Data processing (parsing, formatting, transforming)
- Complex calculations (cost estimation, resource sizing)
- API interactions (fetching data, running health checks)
-
-Scripts are token-efficient because only their output enters context, not the code itself. A 500-line validation script produces a simple "Passed" or detailed error messages without consuming any context for the script logic.
-
-### Referencing Bundled Files
-
-Reference these files in your SKILL.md instructions:
-
-```markdown title="SKILL.md (referencing bundled files)"
-For initial setup, follow [setup.md](docs/setup.md).
-Use the config template at `templates/config.yaml` as a starting point.
-Run the validation script to check your configuration:
-
-python scripts/validate.py
-```
-
-Cline reads documentation files using `read_file` when the instructions reference them. Scripts can be executed directly, and only the script's output enters the context window.
-
-| Use Scripts For | Use Instructions For |
-|-----------------|---------------------|
-| Deterministic operations (validation, formatting) | Flexible guidance that adapts to context |
-| Complex computations | Decision-making workflows |
-| Operations that need reliability | Steps that might vary by situation |
-| Anything you'd rather not consume tokens explaining | Best practices and patterns |
-
-## Example: Data Analysis Skill
-
-Here's a practical skill for data analysis tasks. Create a directory called `data-analysis/` with this `SKILL.md`:
-
-```markdown title="data-analysis/SKILL.md"
---
-name: data-analysis
-description: Analyze data files and generate insights. Use when working with CSV, Excel, or JSON data files that need exploration, cleaning, or visualization.
---
-
-# Data Analysis
-
-When analyzing data files, follow this workflow:
-
-## 1. Understand the Data
- Read a sample of the file to understand its structure
- Identify column types and data quality issues
- Note any missing values or anomalies
-
-## 2. Ask Clarifying Questions
-Before diving in, ask the user:
- What specific insights are they looking for?
- Are there any known data quality issues?
- What format do they want for the output?
-
-## 3. Perform Analysis
-Use pandas for data manipulation:
-
-import pandas as pd
-
-# Load and explore
-df = pd.read_csv("data.csv")
-print(df.head())
-print(df.describe())
-print(df.info())
-
-For visualization, prefer matplotlib or seaborn depending on complexity.
-```
-
-Skills transform Cline from a general-purpose assistant into a specialist that knows your domain. Start with one skill for a task you repeat often, test it, and iterate on the description until it triggers reliably.
@@ -1,221 +0,0 @@
---
-title: "Workflows"
-sidebarTitle: "Workflows"
-description: "Automate repetitive tasks with Markdown-based workflow files."
---
-
-Workflows are Markdown files that define a series of steps to guide Cline through repetitive or complex tasks. Type `/` followed by the workflow's filename to invoke it (e.g., `/deploy.md`).
-
-Deploying, setting up a new project, running through a release checklist: these tasks often require remembering a dozen steps, running commands in the right order, and updating files manually. Mess up one step and you're debugging for an hour. Workflows turn those multi-step processes into one command. Type `/release.md` and Cline handles the version bump, runs tests, updates the changelog, commits, tags, and pushes. You just review and approve.
-
-## Workflow Structure
-
-A workflow is a markdown file with a title and steps. The filename becomes the command: `demo-workflow.md` is invoked with `/demo-workflow.md`.
-
-````markdown title="demo-workflow.md"
-# Demo Workflow
-
-Brief description of what this workflow accomplishes.
-
-## Step 1: Check prerequisites
-Verify the environment is ready. Look for required tools and dependencies.
-
-## Step 2: Run the build
-Execute the build command:
-```bash
-npm run build
-```
-
-## Step 3: Verify results
-Check that the build completed successfully and report any issues.
-````
-
-Steps can be written at different levels of detail:
-
- **High-level**: "Run the test suite and fix any failures" lets Cline decide how to accomplish the goal
- **Specific**: Use XML tool syntax or exact commands when you need precise control
-
-## Creating Workflows
-
-<Steps>
-  <Step title="Open the Workflows menu">
-    Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Workflows tab.
-  </Step>
-  <Step title="Create a new workflow file">
-    Click "New workflow file..." and enter a filename (e.g., `deploy`). The file will be created with a `.md` extension.
-  </Step>
-  <Step title="Write your workflow">
-    Add a title and numbered steps in markdown format. Describe what each step should accomplish.
-  </Step>
-</Steps>
-
-<Tip>
-**Create workflows from completed tasks.** After finishing something you'll need to repeat, tell Cline: "Create a workflow for the process I just completed." Cline analyzes the conversation, identifies the steps, and generates the workflow file. Your accumulated context becomes reusable automation.
-</Tip>
-
-### Invoking Workflows
-
-Type `/` in the chat input to see available workflows. Cline shows autocomplete suggestions as you type, so `/rel` would match `release-prep.md`. Select a workflow and press Enter to start it.
-
-Cline executes each step in sequence, pausing for your approval when needed. You can stop a workflow at any point by rejecting a step.
-
-### Toggling Workflows
-
-Every workflow has a toggle to enable or disable it. This lets you control which workflows appear in the `/` menu without deleting the file.
-
-## Where Workflows Live
-
-Workflows can be stored in two locations: your project workspace or globally on your system.
-
-**Workspace workflows** go in `.clinerules/workflows/` at your project root. Use these for project-specific automation like deployment scripts, release processes, or setup procedures that your team shares.
-
-**Global workflows** go in your system's Cline Workflows directory. Use these for personal productivity workflows you use across all projects.
-
-### Global Workflows Directory
-
-| Operating System | Default Location |
-|------------------|------------------|
-| Windows | `Documents\Cline\Workflows` |
-| macOS | `~/Documents/Cline/Workflows` |
-| Linux/WSL | `~/Documents/Cline/Workflows` |
-
-Workspace workflows take precedence when names match global workflows. See [Storage Locations](/customization/overview#storage-locations) for more guidance.
-
-## What Workflows Can Use
-
-Workflows can combine natural language instructions with specific tool calls. This flexibility lets you write workflows that are as simple or as precise as your task requires.
-
-### Natural Language
-
-Write steps as plain instructions. Cline interprets them and figures out which tools to use:
-
-```markdown
-## Step 1: Check for uncommitted changes
-Look at the git status. If there are uncommitted changes, ask whether to continue or abort.
-
-## Step 2: Run the test suite
-Execute all tests. If any fail, show the failures and stop.
-```
-
-This approach works well when you want Cline to adapt to the situation rather than follow rigid steps.
-
-### Cline Tools
-
-For precise control, use Cline's built-in tools with XML syntax. This guarantees specific actions:
-
-```xml
-<execute_command>
-  <command>npm run test</command>
-  <requires_approval>false</requires_approval>
-</execute_command>
-```
-
-```xml
-<read_file>
-  <path>src/config.json</path>
-</read_file>
-```
-
-```xml
-<ask_followup_question>
-  <question>Deploy to production or staging?</question>
-  <options>["Production", "Staging", "Cancel"]</options>
-</ask_followup_question>
-```
-
-See the full list in the [Cline Tools Reference](/tools-reference/all-cline-tools).
-
-### CLI Tools
-
-Reference any command-line tool installed on your machine. Git, npm, docker, gh, make, curl: whatever you have available.
-
-```bash
-git log --author="$(git config user.name)" --since="yesterday" --oneline
-```
-
-### MCP Tools
-
-If you have [MCP servers](/mcp/mcp-overview) connected, use them in your workflows with the `use_mcp_tool` syntax. This lets you integrate with external services like GitHub, Slack, databases, or custom internal tools.
-
-```xml
-<use_mcp_tool>
-<server_name>github-server</server_name>
-<tool_name>create_release</tool_name>
-<arguments>{"tag": "v1.2.0", "name": "Release v1.2.0", "body": "Changelog content here"}</arguments>
-</use_mcp_tool>
-```
-
-Or describe the intent in natural language and let Cline figure out the tool call:
-
-```markdown
-## Step 3: Create GitHub release
-Use the GitHub MCP server to create a release tagged with the version from package.json.
-Include the changelog as the release body.
-```
-
-## Writing Effective Workflows
-
-**Start simple.** Write natural language steps first. Only add XML tool calls when you need guaranteed behavior.
-
-**Be specific about decisions.** If a step requires user input, make that explicit: "Ask whether to deploy to production or staging."
-
-**Include failure handling.** Tell Cline what to do when something goes wrong: "If tests fail, show the failures and stop the workflow."
-
-**Keep workflows focused.** A `deploy.md` should deploy. A `setup-db.md` should set up the database. Split complex processes into multiple workflows that can be run independently.
-
-**Version control your workflows.** Store workflows in `.clinerules/workflows/` and commit them. Your team can share, review, and improve them together.
-
-<Warning>
-Workflows execute with your permissions. Review workflows before running them, especially those from external sources.
-</Warning>
-
-## Example: Release Preparation
-
-This workflow automates the tedious pre-release checklist. It verifies your working directory is clean, runs tests and builds, prompts you for the version bump, and generates a changelog from recent commits.
-
-The workflow demonstrates both approaches: XML tool syntax (`<execute_command>`, `<ask_followup_question>`) for steps that need precise control, and natural language for steps where Cline should adapt to the situation.
-
-````markdown title="release-prep.md"
-# Release Preparation
-
-Prepare a new release by running tests, building, and updating version info.
-
-## Step 1: Check for clean working directory
-<execute_command>
-<command>git status --porcelain</command>
-</execute_command>
-
-If there are uncommitted changes, ask whether to continue or stash them first.
-
-## Step 2: Run the test suite
-<execute_command>
-<command>npm run test</command>
-</execute_command>
-
-If any tests fail, stop the workflow and report the failures.
-
-## Step 3: Build the project
-<execute_command>
-<command>npm run build</command>
-</execute_command>
-
-Verify the build completes without errors.
-
-## Step 4: Ask for new version
-<ask_followup_question>
-<question>What should the new version be?</question>
-<options>["Patch (x.x.X)", "Minor (x.X.0)", "Major (X.0.0)", "Custom"]</options>
-</ask_followup_question>
-
-## Step 5: Update version
-Update the version in `package.json` to the new version specified by the user.
-
-## Step 6: Generate changelog entry
-<execute_command>
-<command>git log --oneline $(git describe --tags --abbrev=0)..HEAD</command>
-</execute_command>
-
-Use these commits to write a changelog entry for the new version.
-````
-
-Invoke it with `/release-prep.md` and Cline walks through each step.
@@ -1,6 +1,6 @@
 {
 	"$schema": "https://mintlify.com/docs.json",
-	"theme": "mint",
+	"theme": "linden",
 	"name": "Cline",
 	"description": "AI-powered coding agent for complex work",
 	"colors": {
@@ -60,130 +60,170 @@
 				"icon": "square-terminal",
 				"groups": [
 					{
-						"group": "Home",
+						"group": "Introduction",
 						"pages": [
-							"home",
-							"getting-started/quick-start"
+							"introduction/welcome",
+							"introduction/overview"
 						]
 					},
 					{
 						"group": "Getting Started",
 						"pages": [
-							"getting-started/what-is-cline",
 							"getting-started/installing-cline",
-							"getting-started/authorizing-with-cline",
+							"getting-started/selecting-your-model",
 							"getting-started/your-first-project"
 						]
 					},
 					{
-						"group": "Core Workflows",
+						"group": "Best Practices",
 						"pages": [
-							"core-workflows/task-management",
-							"core-workflows/plan-and-act",
-							"core-workflows/working-with-files",
-							"core-workflows/using-commands",
-							"core-workflows/checkpoints"
+							"prompting/understanding-context-management",
+							"prompting/prompt-engineering-guide",
+							"prompting/cline-memory-bank"
 						]
 					},
 					{
-						"group": "Customization",
-						"pages": [
-							"customization/overview",
-							"customization/cline-rules",
-							"customization/skills",
-							"customization/workflows",
-							"customization/hooks",
-							"customization/clineignore"
-						]
-					},
-					{
-						"group": "Cline CLI",
+						"group": "CLI",
 						"pages": [
 							"cline-cli/overview",
 							"cline-cli/installation",
 							"cline-cli/interactive-mode",
+							"cline-cli/configuration",
+							"cline-cli/three-core-flows",
+							"cline-cli/acp-editor-integrations",
 							{
-								"group": "Headless Mode",
+								"group": "CLI Samples",
 								"pages": [
-									"cline-cli/three-core-flows",
 									"cline-cli/samples/overview",
+									"cline-cli/samples/model-orchestration",
+									"cline-cli/samples/worktree-workflows",
 									"cline-cli/samples/github-issue-rca",
 									"cline-cli/samples/github-integration",
-									"cline-cli/samples/github-pr-review",
-									"cline-cli/samples/model-orchestration",
-									"cline-cli/samples/worktree-workflows"
+									"cline-cli/samples/github-pr-review"
 								]
 							},
-							"cline-cli/configuration",
-							"cline-cli/acp-editor-integrations",
 							"cline-cli/cli-reference"
 						]
 					},
 					{
 						"group": "Features",
 						"pages": [
-							"features/memory-bank",
-							"features/focus-chain",
+							{
+								"group": "@ Mentions",
+								"pages": [
+									"features/at-mentions/overview",
+									"features/at-mentions/file-mentions",
+									"features/at-mentions/terminal-mentions",
+									"features/at-mentions/problem-mentions",
+									"features/at-mentions/git-mentions",
+									"features/at-mentions/url-mentions"
+								]
+							},
 							"features/auto-approve",
 							"features/auto-compact",
-							"features/multiroot-workspace",
-							"features/subagents",
 							"features/background-edit",
-							"features/jupyter-notebooks",
-							"features/deep-planning",
-							"features/web-tools",
-							"features/worktrees"
-						]
-					},
-					{
-						"group": "Models & Providers",
-						"pages": [
+							"features/checkpoints",
 							{
-								"group": "Choosing & Configuring Models",
+								"group": "Cline Rules",
 								"pages": [
-									"core-features/model-selection-guide",
-									"model-config/context-windows"
+									"features/cline-rules/overview",
+									"features/cline-rules/conditional-rules"
 								]
 							},
 							{
-								"group": "Running Models Locally",
+								"group": "Commands & Shortcuts",
 								"pages": [
-									"running-models-locally/overview",
-									"running-models-locally/ollama",
-									"running-models-locally/lm-studio"
+									"features/commands-and-shortcuts/overview",
+									"features/commands-and-shortcuts/code-commands",
+									"features/commands-and-shortcuts/terminal-integration",
+									"features/commands-and-shortcuts/git-integration",
+									"features/commands-and-shortcuts/keyboard-shortcuts"
+								]
+							},
+							{
+								"group": "Customization",
+								"pages": [
+									"features/customization/opening-cline-in-sidebar",
+									"features/customization/disable-terminal-pagers"
+								]
+							},
+							"features/dictation",
+							"features/drag-and-drop",
+							"features/editing-messages",
+							"features/explain-changes",
+							"features/focus-chain",
+							{
+								"group": "Hooks",
+								"pages": [
+									"features/hooks/index",
+									"features/hooks/hook-reference",
+									"features/hooks/samples"
+								]
+							},
+							"features/jupyter-notebooks",
+							"features/multiroot-workspace",
+							"features/plan-and-act",
+							"features/skills",
+							"features/subagents",
+							{
+								"group": "Slash Commands",
+								"pages": [
+									"features/slash-commands/new-task",
+									"features/slash-commands/new-rule",
+									"features/slash-commands/explain-changes",
+									"features/slash-commands/smol",
+									"features/slash-commands/report-bug",
+									"features/slash-commands/deep-planning"
+								]
+							},
+							{
+								"group": "Workflows",
+								"pages": [
+									"features/slash-commands/workflows/index",
+									"features/slash-commands/workflows/quickstart",
+									"features/slash-commands/workflows/best-practices"
+								]
+							},
+							{
+								"group": "Task Management",
+								"pages": [
+									"features/tasks/understanding-tasks",
+									"features/tasks/task-management"
+								]
+							},
+							"features/worktrees",
+							"features/yolo-mode"
+						]
+					},
+					{
+						"group": "Model & Provider Configuration",
+						"pages": [
+							{
+								"group": "Model Selection",
+								"pages": [
+									"core-features/model-selection-guide",
+									"model-config/model-comparison",
+									"model-config/context-windows"
 								]
 							},
 							{
 								"group": "Cloud Providers",
 								"pages": [
-									"provider-config/qwen",
 									"provider-config/anthropic",
-									"provider-config/asksage",
-									"provider-config/baseten",
-									"provider-config/cerebras",
 									"provider-config/claude-code",
-									"provider-config/deepseek",
-									"provider-config/doubao",
-									"provider-config/fireworks",
-									"provider-config/gcp-vertex-ai",
-									"provider-config/google-gemini",
-									"provider-config/groq",
-									"provider-config/huawei-cloud-maas",
-									"provider-config/huggingface",
-									"provider-config/minimax",
-									"provider-config/mistral-ai",
-									"provider-config/moonshot",
-									"provider-config/nebius",
-									"provider-config/nousresearch",
 									"provider-config/openai",
 									"provider-config/openai-codex",
 									"provider-config/openrouter",
-									"provider-config/oracle-code-assist",
-									"provider-config/qwen-code",
-									"provider-config/sambanova",
-									"provider-config/together",
+									"provider-config/cerebras",
+									"provider-config/deepseek",
+									"provider-config/groq",
 									"provider-config/xai-grok",
+									"provider-config/mistral-ai",
+									"provider-config/doubao",
+									"provider-config/fireworks",
 									"provider-config/zai",
+									"provider-config/gcp-vertex-ai",
+									"provider-config/baseten",
 									{
 										"group": "AWS Bedrock",
 										"pages": [
@@ -194,53 +234,55 @@
 									}
 								]
 							},
+							{
+								"group": "Running Models Locally",
+								"pages": [
+									"running-models-locally/overview",
+									"running-models-locally/ollama",
+									"running-models-locally/lm-studio"
+								]
+							},
 							{
 								"group": "Advanced Configuration",
 								"pages": [
-									"provider-config/aihubmix",
-									"provider-config/dify",
-									"provider-config/hicap",
-									"provider-config/litellm-and-cline-using-codestral",
 									"provider-config/openai-compatible",
-									"provider-config/requesty",
+									"provider-config/litellm-and-cline-using-codestral",
+									"provider-config/vscode-language-model-api",
 									"provider-config/sap-aicore",
 									"provider-config/vercel-ai-gateway",
-									"provider-config/vscode-language-model-api"
+									"provider-config/requesty"
 								]
 							}
 						]
 					},
 					{
-						"group": "MCP (Extending Cline)",
+						"group": "MCP Integration",
 						"pages": [
 							"mcp/mcp-overview",
-							"mcp/mcp-marketplace",
-							"mcp/adding-and-configuring-servers",
-							"mcp/mcp-server-development-protocol",
+							"mcp/adding-mcp-servers-from-github",
+							"mcp/configuring-mcp-servers",
 							"mcp/connecting-to-a-remote-server",
+							"mcp/mcp-marketplace",
+							"mcp/mcp-server-development-protocol",
 							"mcp/mcp-transport-mechanisms"
 						]
 					},
 					{
-						"group": "Tools Reference",
+						"group": "Cline Tools Reference",
 						"pages": [
-							"tools-reference/all-cline-tools",
-							"tools-reference/browser-automation"
+							"exploring-clines-tools/cline-tools-guide",
+							"exploring-clines-tools/new-task-tool",
+							"exploring-clines-tools/remote-browser-support"
 						]
 					},
 					{
-						"group": "Troubleshooting",
+						"group": "Reference",
 						"pages": [
-							"troubleshooting/terminal-quick-fixes",
 							"troubleshooting/networking-and-proxies",
-							"troubleshooting/task-history-recovery"
-						]
-					},
-					{
-						"group": "Contributing",
-						"pages": [
-							"contributing/documentation-guide",
-							"contributing/doc-templates"
+							"troubleshooting/terminal-quick-fixes",
+							"troubleshooting/terminal-integration-guide",
+							"troubleshooting/task-history-recovery",
+							"more-info/telemetry"
 						]
 					}
 				]
@@ -294,7 +336,8 @@
 								"pages": [
 									"enterprise-solutions/monitoring/overview",
 									"enterprise-solutions/monitoring/telemetry",
-									"enterprise-solutions/monitoring/opentelemetry"
+									"enterprise-solutions/monitoring/opentelemetry",
+									"enterprise-solutions/monitoring/opentelemetry_override"
 								]
 							}
 						]
@@ -319,7 +362,7 @@
 		{
 			"name": "Overview",
 			"icon": "house",
-			"url": "getting-started/what-is-cline"
+			"url": "introduction/overview"
 		}
 	],
 	"redirects": [
@@ -327,21 +370,17 @@
 			"source": "/getting-started/installing-cline-jetbrains",
 			"destination": "/getting-started/installing-cline"
 		},
+		{
+			"source": "/getting-started/what-is-cline",
+			"destination": "/introduction/overview"
+		},
 		{
 			"source": "/getting-started/overview",
-			"destination": "/getting-started/what-is-cline"
+			"destination": "/introduction/overview"
 		},
 		{
 			"source": "/introduction",
-			"destination": "/getting-started/what-is-cline"
-		},
-		{
-			"source": "/introduction/welcome",
-			"destination": "/getting-started/what-is-cline"
-		},
-		{
-			"source": "/introduction/overview",
-			"destination": "/getting-started/what-is-cline"
+			"destination": "/introduction/welcome"
 		},
 		{
 			"source": "/getting-started/model-selection-guide",
@@ -357,39 +396,11 @@
 		},
 		{
 			"source": "/getting-started/understanding-context-management",
-			"destination": "/model-config/context-windows"
+			"destination": "/prompting/understanding-context-management"
 		},
 		{
 			"source": "/best-practices/understanding-context-management",
-			"destination": "/model-config/context-windows"
-		},
-		{
-			"source": "/prompting/understanding-context-management",
-			"destination": "/model-config/context-windows"
-		},
-		{
-			"source": "/prompting/prompt-engineering-guide",
-			"destination": "/customization/cline-rules"
-		},
-		{
-			"source": "/prompting/cline-memory-bank",
-			"destination": "/features/memory-bank"
-		},
-		{
-			"source": "/customization/memory-bank",
-			"destination": "/features/memory-bank"
-		},
-		{
-			"source": "/customization/focus-chain",
-			"destination": "/features/focus-chain"
-		},
-		{
-			"source": "/customization/auto-approve",
-			"destination": "/features/auto-approve"
-		},
-		{
-			"source": "/customization/auto-compact",
-			"destination": "/features/auto-compact"
+			"destination": "/prompting/understanding-context-management"
 		},
 		{
 			"source": "/getting-started/your-first-task",
@@ -399,149 +410,9 @@
 			"source": "/cline-cli/samples",
 			"destination": "/cline-cli/samples/overview"
 		},
-		{
-			"source": "/cline-cli/overview",
-			"destination": "/cline-cli/getting-started"
-		},
 		{
 			"source": "/features/hooks/real-world-examples",
-			"destination": "/customization/hooks"
-		},
-		{
-			"source": "/features/hooks/index",
-			"destination": "/customization/hooks"
-		},
-		{
-			"source": "/features/hooks/hook-reference",
-			"destination": "/customization/hooks"
-		},
-		{
-			"source": "/features/hooks/samples",
-			"destination": "/customization/hooks"
-		},
-		{
-			"source": "/features/plan-and-act",
-			"destination": "/core-workflows/plan-and-act"
-		},
-		{
-			"source": "/features/checkpoints",
-			"destination": "/core-workflows/checkpoints"
-		},
-		{
-			"source": "/features/tasks/understanding-tasks",
-			"destination": "/core-workflows/task-management"
-		},
-		{
-			"source": "/features/tasks/task-management",
-			"destination": "/core-workflows/task-management"
-		},
-		{
-			"source": "/features/at-mentions/overview",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/at-mentions/file-mentions",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/at-mentions/folder-mentions",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/at-mentions/terminal-mentions",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/at-mentions/problem-mentions",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/at-mentions/git-mentions",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/at-mentions/url-mentions",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/drag-and-drop",
-			"destination": "/core-workflows/working-with-files"
-		},
-		{
-			"source": "/features/yolo-mode",
-			"destination": "/features/auto-approve"
-		},
-		{
-			"source": "/features/cline-rules",
-			"destination": "/customization/cline-rules"
-		},
-		{
-			"source": "/features/cline-rules/overview",
-			"destination": "/customization/cline-rules"
-		},
-		{
-			"source": "/features/cline-rules/conditional-rules",
-			"destination": "/customization/cline-rules"
-		},
-		{
-			"source": "/features/commands-and-shortcuts/overview",
-			"destination": "/core-workflows/using-commands"
-		},
-		{
-			"source": "/features/commands-and-shortcuts/code-commands",
-			"destination": "/core-workflows/using-commands"
-		},
-		{
-			"source": "/features/commands-and-shortcuts/terminal-integration",
-			"destination": "/core-workflows/using-commands"
-		},
-		{
-			"source": "/features/commands-and-shortcuts/git-integration",
-			"destination": "/core-workflows/using-commands"
-		},
-		{
-			"source": "/features/commands-and-shortcuts/keyboard-shortcuts",
-			"destination": "/core-workflows/using-commands"
-		},
-		{
-			"source": "/features/slash-commands/new-task",
-			"destination": "/core-workflows/using-commands"
-		},
-		{
-			"source": "/features/slash-commands/workflows/index",
-			"destination": "/customization/workflows"
-		},
-		{
-			"source": "/features/slash-commands/workflows/quickstart",
-			"destination": "/customization/workflows"
-		},
-		{
-			"source": "/features/slash-commands/workflows/best-practices",
-			"destination": "/customization/workflows"
-		},
-		{
-			"source": "/exploring-clines-tools/cline-tools-guide",
-			"destination": "/tools-reference/all-cline-tools"
-		},
-		{
-			"source": "/exploring-clines-tools/new-task-tool",
-			"destination": "/tools-reference/all-cline-tools"
-		},
-		{
-			"source": "/exploring-clines-tools/remote-browser-support",
-			"destination": "/tools-reference/browser-automation"
-		},
-		{
-			"source": "/mcp/adding-mcp-servers-from-github",
-			"destination": "/mcp/adding-and-configuring-servers"
-		},
-		{
-			"source": "/mcp/configuring-mcp-servers",
-			"destination": "/mcp/adding-and-configuring-servers"
-		},
-		{
-			"source": "/more-info/telemetry",
-			"destination": "/enterprise-solutions/monitoring/telemetry"
+			"destination": "/features/hooks/samples"
 		},
 		{
 			"source": "/enterprise-solutions/configure-AWS-Bedrock-Admin",
@@ -568,44 +439,16 @@
 			"destination": "/enterprise-solutions/team-management/managing-members"
 		},
 		{
-			"source": "/features/customization/opening-cline-in-sidebar",
-			"destination": "/getting-started/installing-cline"
+			"source": "/features/cline-rules",
+			"destination": "/features/cline-rules/overview"
 		},
 		{
-			"source": "/prompting/prompt-engineering-guide/clineignore-file-guide",
-			"destination": "/customization/clineignore"
+			"source": "/features/conditional-rules",
+			"destination": "/features/cline-rules/conditional-rules"
 		},
 		{
-			"source": "/getting-started/selecting-your-model",
-			"destination": "/getting-started/authorizing-with-cline"
-		},
-		{
-			"source": "/model-config/model-comparison",
-			"destination": "/core-features/model-selection-guide"
-		},
-		{
-			"source": "/troubleshooting/terminal-integration-guide",
-			"destination": "/troubleshooting/terminal-quick-fixes"
-		},
-		{
-			"source": "/features/slash-commands/deep-planning",
-			"destination": "/features/deep-planning"
-		},
-		{
-			"source": "/features/slash-commands/smol",
-			"destination": "/core-workflows/using-commands#smol"
-		},
-		{
-			"source": "/features/slash-commands/explain-changes",
-			"destination": "/core-workflows/using-commands#explain-changes"
-		},
-		{
-			"source": "/features/slash-commands/new-rule",
-			"destination": "/core-workflows/using-commands#newrule"
-		},
-		{
-			"source": "/features/skills",
-			"destination": "/customization/skills"
+			"source": "/cline-cli/authentication",
+			"destination": "/cline-cli/installation"
 		}
 	],
 	"search": {
@@ -0,0 +1,287 @@
+---
+title: "Bundled Endpoints Configuration"
+description: "Enterprise guide for distributing Cline with pre-configured endpoints"
+---
+
+# Bundled Endpoints Configuration
+
+This guide explains how enterprise customers can distribute Cline with pre-configured endpoints bundled directly into the installation packages.
+
+## Overview
+
+Cline supports bundling custom endpoint configurations directly into distribution packages (VSIX, NPM, or JetBrains). This eliminates the need for end users to manually configure endpoints, ensuring consistent configuration across your organization.
+
+### Configuration Priority
+
+When Cline starts, it checks for endpoints configuration in this order:
+
+1. **Bundled endpoints.json** (in extension installation directory) - Highest priority
+2. **User endpoints.json** (`~/.cline/endpoints.json`) - Fallback
+3. **Built-in endpoints** (standard Cline URLs) - Default
+
+When a bundled `endpoints.json` is found, Cline automatically switches to self-hosted mode and uses those endpoints exclusively.
+
+## Prerequisites
+
+- Official Cline release package (VSIX, TGZ, or ZIP)
+- Your `endpoints.json` configuration file
+- `jq` command-line tool (for JSON validation)
+- `unzip`, `zip`, `tar` utilities
+
+## Creating endpoints.json
+
+Create a JSON file with your organization's endpoints:
+
+```json
+{
+  "appBaseUrl": "https://cline.yourcompany.com",
+  "apiBaseUrl": "https://api-cline.yourcompany.com",
+  "mcpBaseUrl": "https://api-cline.yourcompany.com/v1/mcp"
+}
+```
+
+### Required Fields
+
+All three fields are required and must be valid URLs:
+
+- **appBaseUrl**: Web application base URL
+- **apiBaseUrl**: API server base URL  
+- **mcpBaseUrl**: MCP (Model Context Protocol) server URL
+
+### Validation
+
+The packaging scripts automatically validate:
+- Valid JSON syntax
+- All required fields present
+- Non-empty string values
+- Valid URL format (must start with `http://` or `https://`)
+
+## Packaging Scripts
+
+Cline provides three scripts for adding bundled endpoints to packages:
+
+### VSCode Extension (VSIX)
+
+```bash
+./scripts/add-endpoints-to-vsix.sh \
+  cline-3.55.0.vsix \
+  cline-3.55.0-enterprise.vsix \
+  endpoints.json
+```
+
+This script:
+1. Extracts the VSIX package
+2. Adds `endpoints.json` to the `extension/` directory
+3. Repackages as a new VSIX file
+
+### NPM Package (CLI)
+
+```bash
+./scripts/add-endpoints-to-npm.sh \
+  cline-3.55.0.tgz \
+  cline-3.55.0-enterprise.tgz \
+  endpoints.json
+```
+
+This script:
+1. Extracts the NPM tarball
+2. Adds `endpoints.json` to the package root
+3. Repackages as a new tarball
+
+### JetBrains Plugin (ZIP)
+
+```bash
+./scripts/add-endpoints-to-jetbrains.sh \
+  cline-jetbrains-3.55.0.zip \
+  cline-jetbrains-3.55.0-enterprise.zip \
+  endpoints.json
+```
+
+This script:
+1. Extracts the ZIP package
+2. Adds `endpoints.json` to the plugin directory
+3. Repackages as a new ZIP file
+
+## Distribution Workflow
+
+### 1. Download Official Release
+
+Download the official Cline package for your platform:
+
+```bash
+# VSCode - from marketplace or GitHub releases
+curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-3.55.0.vsix
+
+# NPM - from npm registry
+npm pack @cline/cline@3.55.0
+
+# JetBrains - from marketplace or GitHub releases
+curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-jetbrains-3.55.0.zip
+```
+
+### 2. Create Endpoints Configuration
+
+Create your `endpoints.json` file:
+
+```json
+{
+  "appBaseUrl": "https://cline.internal.company.com",
+  "apiBaseUrl": "https://cline-api.internal.company.com",
+  "mcpBaseUrl": "https://cline-api.internal.company.com/v1/mcp"
+}
+```
+
+### 3. Run Packaging Script
+
+Choose the appropriate script for your platform:
+
+```bash
+# VSCode
+./scripts/add-endpoints-to-vsix.sh \
+  cline-3.55.0.vsix \
+  cline-3.55.0-yourcompany.vsix \
+  endpoints.json
+
+# CLI
+./scripts/add-endpoints-to-npm.sh \
+  cline-3.55.0.tgz \
+  cline-3.55.0-yourcompany.tgz \
+  endpoints.json
+
+# JetBrains
+./scripts/add-endpoints-to-jetbrains.sh \
+  cline-jetbrains-3.55.0.zip \
+  cline-jetbrains-3.55.0-yourcompany.zip \
+  endpoints.json
+```
+
+### 4. Distribute to Users
+
+Distribute the enterprise package to your users through your internal channels:
+
+- **VSCode**: Install via `code --install-extension cline-3.55.0-yourcompany.vsix`
+- **CLI**: Install via `npm install -g cline-3.55.0-yourcompany.tgz`
+- **JetBrains**: Install through IDE plugin manager from disk
+
+## Verification
+
+After installation, verify the configuration is active:
+
+1. Launch Cline
+2. Check the logs for: `"Cline running in self-hosted mode with custom endpoints"`
+3. Confirm that environment switching is disabled (as expected in self-hosted mode)
+
+## User Experience
+
+### What Users See
+
+- Cline automatically uses the bundled endpoints
+- No manual configuration required
+- Environment switching is disabled (prevents accidental misconfiguration)
+- All API calls route to your organization's infrastructure
+
+### User Override
+
+Users **cannot** override bundled endpoints through the UI. The bundled configuration takes absolute precedence. This ensures:
+- Consistent configuration across the organization
+- No accidental connections to external services
+- Simplified deployment and support
+
+If users have a `~/.cline/endpoints.json` file, it will be ignored when bundled configuration is present.
+
+## Troubleshooting
+
+### Invalid Configuration Error
+
+If users see an error about invalid configuration on startup:
+
+```
+ClineConfigurationError: Invalid JSON in bundled endpoints configuration file
+```
+
+**Solution**: The bundled `endpoints.json` is malformed. Repackage with a valid JSON file.
+
+### Missing Required Field Error
+
+```
+ClineConfigurationError: Missing required field "apiBaseUrl" in endpoints configuration file
+```
+
+**Solution**: Ensure all three required fields are present in `endpoints.json`.
+
+### Invalid URL Error
+
+```
+ClineConfigurationError: Field "appBaseUrl" must be a valid URL. Got: "not-a-url"
+```
+
+**Solution**: All URLs must start with `http://` or `https://`.
+
+## Security Considerations
+
+1. **Bundle Validation**: The packaging scripts validate JSON structure and required fields
+2. **Read-Only Configuration**: Users cannot modify bundled endpoints through the UI
+3. **Self-Hosted Mode**: Automatic switch to self-hosted mode prevents external connections
+4. **Audit Trail**: All endpoint access is logged with configuration source
+
+## Updating Endpoints
+
+To update endpoints for existing installations:
+
+1. Create updated `endpoints.json`
+2. Repackage the same Cline version with new endpoints
+3. Distribute updated package
+4. Users reinstall/update the package
+
+The version number remains the same since only configuration changed, not the Cline code.
+
+## Support
+
+For questions or issues with bundled endpoints:
+
+1. Verify your `endpoints.json` is valid JSON with all required fields
+2. Check that URLs are accessible from user networks
+3. Review Cline logs for configuration loading messages
+4. Contact your Cline support representative for assistance
+
+## Example: Complete Workflow
+
+Here's a complete example for VSCode deployment:
+
+```bash
+# 1. Download official release
+curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-3.55.0.vsix
+
+# 2. Create endpoints configuration
+cat > endpoints.json << 'EOF'
+{
+  "appBaseUrl": "https://cline.acme.internal",
+  "apiBaseUrl": "https://cline-api.acme.internal",
+  "mcpBaseUrl": "https://cline-api.acme.internal/v1/mcp"
+}
+EOF
+
+# 3. Validate JSON
+jq empty endpoints.json  # Should succeed silently
+
+# 4. Run packaging script
+./scripts/add-endpoints-to-vsix.sh \
+  cline-3.55.0.vsix \
+  cline-3.55.0-acme.vsix \
+  endpoints.json
+
+# 5. Verify output
+unzip -l cline-3.55.0-acme.vsix | grep endpoints.json
+# Should show: extension/endpoints.json
+
+# 6. Test installation (on test machine)
+code --install-extension cline-3.55.0-acme.vsix
+
+# 7. Distribute to organization
+# Upload to internal package repository
+# or distribute via configuration management system
+```
+
+## Changelog
+
+- **v3.55.0**: Initial release of bundled endpoints support
@@ -0,0 +1,105 @@
+---
+title: "Choosing Your Configuration Path"
+sidebarTitle: "Deployment Guide"
+description: "Decide between SaaS and Self-Hosted configuration for your Cline Enterprise deployment"
+---
+
+Choose the right configuration approach for your organization. Most teams start with SaaS for quick deployment, while enterprises with complex requirements opt for self-hosted infrastructure.
+
+## Configuration Paths
+
+<CardGroup cols={2}>
+  <Card title="SaaS Provider Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
+    ### Quick Setup via Web Console
+    
+    ✅ No infrastructure required  
+    ✅ 5-10 minute configuration  
+    ✅ Web-based admin console  
+    ✅ Automatic updates  
+    ✅ Simplified credential management
+    
+    **Best for:**
+    - Small to medium teams (5-50 developers)
+    - Quick deployment needs
+    - Limited DevOps resources
+    - Standard security requirements
+    - Single region deployments
+  </Card>
+  
+  <Card title="Self-Hosted Configuration" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
+    ### Full Infrastructure Control
+    
+    ✅ Your own AWS/GCP/K8s  
+    ✅ VPC endpoints & private connectivity  
+    ✅ Multi-account setups  
+    ✅ Advanced compliance & audit  
+    ✅ GitOps workflows
+    
+    **Best for:**
+    - Large enterprises (50+ developers)
+    - Complex security requirements
+    - Existing cloud infrastructure
+    - Multi-region deployments
+    - Custom compliance needs
+  </Card>
+</CardGroup>
+
+## Detailed Comparison
+
+### Feature Comparison
+
+| Feature | SaaS | Self-Hosted |
+|---------|------|-------------|
+| **Configuration** | Web UI | YAML + Helm/Kubernetes |
+| **Infrastructure** | None required | Full AWS/GCP/K8s |
+| **VPC Endpoints** | Basic | Full private connectivity |
+| **Multi-Account** | ❌ | ✅ |
+| **IAM** | Standard RBAC roles | Standard RBAC roles |
+| **Compliance** | Standard | Custom frameworks |
+| **GitOps** | ❌ | ✅ |
+| **Maintenance** | Managed by Cline | Self-managed |
+| **Updates** | Automatic (extension) | Automatic (extension) + Infrastructure control |
+
+### Security & Compliance
+
+| Capability | SaaS | Self-Hosted |
+|------------|------|-------------|
+| **Network Encryption** | HTTPS/TLS | HTTPS/TLS |
+| **Network** | Public internet | Private VPC endpoints |
+| **Access Control** | Standard RBAC | Standard RBAC |
+| **Audit Logs** | OpenTelemetry traces | OpenTelemetry traces + Infrastructure logs |
+| **Data Residency** | Cline-managed deployment | Customer-controlled deployment |
+
+### Cost Structure
+
+| Cost Category | SaaS | Self-Hosted |
+|---------------|------|-------------|
+| **Cline Subscription** | Fixed enterprise fee | Fixed enterprise fee |
+| **Inference Provider Costs** | Usage-based | Usage-based |
+| **Infrastructure** | ✅ None required | Kubernetes, networking, storage |
+| **Personnel** | ✅ None required | DevOps team needed |
+| **Total Cost Profile** | Predictable and simple | Variable based on scale |
+
+## Migration Path
+
+<Note>
+Most organizations start with SaaS configuration for quick deployment, then migrate to self-hosted later as requirements grow. This minimizes risk and ensures your infrastructure meets actual usage patterns.
+</Note>
+
+## Getting Started
+
+<CardGroup cols={2}>
+  <Card title="Start with SaaS" icon="rocket" href="/enterprise-solutions/configuration/remote-configuration/overview">
+    Begin with quick SaaS setup
+  </Card>
+  
+  <Card title="Deploy Self-Hosted" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
+    Plan your infrastructure deployment
+  </Card>
+</CardGroup>
+
+## Need Help Deciding?
+
+- [**Contact Cline Enterprise Sales**](https://cline.bot/contact-sales) for a consultation on your specific requirements
+- [**Start with SaaS**](/enterprise-solutions/configuration/remote-configuration/overview) if unsure - it's lower risk and you can always migrate later
+- [**Review Self-Hosted Requirements**](/enterprise-solutions/configuration/infrastructure-configuration/overview) if you have existing infrastructure that could benefit from self-hosted deployment
@@ -0,0 +1,35 @@
+---
+title: "Overview"
+sidebarTitle: "Overview"
+description: "Configure Cline settings for your enterprise deployment"
+---
+
+This section covers configuration options for controlling Cline's behavior in enterprise deployments.
+
+## Available Settings
+
+<Card title="YOLO Mode" icon="rocket" href="/enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/yolo-mode">
+  Control enterprise access to autonomous operation mode with complete auto-approval
+</Card>
+
+## Configuration Methods
+
+These settings can be configured through:
+
+
+### Individual Users
+- Users can toggle settings in their local Cline interface
+- Enterprise policies can restrict certain settings
+- Changes apply immediately to new tasks
+
+## Enterprise Controls
+
+Administrators can enforce policies through remote configuration:
+
+```json
+{
+  "yoloModeAllowed": false
+}
+```
+
+When `yoloModeAllowed` is set to `false`, users cannot enable YOLO Mode in their local Cline interface.
@@ -0,0 +1,565 @@
+---
+title: "MCP Marketplace"
+sidebarTitle: "MCP Marketplace"
+description: "Deploy pre-built enterprise MCP servers from the Cline marketplace with one-click configuration"
+---
+
+The MCP Marketplace provides curated, enterprise-ready integrations with popular development tools and services. All marketplace servers are built with enterprise security, compliance, and scalability in mind.
+
+## Enterprise Marketplace Benefits
+
+<CardGroup cols={2}>
+  <Card title="One-Click Deployment" icon="rocket">
+    Deploy complex integrations instantly with pre-configured enterprise settings.
+  </Card>
+  
+  <Card title="Security Hardened" icon="shield-check">
+    All servers include enterprise security features, audit logging, and compliance controls.
+  </Card>
+  
+  <Card title="Maintained & Updated" icon="sync">
+    Regular security updates and feature enhancements managed by Cline Enterprise team.
+  </Card>
+  
+  <Card title="Enterprise Support" icon="headset">
+    Dedicated support channels for marketplace integration issues and customization.
+  </Card>
+</CardGroup>
+
+## Available Integrations
+
+### Development Tools
+
+<CardGroup cols={3}>
+  <Card title="GitHub Enterprise" icon="github">
+    Repository management, issue tracking, PR workflows, and code analysis
+  </Card>
+  
+  <Card title="GitLab Enterprise" icon="gitlab">
+    Project management, CI/CD pipelines, merge requests, and security scanning
+  </Card>
+  
+  <Card title="Bitbucket Enterprise" icon="bitbucket">  
+    Source code management, build pipelines, and deployment automation
+  </Card>
+</CardGroup>
+
+### Project Management
+
+<CardGroup cols={3}>
+  <Card title="Jira Enterprise" icon="jira">
+    Issue tracking, sprint management, custom fields, and workflow automation
+  </Card>
+  
+  <Card title="Azure DevOps" icon="microsoft">
+    Work items, boards, repos, pipelines, and test management
+  </Card>
+  
+  <Card title="Linear" icon="linear">
+    Issue tracking, project planning, and development workflow integration
+  </Card>
+</CardGroup>
+
+### Communication & Collaboration
+
+<CardGroup cols={3}>
+  <Card title="Slack Enterprise Grid" icon="slack">
+    Notifications, bot interactions, file sharing, and workflow automation
+  </Card>
+  
+  <Card title="Microsoft Teams" icon="microsoft-teams">
+    Chat notifications, meeting integration, and collaborative workflows
+  </Card>
+  
+  <Card title="Discord" icon="discord">
+    Community management, bot interactions, and developer notifications
+  </Card>
+</CardGroup>
+
+### Cloud Services
+
+<CardGroup cols={3}>
+  <Card title="AWS Services" icon="aws">
+    EC2, S3, Lambda, RDS, CloudWatch, and other AWS service integrations
+  </Card>
+  
+  <Card title="Google Cloud" icon="google-cloud">
+    Compute Engine, Cloud Storage, BigQuery, and GCP service management
+  </Card>
+  
+  <Card title="Azure Services" icon="azure">
+    Virtual Machines, Storage Accounts, Functions, and Azure resource management
+  </Card>
+</CardGroup>
+
+## Installing Marketplace Servers
+
+### Via Cline Enterprise Dashboard
+
+1. **Access Marketplace**: Navigate to `Settings > Enterprise > MCP Marketplace`
+2. **Browse Integrations**: Filter by category, popularity, or search by name
+3. **Review Details**: Check compatibility, permissions, and configuration requirements
+4. **Install**: Click "Install" and configure required settings
+5. **Deploy**: Approve deployment to your selected environment
+
+### Via Configuration File
+
+Install marketplace servers through enterprise configuration:
+
+```yaml
+# enterprise-mcp-config.yaml
+mcp:
+  marketplace_servers:
+    - name: "github-enterprise"
+      package: "@cline/mcp-github-enterprise"
+      version: "2.1.0"
+      environment: "production"
+      
+      config:
+        github:
+          base_url: "https://github.company.com/api/v3"
+          token: "${GITHUB_ENTERPRISE_TOKEN}"
+          organization: "company"
+          
+        features:
+          issue_management: true
+          pull_request_automation: true
+          code_analysis: true
+          security_scanning: true
+          
+        permissions:
+          repositories: "read-write"
+          issues: "write"
+          pull_requests: "write"
+          
+        compliance:
+          audit_logging: true
+          data_retention_days: 365
+          encryption_at_rest: true
+          
+    - name: "jira-enterprise"
+      package: "@cline/mcp-jira-enterprise"
+      version: "1.8.3"
+      environment: "production"
+      
+      config:
+        jira:
+          base_url: "https://company.atlassian.net"
+          username: "${JIRA_USERNAME}"
+          api_token: "${JIRA_API_TOKEN}"
+          
+        projects:
+          - key: "DEV"
+            permissions: ["read", "write", "transition"]
+          - key: "OPS"
+            permissions: ["read", "comment"]
+            
+        compliance:
+          field_encryption: ["description", "comments"]
+          audit_trail: true
+```
+
+### Via CLI
+
+Deploy using the Cline Enterprise CLI:
+
+```bash
+# Install GitHub Enterprise integration
+cline-enterprise mcp install github-enterprise \
+  --version 2.1.0 \
+  --config-file github-config.yaml \
+  --environment production
+
+# Install Slack Enterprise Grid integration  
+cline-enterprise mcp install slack-enterprise-grid \
+  --version 1.5.2 \
+  --config workspace_id=T1234567890 \
+  --config bot_token=${SLACK_BOT_TOKEN} \
+  --environment production
+
+# List installed marketplace servers
+cline-enterprise mcp list --environment production
+
+# Check server status
+cline-enterprise mcp status github-enterprise --environment production
+```
+
+## Configuration Examples
+
+### GitHub Enterprise Integration
+
+```yaml
+# github-enterprise-config.yaml
+github:
+  base_url: "https://github.company.com/api/v3"
+  token: "${GITHUB_ENTERPRISE_TOKEN}"
+  organization: "company"
+  
+  # Repository access controls
+  repositories:
+    allowed_patterns:
+      - "company/*"
+      - "internal/*"
+    blocked_patterns:
+      - "*/secrets"
+      - "*/private-keys"
+      
+  # Feature configuration
+  features:
+    issue_management:
+      enabled: true
+      auto_assign: true
+      labels:
+        - "ai-generated"
+        - "cline-task"
+        
+    pull_requests:
+      enabled: true
+      auto_review_request: true
+      required_approvals: 2
+      enforce_branch_protection: true
+      
+    code_analysis:
+      enabled: true
+      languages: ["typescript", "python", "go", "rust"]
+      security_scan: true
+      
+  # Security and compliance
+  security:
+    webhook_secret: "${GITHUB_WEBHOOK_SECRET}"
+    rate_limiting:
+      requests_per_hour: 5000
+      burst_limit: 100
+    ip_whitelist:
+      - "10.0.0.0/8"
+      - "192.168.0.0/16"
+      
+  audit:
+    log_level: "INFO"
+    include_payloads: false
+    retention_days: 365
+    destinations: ["datadog", "splunk"]
+```
+
+### Jira Enterprise Integration
+
+```yaml
+# jira-enterprise-config.yaml
+jira:
+  base_url: "https://company.atlassian.net"
+  username: "${JIRA_USERNAME}"
+  api_token: "${JIRA_API_TOKEN}"
+  
+  # Project access configuration
+  projects:
+    - key: "DEV"
+      name: "Development"
+      permissions: ["read", "write", "transition", "assign"]
+      issue_types: ["Story", "Bug", "Task", "Subtask"]
+      
+    - key: "OPS"
+      name: "Operations"  
+      permissions: ["read", "comment", "watch"]
+      
+  # Custom field mappings
+  custom_fields:
+    story_points: "customfield_10002"
+    epic_link: "customfield_10014"
+    sprint: "customfield_10020"
+    
+  # Workflow automation
+  automation:
+    auto_transition:
+      enabled: true
+      rules:
+        - from_status: "To Do"
+          to_status: "In Progress"
+          condition: "assignee_changed"
+          
+    auto_assign:
+      enabled: true
+      rules:
+        - issue_type: "Bug"
+          component: "Frontend"
+          assignee: "frontend-team-lead"
+          
+  # Security and compliance
+  security:
+    encrypt_fields: ["description", "comment"]
+    mask_sensitive_data: true
+    audit_changes: true
+    
+  compliance:
+    gdpr_compliant: true
+    data_retention_policy: "365_days"
+    audit_log_retention: "7_years"
+```
+
+### Slack Enterprise Grid Integration
+
+```yaml
+# slack-enterprise-config.yaml
+slack:
+  workspace_id: "T1234567890"
+  bot_token: "${SLACK_BOT_TOKEN}"
+  signing_secret: "${SLACK_SIGNING_SECRET}"
+  
+  # Channel management
+  channels:
+    notifications:
+      - name: "#dev-alerts"
+        types: ["deployments", "errors", "security"]
+      - name: "#ai-activity"
+        types: ["cline-tasks", "completions"]
+        
+    private_channels:
+      - name: "#security-incidents"
+        members: ["security-team"]
+        types: ["security-alerts", "compliance-issues"]
+        
+  # Bot behavior
+  bot:
+    display_name: "Cline Enterprise"
+    default_channel: "#general"
+    response_delay_ms: 1000
+    
+    commands:
+      - command: "/cline-status"
+        description: "Check Cline Enterprise status"
+        permission: "all"
+        
+      - command: "/cline-deploy"
+        description: "Trigger deployment"
+        permission: "admin"
+        
+  # Enterprise features
+  enterprise:
+    app_approval_required: true
+    data_residency: "US"
+    compliance_export: true
+    
+    dlp:
+      enabled: true
+      scan_messages: true
+      block_sensitive_data: true
+      
+  # Security settings
+  security:
+    require_app_approval: true
+    audit_api_calls: true
+    encrypt_messages: true
+    retain_audit_logs_days: 2555  # 7 years
+```
+
+## Enterprise Management
+
+### Multi-Environment Deployment
+
+Deploy marketplace servers across environments:
+
+```yaml
+# environments-config.yaml
+environments:
+  development:
+    marketplace_servers:
+      - github-enterprise:
+          version: "2.1.0-beta"
+          config_override:
+            github:
+              base_url: "https://github-dev.company.com/api/v3"
+              organization: "company-dev"
+              
+  staging:
+    marketplace_servers:
+      - github-enterprise:
+          version: "2.1.0-rc1"  
+          config_override:
+            github:
+              base_url: "https://github-staging.company.com/api/v3"
+              organization: "company-staging"
+              
+  production:
+    marketplace_servers:
+      - github-enterprise:
+          version: "2.1.0"
+          config_override:
+            github:
+              base_url: "https://github.company.com/api/v3"
+              organization: "company"
+```
+
+### Version Management
+
+Control marketplace server versions:
+
+```bash
+# List available versions
+cline-enterprise mcp versions github-enterprise
+
+# Upgrade to latest version
+cline-enterprise mcp upgrade github-enterprise --version 2.2.0 --environment staging
+
+# Rollback to previous version
+cline-enterprise mcp rollback github-enterprise --version 2.1.0 --environment staging
+
+# Pin to specific version (disable auto-updates)
+cline-enterprise mcp pin github-enterprise --version 2.1.0
+```
+
+### Health Monitoring
+
+Monitor marketplace server health:
+
+```yaml
+# monitoring-config.yaml
+monitoring:
+  marketplace_servers:
+    health_checks:
+      interval_seconds: 30
+      timeout_seconds: 10
+      
+    metrics:
+      - server_status
+      - request_latency
+      - error_rate
+      - resource_usage
+      
+    alerts:
+      - name: "marketplace-server-down"
+        condition: "server_status != 1"
+        severity: "critical"
+        
+      - name: "high-error-rate"
+        condition: "error_rate > 0.05"  
+        severity: "warning"
+        
+      - name: "performance-degradation"
+        condition: "request_latency > 5s"
+        severity: "warning"
+```
+
+## Security & Compliance
+
+### Enterprise Security Features
+
+All marketplace servers include:
+
+- **Authentication Integration**: SSO, SAML, OAuth2 support
+- **Authorization Controls**: RBAC and fine-grained permissions
+- **Audit Logging**: Comprehensive activity tracking
+- **Data Encryption**: At-rest and in-transit encryption
+- **Network Security**: VPN, IP whitelisting, private endpoints
+- **Compliance**: SOC2, GDPR, HIPAA compliance frameworks
+
+### Data Governance
+
+Configure data handling policies:
+
+```yaml
+# data-governance-config.yaml
+data_governance:
+  classification:
+    public:
+      retention_days: 90
+      backup_required: false
+      
+    internal:
+      retention_days: 365
+      backup_required: true
+      encryption_required: false
+      
+    confidential:
+      retention_days: 2555  # 7 years
+      backup_required: true
+      encryption_required: true
+      audit_access: true
+      
+    restricted:
+      retention_days: 2555
+      backup_required: true  
+      encryption_required: true
+      audit_access: true
+      approval_required: true
+      
+  privacy:
+    pii_detection: true
+    pii_masking: true
+    gdpr_compliance: true
+    data_subject_requests: true
+    
+  compliance:
+    frameworks: ["SOC2", "GDPR", "CCPA", "HIPAA"]
+    audit_frequency: "quarterly"
+    certification_renewal: "annual"
+```
+
+## Best Practices
+
+### Installation
+1. **Review Permissions**: Always review required permissions before installation
+2. **Test in Staging**: Deploy to staging environment first
+3. **Configuration Validation**: Validate configuration files before deployment
+4. **Backup Current State**: Create configuration backups before changes
+5. **Monitor Deployment**: Watch health metrics during rollout
+
+### Configuration  
+1. **Environment Separation**: Use different configurations per environment
+2. **Secret Management**: Store sensitive data in secure secret stores
+3. **Version Pinning**: Pin versions for production deployments
+4. **Access Controls**: Implement least-privilege access policies
+5. **Regular Updates**: Schedule regular security and feature updates
+
+### Monitoring
+1. **Health Checks**: Monitor server health continuously
+2. **Performance Metrics**: Track latency and throughput
+3. **Error Tracking**: Alert on error rates and failure patterns
+4. **Resource Usage**: Monitor CPU, memory, and network usage
+5. **Audit Reviews**: Regular review of audit logs and access patterns
+
+## Troubleshooting
+
+### Common Issues
+
+**Installation Failures**:
+```bash
+# Check marketplace connectivity
+cline-enterprise mcp marketplace-status
+
+# Verify authentication
+cline-enterprise auth verify --service marketplace
+
+# Check installation logs
+cline-enterprise logs mcp-installer --lines 100
+```
+
+**Configuration Errors**:
+```bash
+# Validate configuration
+cline-enterprise mcp validate-config --file config.yaml
+
+# Test connectivity 
+cline-enterprise mcp test-connection github-enterprise --environment staging
+
+# Check server status
+cline-enterprise mcp status --all
+```
+
+**Performance Issues**:
+```bash
+# Check server metrics
+cline-enterprise mcp metrics github-enterprise --duration 1h
+
+# View recent error logs
+cline-enterprise logs github-enterprise --level error --lines 50
+```
+
+## Support
+
+For marketplace server issues:
+
+- **Documentation**: Check server-specific documentation in the dashboard
+- **Community**: Join the Cline Enterprise community forum
+- **Support Tickets**: Create support tickets for critical issues
+- **Professional Services**: Engage professional services for custom configurations
+
+Enterprise customers have access to dedicated support channels with SLA guarantees.
@@ -0,0 +1,571 @@
+---
+title: "MCP Integration"
+sidebarTitle: "Overview"
+description: "Configure Model Context Protocol (MCP) servers and marketplace integrations for enterprise Cline deployments"
+---
+
+Model Context Protocol (MCP) provides standardized communication between AI models and external data sources, tools, and services. Enterprise MCP integration allows you to securely connect Cline to your organization's systems while maintaining governance and compliance.
+
+## Enterprise MCP Benefits
+
+<CardGroup cols={2}>
+  <Card title="Extensible Architecture" icon="puzzle-piece">
+    Connect to unlimited external tools, databases, APIs, and services through standardized MCP servers.
+  </Card>
+  
+  <Card title="Enterprise Security" icon="shield-alt">
+    Secure authentication, authorization, and audit trails for all MCP server communications.
+  </Card>
+  
+  <Card title="Centralized Management" icon="network-wired">
+    Manage and deploy MCP servers enterprise-wide with version control and configuration management.
+  </Card>
+  
+  <Card title="Compliance Ready" icon="clipboard-check">
+    Built-in logging, monitoring, and data governance for regulatory compliance requirements.
+  </Card>
+</CardGroup>
+
+## MCP Architecture Overview
+
+```mermaid
+graph TB
+    A[Cline Enterprise] --> B[MCP Hub]
+    B --> C[MCP Marketplace]
+    B --> D[Remote MCP Servers]
+    B --> E[Internal MCP Servers]
+    
+    C --> F[GitHub Integration]
+    C --> G[Slack Integration] 
+    C --> H[Jira Integration]
+    
+    D --> I[Custom APIs]
+    D --> J[Databases]
+    D --> K[Cloud Services]
+    
+    E --> L[Internal Tools]
+    E --> M[Legacy Systems]
+    E --> N[Security Systems]
+    
+    O[Enterprise Admin] --> B
+    P[Audit Logging] --> B
+    Q[Authentication] --> B
+```
+
+## Core Components
+
+<CardGroup cols={2}>
+  <Card title="MCP Marketplace" icon="store" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace">
+    Pre-built, enterprise-ready MCP servers for popular tools and services with one-click deployment.
+  </Card>
+  
+  <Card title="Remote MCP Servers" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers">
+    Deploy and manage custom MCP servers across your infrastructure with centralized configuration.
+  </Card>
+</CardGroup>
+
+## Enterprise Configuration
+
+### Basic MCP Hub Setup
+
+Configure the central MCP hub for your enterprise deployment:
+
+```yaml
+# mcp-hub-config.yaml
+mcp:
+  hub:
+    enabled: true
+    port: 8080
+    authentication:
+      method: "enterprise-sso"
+      jwt_secret: "${MCP_JWT_SECRET}"
+      
+    # Server discovery
+    discovery:
+      methods: ["marketplace", "remote", "local"]
+      marketplace_url: "https://mcp.cline.bot/marketplace"
+      
+    # Security settings
+    security:
+      enforce_tls: true
+      allowed_origins: ["https://*.company.com"]
+      rate_limiting:
+        requests_per_minute: 1000
+        burst_size: 100
+        
+    # Audit and compliance
+    audit:
+      enabled: true
+      log_level: "INFO"
+      destinations: ["file", "syslog", "datadog"]
+      retention_days: 90
+```
+
+### Multi-Environment Configuration
+
+Deploy MCP configurations across environments:
+
+<Tabs>
+<Tab title="Development">
+```yaml
+# mcp-dev-config.yaml
+mcp:
+  environment: "development"
+  
+  servers:
+    - name: "github-dev"
+      type: "marketplace"
+      package: "@cline/mcp-github"
+      version: "latest"
+      config:
+        github_token: "${GITHUB_DEV_TOKEN}"
+        org: "company-dev"
+        
+    - name: "local-db"
+      type: "remote" 
+      url: "http://localhost:3001"
+      auth:
+        type: "api-key"
+        key: "${DEV_DB_API_KEY}"
+        
+  policies:
+    allow_experimental: true
+    auto_update: true
+    rate_limits:
+      relaxed: true
+```
+</Tab>
+
+<Tab title="Production">
+```yaml
+# mcp-prod-config.yaml
+mcp:
+  environment: "production"
+  
+  servers:
+    - name: "github-prod"
+      type: "marketplace"
+      package: "@cline/mcp-github"
+      version: "1.2.3"  # Pinned version
+      config:
+        github_token: "${GITHUB_PROD_TOKEN}"
+        org: "company"
+        
+    - name: "crm-integration"
+      type: "remote"
+      url: "https://mcp-crm.internal.company.com"
+      auth:
+        type: "mtls"
+        cert_path: "/certs/mcp-client.pem"
+        key_path: "/certs/mcp-client-key.pem"
+        
+    - name: "security-scanner"
+      type: "remote"
+      url: "https://security-mcp.company.com"
+      auth:
+        type: "oauth2"
+        client_id: "${SECURITY_CLIENT_ID}"
+        client_secret: "${SECURITY_CLIENT_SECRET}"
+        
+  policies:
+    allow_experimental: false
+    auto_update: false
+    strict_versioning: true
+    
+  monitoring:
+    metrics: true
+    health_checks: true
+    alert_on_failure: true
+```
+</Tab>
+</Tabs>
+
+## Server Management
+
+### Lifecycle Management
+
+Manage MCP server deployments with GitOps:
+
+```yaml
+# mcp-server-manifest.yaml
+apiVersion: mcp.cline.bot/v1
+kind: MCPServer
+metadata:
+  name: custom-api-server
+  namespace: cline-enterprise
+spec:
+  image: company/custom-mcp-server:v1.0.0
+  replicas: 3
+  
+  config:
+    api_endpoint: "https://api.internal.company.com"
+    timeout: 30s
+    retry_attempts: 3
+    
+  auth:
+    type: service-account
+    service_account: mcp-custom-api
+    
+  resources:
+    requests:
+      memory: "256Mi"
+      cpu: "100m"
+    limits:
+      memory: "512Mi" 
+      cpu: "500m"
+      
+  monitoring:
+    enabled: true
+    metrics_port: 9090
+    health_endpoint: "/health"
+    
+  security:
+    network_policy: strict
+    pod_security_standard: restricted
+```
+
+### Configuration Management
+
+Use Helm charts for enterprise MCP deployments:
+
+```yaml
+# values-prod.yaml
+mcp:
+  hub:
+    replicaCount: 3
+    image:
+      repository: cline/mcp-hub-enterprise
+      tag: "1.5.2"
+      
+  servers:
+    marketplace:
+      enabled: true
+      catalog_url: "https://enterprise-catalog.company.com"
+      
+    custom:
+      - name: "salesforce"
+        enabled: true
+        image: "company/mcp-salesforce:1.0.0"
+        config:
+          instance_url: "https://company.my.salesforce.com"
+          
+      - name: "jira"
+        enabled: true
+        image: "company/mcp-jira:2.1.0"
+        config:
+          base_url: "https://company.atlassian.net"
+          
+  ingress:
+    enabled: true
+    className: nginx
+    annotations:
+      cert-manager.io/cluster-issuer: "letsencrypt-prod"
+    hosts:
+      - host: mcp.company.com
+        paths:
+          - path: /
+            pathType: Prefix
+    tls:
+      - secretName: mcp-tls
+        hosts:
+          - mcp.company.com
+```
+
+## Security & Governance
+
+### Authentication & Authorization
+
+Configure enterprise authentication for MCP servers:
+
+```yaml
+# mcp-auth-config.yaml
+authentication:
+  providers:
+    - name: "enterprise-sso"
+      type: "oidc"
+      issuer: "https://sso.company.com"
+      client_id: "${SSO_CLIENT_ID}"
+      client_secret: "${SSO_CLIENT_SECRET}"
+      
+    - name: "service-accounts"
+      type: "jwt"
+      signing_key: "${SERVICE_ACCOUNT_KEY}"
+      
+authorization:
+  policies:
+    - name: "developers"
+      subjects: ["group:developers"]
+      resources: ["mcp:servers:read", "mcp:servers:execute"]
+      
+    - name: "admins"
+      subjects: ["group:mcp-admins"]
+      resources: ["mcp:*"]
+      
+    - name: "security-team"
+      subjects: ["group:security"]
+      resources: ["mcp:audit:*", "mcp:servers:security-*"]
+      
+  rbac:
+    enabled: true
+    default_role: "viewer"
+```
+
+### Network Security
+
+Implement network policies for MCP communications:
+
+```yaml
+# mcp-network-policy.yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: mcp-server-policy
+  namespace: cline-enterprise
+spec:
+  podSelector:
+    matchLabels:
+      app: mcp-server
+  policyTypes:
+    - Ingress
+    - Egress
+    
+  ingress:
+    - from:
+        - namespaceSelector:
+            matchLabels:
+              name: cline-enterprise
+        - podSelector:
+            matchLabels:
+              app: cline-core
+      ports:
+        - protocol: TCP
+          port: 8080
+          
+  egress:
+    # Allow DNS
+    - to: []
+      ports:
+        - protocol: UDP
+          port: 53
+    # Allow HTTPS to external APIs
+    - to: []
+      ports:
+        - protocol: TCP
+          port: 443
+```
+
+## Monitoring & Observability
+
+### Metrics Collection
+
+Configure comprehensive MCP monitoring:
+
+```yaml
+# mcp-monitoring.yaml
+monitoring:
+  metrics:
+    enabled: true
+    interval: 30s
+    
+    collectors:
+      - name: "server-health"
+        metrics:
+          - mcp_server_status
+          - mcp_server_response_time
+          - mcp_server_error_rate
+          
+      - name: "hub-performance"
+        metrics:
+          - mcp_hub_requests_total
+          - mcp_hub_request_duration
+          - mcp_hub_active_connections
+          
+      - name: "resource-usage"
+        metrics:
+          - mcp_memory_usage
+          - mcp_cpu_usage
+          - mcp_network_io
+          
+  alerts:
+    - name: "server-down"
+      condition: "mcp_server_status == 0"
+      severity: "critical"
+      notification_channels: ["pagerduty", "slack"]
+      
+    - name: "high-error-rate"
+      condition: "mcp_server_error_rate > 0.05"
+      severity: "warning"
+      notification_channels: ["slack"]
+      
+    - name: "performance-degradation"
+      condition: "mcp_server_response_time > 5s"
+      severity: "warning"
+      notification_channels: ["email"]
+```
+
+### Audit Logging
+
+Implement comprehensive audit trails:
+
+```json
+{
+  "timestamp": "2024-01-15T10:30:00Z",
+  "event_type": "mcp_server_call",
+  "user_id": "john.doe@company.com",
+  "session_id": "sess_abc123",
+  "server_name": "github-prod",
+  "method": "github.create_issue",
+  "request": {
+    "repository": "company/project",
+    "title": "Bug fix required",
+    "sensitive_data_detected": false
+  },
+  "response": {
+    "status": "success",
+    "issue_id": "12345",
+    "duration_ms": 234
+  },
+  "compliance": {
+    "data_classification": "internal",
+    "retention_required": true,
+    "pii_detected": false
+  }
+}
+```
+
+## Custom MCP Server Development
+
+### Development Framework
+
+Create custom MCP servers using the enterprise SDK:
+
+```typescript
+// custom-mcp-server.ts
+import { MCPServer, Tool, Resource } from '@cline/mcp-enterprise-sdk';
+
+class CustomAPIServer extends MCPServer {
+  constructor() {
+    super({
+      name: 'custom-api-server',
+      version: '1.0.0',
+      description: 'Custom API integration server'
+    });
+    
+    this.addTool(new DatabaseQueryTool());
+    this.addResource(new UserDataResource());
+  }
+}
+
+class DatabaseQueryTool implements Tool {
+  name = 'query_database';
+  description = 'Query the company database';
+  
+  async execute(params: any) {
+    // Implement database query logic
+    const result = await this.database.query(params.sql);
+    
+    // Audit log the query
+    await this.auditLog({
+      action: 'database_query',
+      query: params.sql,
+      user: params.user_id,
+      results_count: result.length
+    });
+    
+    return result;
+  }
+  
+  async validate(params: any): Promise<boolean> {
+    // Implement query validation
+    return params.sql && !this.containsMaliciousSQL(params.sql);
+  }
+}
+```
+
+### Deployment Pipeline
+
+Automate MCP server deployments:
+
+```yaml
+# .github/workflows/deploy-mcp-server.yml
+name: Deploy MCP Server
+on:
+  push:
+    branches: [main]
+    paths: ['mcp-servers/**']
+    
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      
+      - name: Build MCP Server
+        run: |
+          docker build -t company/mcp-server:${{ github.sha }} .
+          docker push company/mcp-server:${{ github.sha }}
+          
+      - name: Deploy to Staging
+        run: |
+          helm upgrade mcp-server-staging ./helm-chart \
+            --set image.tag=${{ github.sha }} \
+            --namespace mcp-staging
+            
+      - name: Run Integration Tests
+        run: |
+          kubectl wait --for=condition=ready pod -l app=mcp-server -n mcp-staging
+          npm run test:integration
+          
+      - name: Deploy to Production
+        if: success()
+        run: |
+          helm upgrade mcp-server-prod ./helm-chart \
+            --set image.tag=${{ github.sha }} \
+            --namespace mcp-prod
+```
+
+## Best Practices
+
+### Security
+1. **Authentication**: Always require authentication for MCP servers
+2. **Encryption**: Use TLS for all MCP communications
+3. **Validation**: Validate all inputs and sanitize outputs
+4. **Least Privilege**: Grant minimal required permissions
+5. **Audit**: Log all MCP server interactions
+
+### Performance
+1. **Caching**: Implement response caching where appropriate
+2. **Connection Pooling**: Reuse connections to external services
+3. **Async Operations**: Use non-blocking operations for I/O
+4. **Resource Limits**: Set appropriate CPU and memory limits
+5. **Load Balancing**: Scale MCP servers based on demand
+
+### Reliability
+1. **Health Checks**: Implement comprehensive health endpoints
+2. **Circuit Breakers**: Fail fast when external services are down
+3. **Retry Logic**: Implement exponential backoff for failures
+4. **Graceful Degradation**: Provide fallback behavior
+5. **Monitoring**: Set up proactive alerting and monitoring
+
+## Production Checklist
+
+Before deploying MCP servers to production:
+
+- [ ] Security review completed
+- [ ] Authentication and authorization configured
+- [ ] Network policies implemented
+- [ ] Monitoring and alerting set up
+- [ ] Audit logging enabled
+- [ ] Resource limits configured
+- [ ] Health checks implemented
+- [ ] Integration tests passing
+- [ ] Disaster recovery plan documented
+- [ ] Compliance requirements validated
+
+## Getting Started
+
+Ready to implement enterprise MCP integration? Start with:
+
+1. [MCP Marketplace](/enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace) - Deploy pre-built integrations
+2. [Remote MCP Servers](/enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers) - Configure custom servers
+3. Review our [MCP Development Guide](/mcp/mcp-overview) for building custom integrations
@@ -0,0 +1,95 @@
+---
+title: "Self-Hosted Configuration"
+sidebarTitle: "Overview"
+description: "Deploy and configure Cline on your own infrastructure with enterprise-grade security and compliance"
+---
+
+<Warning>
+**Self-Hosted Configuration Path**
+
+This section is for enterprises deploying **self-hosted Cline infrastructure** with complex security, compliance, and multi-environment requirements. Configuration is done through YAML files, Kubernetes/Helm deployments, and infrastructure-as-code.
+
+**Looking for simple setup?** See [SaaS Provider Configuration](/enterprise-solutions/configuration/remote-configuration/overview) for quick configuration through the app.cline.bot admin console - no infrastructure deployment required, just web-based settings.
+</Warning>
+
+Self-Hosted Configuration provides centralized control over all aspects of your Cline deployment on your own infrastructure, from AI providers to custom workflows. This section covers how to configure, manage, and optimize your enterprise Cline installation with advanced security, compliance, and operational features.
+
+## Configuration Categories
+
+<CardGroup cols={2}>
+  <Card title="Providers" icon="cloud" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/overview">
+    Configure AI providers including AWS Bedrock, LiteLLM, and Google Vertex AI with enterprise-grade security and governance.
+  </Card>
+  
+  <Card title="MCP Integration" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/overview">
+    Manage Model Context Protocol servers, marketplace integrations, and remote MCP server configurations.
+  </Card>
+  
+  <Card title="Rules Engine" icon="shield-check" href="/enterprise-solutions/configuration/infrastructure-configuration/rules">
+    Define and enforce enterprise governance rules, security policies, and compliance requirements.
+  </Card>
+  
+  <Card title="Workflows" icon="workflow" href="/enterprise-solutions/configuration/infrastructure-configuration/workflows">
+    Create automated workflows for development processes, approval chains, and integration pipelines.
+  </Card>
+</CardGroup>
+
+## Advanced Controls
+
+<CardGroup cols={2}>
+  <Card title="Control Other Cline Features" icon="toggles" href="/enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/overview">
+    Enable or disable specific Cline features across your organization with granular permission controls.
+  </Card>
+  
+  <Card title="Monitoring" icon="chart-line" href="/enterprise-solutions/monitoring/overview">
+    Configure OpenTelemetry integration for comprehensive monitoring, logging, and analytics.
+  </Card>
+</CardGroup>
+
+## Getting Started
+
+1. **Assessment**: Review your current infrastructure and integration requirements
+2. **Provider Setup**: Configure your preferred AI providers with enterprise credentials
+3. **Security Configuration**: Implement rules and access controls
+4. **Monitoring Setup**: Enable telemetry and monitoring for operational visibility
+5. **User Onboarding**: Deploy configurations to your development teams
+
+## Enterprise Architecture Considerations
+
+### Security & Compliance
+- **Zero Trust Architecture**: All configurations support zero-trust security models
+- **Audit Logging**: Complete audit trails for all configuration changes
+- **Role-Based Access**: Granular permissions for different administrative roles
+- **Data Sovereignty**: Keep sensitive data within your infrastructure boundaries
+
+### Scalability & Performance
+- **Multi-Region Support**: Deploy configurations across multiple geographic regions  
+- **Load Balancing**: Distribute AI provider requests across multiple endpoints
+- **Caching Strategies**: Optimize performance with intelligent caching
+- **Rate Limiting**: Prevent abuse with configurable rate limits
+
+### Integration & Automation
+- **GitOps Integration**: Version control your configurations alongside code
+- **CI/CD Pipeline Integration**: Automate configuration deployment
+- **Webhook Support**: React to configuration changes with custom automation
+- **API-First Design**: Programmatically manage all configurations
+
+## Configuration Management
+
+All enterprise configurations support:
+
+- **Version Control**: Track changes with full revision history
+- **Environment Promotion**: Deploy configurations from dev → staging → production
+- **Rollback Capabilities**: Quickly revert problematic configurations
+- **Configuration Validation**: Automated testing of configuration changes
+- **Drift Detection**: Monitor and alert on configuration drift
+
+## Next Steps
+
+Ready to configure your enterprise deployment? Start with:
+
+1. [Provider Configuration](/enterprise-solutions/configuration/infrastructure-configuration/providers/overview) - Set up your AI providers
+2. [Security Rules](/enterprise-solutions/configuration/infrastructure-configuration/rules) - Implement governance policies
+3. [Monitoring Setup](/enterprise-solutions/monitoring/overview) - Enable operational visibility
+
+For hands-on configuration assistance, contact your Cline Enterprise support team or refer to our implementation guides.
@@ -0,0 +1,182 @@
+---
+title: "AWS Bedrock Configuration"
+sidebarTitle: "AWS Bedrock"
+description: "Configure AWS Bedrock for your Cline deployment"
+---
+
+<Info>
+**Configuration Path: Self-Hosted**
+
+This guide covers Bedrock configuration for self-hosted deployments. For simple web-based setup, see [AWS Bedrock SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration).
+</Info>
+
+Configure Cline to use AWS Bedrock for enterprise access to Claude and other foundation models through Amazon's managed service.
+
+## Configuration Format
+
+Configure Bedrock through your remote configuration JSON using the `providerSettings.AwsBedrock` section:
+
+```json
+{
+  "providerSettings": {
+    "AwsBedrock": {
+      "models": [
+        {
+          "id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
+          "name": "Claude 3.5 Sonnet"
+        }
+      ],
+      "awsRegion": "us-east-1"
+    }
+  }
+}
+```
+
+## Configuration Fields
+
+| Field | Type | Description | Required |
+|-------|------|-------------|----------|
+| `models` | Array | List of model configurations | Yes |
+| `awsRegion` | String | AWS region (e.g., `us-east-1`) | Yes |
+| `awsUseCrossRegionInference` | Boolean | Enable cross-region inference | No |
+| `awsUseGlobalInference` | Boolean | Enable global inference routing | No |
+| `awsBedrockUsePromptCache` | Boolean | Enable prompt caching | No |
+| `awsBedrockEndpoint` | String | Custom Bedrock endpoint URL | No |
+| `customModels` | Array | Custom model configurations | No |
+
+### Model Configuration
+
+Each model in the `models` array requires:
+
+```json
+{
+  "id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
+  "name": "Claude 3.5 Sonnet",
+  "info": {
+    "maxTokens": 8192,
+    "contextWindow": 200000,
+    "supportsImages": true,
+    "supportsPromptCache": true
+  }
+}
+```
+
+## Common Model IDs
+
+| Model ID | Description | Context Window |
+|----------|-------------|----------------|
+| `anthropic.claude-3-5-sonnet-20241022-v2:0` | Latest Claude Sonnet | 200K tokens |
+| `anthropic.claude-3-5-haiku-20241022-v1:0` | Latest Claude Haiku | 200K tokens |
+| `anthropic.claude-3-opus-20240229-v1:0` | Claude Opus | 200K tokens |
+
+<Note>
+Model availability varies by region. See [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html) for region-specific model availability.
+</Note>
+
+## Example Configurations
+
+### Basic Configuration
+
+```json
+{
+  "providerSettings": {
+    "AwsBedrock": {
+      "models": [
+        {
+          "id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
+          "name": "Claude 3.5 Sonnet"
+        }
+      ],
+      "awsRegion": "us-east-1"
+    }
+  }
+}
+```
+
+### With Prompt Caching
+
+```json
+{
+  "providerSettings": {
+    "AwsBedrock": {
+      "models": [
+        {
+          "id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
+          "name": "Claude 3.5 Sonnet"
+        }
+      ],
+      "awsRegion": "us-east-1",
+      "awsBedrockUsePromptCache": true
+    }
+  }
+}
+```
+
+### Multiple Models
+
+```json
+{
+  "providerSettings": {
+    "AwsBedrock": {
+      "models": [
+        {
+          "id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
+          "name": "Claude 3.5 Sonnet"
+        },
+        {
+          "id": "anthropic.claude-3-5-haiku-20241022-v1:0",
+          "name": "Claude 3.5 Haiku"
+        }
+      ],
+      "awsRegion": "us-east-1"
+    }
+  }
+}
+```
+
+## Prerequisites
+
+Before configuring Cline to use Bedrock, you need:
+
+1. **AWS Account** with Bedrock access enabled
+2. **IAM Permissions** for Bedrock API calls (`bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream`)
+3. **Model Access** enabled for desired models in the Bedrock console
+4. **AWS Credentials** configured (IAM role, access keys, or AWS profile)
+
+<Tip>
+For AWS account setup and IAM configuration, see the [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html).
+</Tip>
+
+## Troubleshooting
+
+**"Access Denied" Errors**
+
+Ensure your AWS credentials have the required Bedrock permissions. See [AWS IAM documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html) for permission requirements.
+
+**"Model Not Found" Errors**
+
+Verify model access is enabled in the AWS Bedrock console and the model is available in your configured region.
+
+**High Latency**
+
+Consider using a region closer to your users or enabling cross-region inference for better performance.
+
+## Related Resources
+
+<CardGroup cols={2}>
+  <Card title="AWS Bedrock Docs" icon="book" href="https://docs.aws.amazon.com/bedrock/">
+    Complete AWS Bedrock documentation
+  </Card>
+  
+  <Card title="Model Access" icon="key" href="https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html">
+    How to enable model access
+  </Card>
+  
+  <Card title="IAM Permissions" icon="shield" href="https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html">
+    Required IAM permissions
+  </Card>
+  
+  <Card title="Pricing" icon="dollar-sign" href="https://aws.amazon.com/bedrock/pricing/">
+    AWS Bedrock pricing details
+  </Card>
+</CardGroup>
@@ -0,0 +1,254 @@
+---
+title: "Custom Provider Configuration"
+sidebarTitle: "Custom Providers"
+description: "Configure custom OpenAI-compatible providers for your Cline deployment"
+---
+
+<Info>
+**Configuration Path: Self-Hosted**
+
+This guide covers custom provider configuration for self-hosted deployments.
+</Info>
+
+Configure Cline to use any OpenAI-compatible API provider, including Azure OpenAI, self-hosted inference servers, and other third-party services.
+
+## What are Custom Providers?
+
+Custom providers include any API that implements the OpenAI API format:
+
+- **Azure OpenAI Service**: Microsoft's managed OpenAI models
+- **vLLM**: Self-hosted inference server
+- **Ollama**: Local model runner
+- **Text Generation Inference (TGI)**: Hugging Face's inference server
+- **LocalAI**: Local OpenAI API replacement
+- **Other OpenAI-compatible APIs**: Any custom implementation
+
+## Configuration Format
+
+Configure custom providers through your remote configuration JSON using the `providerSettings.OpenAiCompatible` section:
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        }
+      ],
+      "openAiBaseUrl": "https://your-api.company.com/v1"
+    }
+  }
+}
+```
+
+## Configuration Fields
+
+| Field | Type | Description | Required |
+|-------|------|-------------|----------|
+| `models` | Array | List of model configurations | Yes |
+| `openAiBaseUrl` | String | API endpoint base URL | Yes |
+| `openAiApiKey` | String | API key for authentication | No |
+| `openAiModelId` | String | Default model identifier | No |
+
+### Azure OpenAI Specific Fields
+
+For Azure OpenAI, additional fields are available:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `azureApiVersion` | String | Azure API version (e.g., `2024-02-15-preview`) |
+
+## Example Configurations
+
+### Azure OpenAI
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        }
+      ],
+      "openAiBaseUrl": "https://your-resource.openai.azure.com/openai/deployments/gpt-4-turbo",
+      "openAiApiKey": "your-azure-api-key",
+      "azureApiVersion": "2024-02-15-preview"
+    }
+  }
+}
+```
+
+### Self-Hosted vLLM
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "meta-llama/Llama-2-70b-chat-hf",
+          "name": "Llama 2 70B"
+        }
+      ],
+      "openAiBaseUrl": "http://vllm.company.com:8000/v1"
+    }
+  }
+}
+```
+
+### Local Ollama
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "codellama",
+          "name": "Code Llama"
+        }
+      ],
+      "openAiBaseUrl": "http://localhost:11434/v1"
+    }
+  }
+}
+```
+
+### Text Generation Inference (TGI)
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "mistralai/Mistral-7B-Instruct-v0.2",
+          "name": "Mistral 7B Instruct"
+        }
+      ],
+      "openAiBaseUrl": "http://tgi.company.com:8080/v1",
+      "openAiApiKey": "your-tgi-api-key"
+    }
+  }
+}
+```
+
+### LocalAI
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-3.5-turbo",
+          "name": "Local GPT-3.5"
+        }
+      ],
+      "openAiBaseUrl": "http://localhost:8080/v1"
+    }
+  }
+}
+```
+
+### Internal Network (No Auth)
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "custom-model",
+          "name": "Custom Model"
+        }
+      ],
+      "openAiBaseUrl": "http://internal.api:8000/v1"
+    }
+  }
+}
+```
+
+## Model Configuration
+
+Each model requires basic information:
+
+```json
+{
+  "id": "model-identifier",
+  "name": "Display Name",
+  "info": {
+    "maxTokens": 4096,
+    "contextWindow": 128000,
+    "supportsImages": true,
+    "supportsPromptCache": false
+  }
+}
+```
+
+## Prerequisites
+
+Before configuring a custom provider, you need:
+
+1. **API Endpoint**: URL of your OpenAI-compatible API
+2. **API Key** (if required): Authentication credentials
+3. **Model IDs**: Names of available models
+4. **Network Access**: Connectivity from where Cline is being used
+
+## Troubleshooting
+
+**Connection Errors**
+
+Verify the endpoint is accessible:
+```bash
+curl https://your-api.company.com/v1/models
+```
+
+**Authentication Errors**
+
+Test authentication with your API key:
+```bash
+curl -H "Authorization: Bearer your-api-key" \
+  https://your-api.company.com/v1/models
+```
+
+**Model Not Found**
+
+Ensure the model ID in your configuration matches what the API expects. Check available models:
+```bash
+curl -H "Authorization: Bearer your-api-key" \
+  https://your-api.company.com/v1/models
+```
+
+**Timeout Issues**
+
+If responses are slow:
+- Check network latency
+- Verify server has adequate resources
+- Consider using faster models
+
+## Provider Documentation
+
+For setup and deployment of these services, see their official documentation:
+
+<CardGroup cols={2}>
+  <Card title="Azure OpenAI" icon="microsoft" href="https://learn.microsoft.com/en-us/azure/ai-services/openai/">
+    Microsoft's managed OpenAI service
+  </Card>
+  
+  <Card title="vLLM" icon="server" href="https://docs.vllm.ai/">
+    High-performance inference engine
+  </Card>
+  
+  <Card title="Ollama" icon="download" href="https://ollama.ai/">
+    Run models locally
+  </Card>
+  
+  <Card title="Text Generation Inference" icon="code" href="https://huggingface.co/docs/text-generation-inference/">
+    Hugging Face inference server
+  </Card>
+</CardGroup>
@@ -0,0 +1,185 @@
+---
+title: "Google Vertex AI Configuration"
+sidebarTitle: "Google Vertex"
+description: "Configure Google Vertex AI for your Cline deployment"
+---
+
+<Info>
+**Configuration Path: Self-Hosted**
+
+This guide covers Vertex AI configuration for self-hosted deployments. For simple web-based setup, see [Google Vertex SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/google-vertex/admin-configuration).
+</Info>
+
+Configure Cline to use Google Vertex AI for enterprise access to Gemini and other Google AI models through Google Cloud Platform.
+
+## Configuration Format
+
+Configure Vertex AI through your remote configuration JSON using the `providerSettings.Vertex` section:
+
+```json
+{
+  "providerSettings": {
+    "Vertex": {
+      "models": [
+        {
+          "id": "claude-3-5-sonnet-v2@20241022",
+          "name": "Claude 3.5 Sonnet"
+        }
+      ],
+      "vertexProjectId": "my-project-id",
+      "vertexRegion": "us-central1"
+    }
+  }
+}
+```
+
+## Configuration Fields
+
+| Field | Type | Description | Required |
+|-------|------|-------------|----------|
+| `models` | Array | List of model configurations | Yes |
+| `vertexProjectId` | String | Google Cloud project ID | Yes |
+| `vertexRegion` | String | GCP region (e.g., `us-central1`) | Yes |
+
+### Model Configuration
+
+Each model in the `models` array requires:
+
+```json
+{
+  "id": "claude-3-5-sonnet-v2@20241022",
+  "name": "Claude 3.5 Sonnet",
+  "info": {
+    "maxTokens": 8192,
+    "contextWindow": 200000,
+    "supportsImages": true,
+    "supportsPromptCache": true
+  }
+}
+```
+
+## Common Model IDs
+
+| Model ID | Description | Context Window |
+|----------|-------------|----------------|
+| `claude-3-5-sonnet-v2@20241022` | Claude 3.5 Sonnet | 200K tokens |
+| `claude-3-5-haiku@20241022` | Claude 3.5 Haiku | 200K tokens |
+| `claude-3-opus@20240229` | Claude 3 Opus | 200K tokens |
+| `gemini-2.0-flash-exp` | Gemini Flash (experimental) | 1M tokens |
+| `gemini-1.5-pro-002` | Gemini Pro | 2M tokens |
+| `gemini-1.5-flash-002` | Gemini Flash | 1M tokens |
+
+<Note>
+Model availability varies by region. See [Vertex AI documentation](https://cloud.google.com/vertex-ai/docs/generative-ai/learn/models) for region-specific model availability.
+</Note>
+
+## Example Configurations
+
+### Basic Configuration
+
+```json
+{
+  "providerSettings": {
+    "Vertex": {
+      "models": [
+        {
+          "id": "claude-3-5-sonnet-v2@20241022",
+          "name": "Claude 3.5 Sonnet"
+        }
+      ],
+      "vertexProjectId": "my-company-prod",
+      "vertexRegion": "us-central1"
+    }
+  }
+}
+```
+
+### Multiple Models
+
+```json
+{
+  "providerSettings": {
+    "Vertex": {
+      "models": [
+        {
+          "id": "claude-3-5-sonnet-v2@20241022",
+          "name": "Claude 3.5 Sonnet"
+        },
+        {
+          "id": "gemini-1.5-pro-002",
+          "name": "Gemini Pro"
+        }
+      ],
+      "vertexProjectId": "my-company-prod",
+      "vertexRegion": "us-central1"
+    }
+  }
+}
+```
+
+### With Extended Thinking
+
+```json
+{
+  "providerSettings": {
+    "Vertex": {
+      "models": [
+        {
+          "id": "claude-3-5-sonnet-v2@20241022",
+          "name": "Claude 3.5 Sonnet",
+          "thinkingBudgetTokens": 1600
+        }
+      ],
+      "vertexProjectId": "my-company-prod",
+      "vertexRegion": "us-central1"
+    }
+  }
+}
+```
+
+## Prerequisites
+
+Before configuring Cline to use Vertex AI, you need:
+
+1. **Google Cloud Project** with Vertex AI API enabled
+2. **Service Account** with Vertex AI User role (`roles/aiplatform.user`)
+3. **Service Account Credentials** configured for authentication
+4. **Model Access** verified in your project and region
+
+<Tip>
+For Google Cloud setup and authentication configuration, see the [Vertex AI documentation](https://cloud.google.com/vertex-ai/docs/generative-ai/start/quickstarts/quickstart-multimodal).
+</Tip>
+
+## Troubleshooting
+
+**"Permission Denied" Errors**
+
+Ensure your service account has the required Vertex AI permissions. See [Google Cloud IAM documentation](https://cloud.google.com/vertex-ai/docs/general/access-control) for permission requirements.
+
+**"API Not Enabled" Errors**
+
+Verify the Vertex AI API is enabled in your Google Cloud project.
+
+**"Model Not Found" Errors**
+
+Check that the model is available in your configured region and that your project has access to it.
+
+## Related Resources
+
+<CardGroup cols={2}>
+  <Card title="Vertex AI Docs" icon="book" href="https://cloud.google.com/vertex-ai/docs">
+    Complete Vertex AI documentation
+  </Card>
+  
+  <Card title="Service Accounts" icon="key" href="https://cloud.google.com/iam/docs/service-accounts">
+    Service account best practices
+  </Card>
+  
+  <Card title="Model Guide" icon="brain" href="https://cloud.google.com/vertex-ai/docs/generative-ai/learn/models">
+    Available models and features
+  </Card>
+  
+  <Card title="Pricing" icon="dollar-sign" href="https://cloud.google.com/vertex-ai/pricing">
+    Vertex AI pricing details
+  </Card>
+</CardGroup>
@@ -0,0 +1,215 @@
+---
+title: "LiteLLM Configuration"
+sidebarTitle: "LiteLLM"
+description: "Configure LiteLLM proxy for your Cline deployment"
+---
+
+<Info>
+**Configuration Path: Self-Hosted**
+
+This guide covers LiteLLM configuration for self-hosted deployments. For web-based setup, see [LiteLLM SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration).
+</Info>
+
+Configure Cline to use an existing LiteLLM proxy for unified access to multiple AI models through a single API endpoint.
+
+## What is LiteLLM?
+
+[LiteLLM](https://github.com/BerriAI/litellm) is an open-source proxy that provides a unified OpenAI-compatible API for accessing 100+ AI models from different providers. Cline connects to your deployed LiteLLM instance.
+
+<Note>
+LiteLLM is a separate service you deploy and manage. This guide covers how to configure Cline to connect to an existing LiteLLM deployment.
+</Note>
+
+## Configuration Format
+
+Configure LiteLLM through your remote configuration JSON using the `providerSettings.OpenAiCompatible` section:
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        }
+      ],
+      "openAiBaseUrl": "https://litellm.yourcompany.com/v1"
+    }
+  }
+}
+```
+
+## Configuration Fields
+
+| Field | Type | Description | Required |
+|-------|------|-------------|----------|
+| `models` | Array | List of model configurations | Yes |
+| `openAiBaseUrl` | String | LiteLLM proxy endpoint URL | Yes |
+| `openAiApiKey` | String | API key for authentication | No |
+
+### Model Configuration
+
+Each model in the `models` array requires:
+
+```json
+{
+  "id": "gpt-4-turbo",
+  "name": "GPT-4 Turbo",
+  "info": {
+    "maxTokens": 4096,
+    "contextWindow": 128000,
+    "supportsImages": true
+  }
+}
+```
+
+<Note>
+Model IDs must match the model names configured in your LiteLLM proxy deployment.
+</Note>
+
+## Example Configurations
+
+### Basic Configuration
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        }
+      ],
+      "openAiBaseUrl": "https://litellm.company.com/v1"
+    }
+  }
+}
+```
+
+### With Authentication
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        }
+      ],
+      "openAiBaseUrl": "https://litellm.company.com/v1",
+      "openAiApiKey": "sk-your-litellm-key"
+    }
+  }
+}
+```
+
+### Multiple Models
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        },
+        {
+          "id": "claude-3-5-sonnet",
+          "name": "Claude 3.5 Sonnet"
+        },
+        {
+          "id": "gemini-pro",
+          "name": "Gemini Pro"
+        }
+      ],
+      "openAiBaseUrl": "https://litellm.company.com/v1",
+      "openAiApiKey": "sk-your-litellm-key"
+    }
+  }
+}
+```
+
+### Internal Network (No Auth)
+
+```json
+{
+  "providerSettings": {
+    "OpenAiCompatible": {
+      "models": [
+        {
+          "id": "gpt-4-turbo",
+          "name": "GPT-4 Turbo"
+        }
+      ],
+      "openAiBaseUrl": "http://litellm.internal:4000/v1"
+    }
+  }
+}
+```
+
+## Prerequisites
+
+Before configuring Cline to use LiteLLM, you need:
+
+1. **LiteLLM Proxy** deployed and accessible
+2. **LiteLLM Configuration** with desired models enabled
+3. **API Key** (if authentication is enabled)
+4. **Network Access** from where Cline is being used
+
+<Tip>
+For LiteLLM deployment and configuration, see the [LiteLLM documentation](https://docs.litellm.ai/docs/proxy/quick_start).
+</Tip>
+
+## Troubleshooting
+
+**Connection Errors**
+
+Verify the LiteLLM proxy is running and accessible:
+```bash
+curl https://litellm.yourcompany.com/health
+```
+
+**Authentication Errors**
+
+Check your API key is valid:
+```bash
+curl -H "Authorization: Bearer sk-your-key" \
+  https://litellm.yourcompany.com/v1/models
+```
+
+**Model Not Found**
+
+Verify the model is configured in your LiteLLM deployment. Model IDs in Cline's config must match the model names in LiteLLM's configuration.
+
+## Benefits of Using LiteLLM
+
+- **Multi-Provider Access**: Connect to multiple AI providers through one endpoint
+- **Load Balancing**: Distribute requests across providers automatically
+- **Fallback Support**: Automatic retry with different models on failure
+- **Cost Tracking**: Monitor usage and costs across all models
+- **Rate Limiting**: Control usage at the proxy level
+
+## Related Resources
+
+<CardGroup cols={2}>
+  <Card title="LiteLLM Docs" icon="book" href="https://docs.litellm.ai/">
+    Complete LiteLLM documentation
+  </Card>
+  
+  <Card title="LiteLLM GitHub" icon="github" href="https://github.com/BerriAI/litellm">
+    Source code and deployment examples
+  </Card>
+  
+  <Card title="Proxy Setup" icon="server" href="https://docs.litellm.ai/docs/proxy/quick_start">
+    LiteLLM proxy deployment guide
+  </Card>
+  
+  <Card title="Supported Providers" icon="list" href="https://docs.litellm.ai/docs/providers">
+    List of supported AI providers
+  </Card>
+</CardGroup>
@@ -0,0 +1,144 @@
+---
+title: "AI Provider Configuration"
+sidebarTitle: "Overview"
+description: "Configure AI provider settings for your Cline deployment"
+---
+
+<Info>
+**Configuration Path: Self-Hosted**
+
+This section covers provider configuration for self-hosted deployments. For web-based configuration through app.cline.bot, see [SaaS Provider Configuration](/enterprise-solutions/configuration/remote-configuration/overview).
+</Info>
+
+Configure which AI providers your team can use and manage provider credentials centrally. Cline supports major AI providers with enterprise-grade authentication options.
+
+## Supported Providers
+
+<CardGroup cols={2}>
+  <Card title="AWS Bedrock" icon="aws" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock">
+    Amazon's managed service for Claude and other foundation models
+  </Card>
+  
+  <Card title="Google Vertex AI" icon="google" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex">
+    Google Cloud's AI platform with Gemini and PaLM models
+  </Card>
+  
+  <Card title="LiteLLM" icon="zap" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/litellm">
+    Universal proxy for accessing 100+ AI models through a unified API
+  </Card>
+  
+  <Card title="Custom Providers" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/custom">
+    OpenAI-compatible APIs and self-hosted models
+  </Card>
+</CardGroup>
+
+## What is Provider Configuration?
+
+Provider configuration in Cline allows administrators to:
+
+1. **Manage Credentials Centrally**: Store API keys and authentication details in one place
+2. **Control Model Access**: Specify which models teams can use
+3. **Enforce Provider Usage**: Direct all team members to approved providers
+
+## How It Works
+
+Provider settings are configured through your remote configuration JSON file:
+
+```json
+{
+  "providerSettings": {
+    "provider": "bedrock",
+    "bedrockRegion": "us-east-1",
+    "bedrockServiceRole": "arn:aws:iam::..."
+  }
+}
+```
+
+When configured, these settings:
+- Apply to all team members automatically
+- Override individual user settings
+- Ensure consistent provider usage across the team
+
+## Configuration Options
+
+### Provider Selection
+
+Choose from supported providers:
+- **bedrock**: Use AWS Bedrock
+- **vertex**: Use Google Vertex AI  
+- **openai**: Use OpenAI API
+- **azure**: Use Azure OpenAI
+- **litellm**: Use a LiteLLM proxy
+
+### Authentication
+
+Each provider supports different authentication methods:
+
+**AWS Bedrock:**
+- IAM roles with cross-account access
+- Access keys (not recommended for production)
+
+**Google Vertex AI:**
+- Service account JSON keys
+- Workload Identity (for GKE deployments)
+
+**OpenAI/Azure:**
+- API keys
+
+**LiteLLM:**
+- Endpoint URL + API key
+
+## Example Configurations
+
+### AWS Bedrock with IAM Role
+```json
+{
+  "providerSettings": {
+    "provider": "bedrock",
+    "bedrockRegion": "us-east-1",
+    "bedrockServiceRole": "arn:aws:iam::123456789012:role/ClineBedrockRole"
+  }
+}
+```
+
+### Google Vertex AI
+```json
+{
+  "providerSettings": {
+    "provider": "vertex",
+    "vertexProject": "my-project-id",
+    "vertexRegion": "us-central1"
+  }
+}
+```
+
+### LiteLLM Proxy
+```json
+{
+  "providerSettings": {
+    "provider": "litellm",
+    "litellmBaseUrl": "https://litellm.company.com",
+    "litellmApiKey": "sk-..."
+  }
+}
+```
+
+## Next Steps
+
+<CardGroup cols={2}>
+  <Card title="Configure AWS Bedrock" icon="aws" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock">
+    Set up AWS Bedrock integration
+  </Card>
+  
+  <Card title="Configure Google Vertex" icon="google" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex">
+    Set up Google Vertex AI integration
+  </Card>
+  
+  <Card title="Configure LiteLLM" icon="zap" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/litellm">
+    Set up LiteLLM proxy integration
+  </Card>
+  
+  <Card title="Configure Custom Provider" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/custom">
+    Set up custom OpenAI-compatible provider
+  </Card>
+</CardGroup>
@@ -0,0 +1,239 @@
+---
+title: "Rules"
+sidebarTitle: "Rules"
+description: "Custom instruction files that guide Cline's behavior in your enterprise deployment"
+---
+
+Rules are custom instruction files that provide Cline with guidelines about your coding preferences, standards, and best practices. These instructions get added to Cline's context when working on tasks.
+
+## What are Rules?
+
+Rules are simple markdown files stored in a `.clinerules/` directory that contain your team's conventions, preferences, and guidelines. They help Cline understand your:
+
+- Coding style and conventions
+- Preferred libraries and frameworks
+- Architectural patterns
+- Testing strategies
+- Documentation standards
+- Communication preferences
+
+<Tip>
+Rules are just `.md` files - no complex configuration needed!
+</Tip>
+
+## Quick Example
+
+Here's a simple rule file that guides TypeScript development:
+
+```markdown
+# TypeScript Conventions
+
+## Code Style
+- Use 2-space indentation
+- Prefer `const` over `let`
+- Always use explicit return types for functions
+- Use named exports instead of default exports
+
+## Testing
+- Write unit tests for all utility functions
+- Use Vitest as the testing framework
+- Aim for 80%+ code coverage
+
+## Dependencies
+- Prefer native TypeScript features over external libraries
+- Use Zod for runtime type validation
+- Use date-fns for date manipulation
+```
+
+## Creating Rules
+
+<Tabs>
+  <Tab title="Using /newrule Command">
+    The easiest way to create a rule is with the `/newrule` command:
+    
+    1. During a conversation with Cline, type `/newrule`
+    2. Cline will analyze your conversation and preferences
+    3. It creates an appropriately named `.md` file in `.clinerules/`
+    
+    **Example:**
+    ```
+    /newrule
+    
+    Based on our conversation, create a rule for React component structure
+    ```
+  </Tab>
+  
+  <Tab title="Manual Creation">
+    You can also create rule files manually:
+    
+    1. Create a `.clinerules/` directory in your repository root
+    2. Add markdown files with your guidelines
+    3. Use descriptive names like `react-patterns.md` or `api-conventions.md`
+    
+    **File structure:**
+    ```
+    your-repo/
+    ├── .clinerules/
+    │   ├── typescript-style.md
+    │   ├── testing-standards.md
+    │   └── code-review-checklist.md
+    └── src/
+    ```
+  </Tab>
+</Tabs>
+
+## Global vs Workspace Rules
+
+<CardGroup cols={2}>
+  <Card title="Workspace Rules" icon="folder">
+    **Location:** `.clinerules/` in your repository
+    
+    **Scope:** Specific to that project
+    
+    **Use for:** Project-specific conventions and patterns
+  </Card>
+  
+  <Card title="Global Rules" icon="globe">
+    **Location:** `Documents/Cline/` directory
+    
+    **Scope:** All your projects
+    
+    **Use for:** Personal preferences that apply everywhere
+  </Card>
+</CardGroup>
+
+## Managing Rules
+
+### Toggling Rules
+
+You can enable or disable individual rule files:
+
+1. Click the rules icon in Cline's interface
+2. Toggle rules on/off as needed
+3. Changes apply immediately to new tasks
+
+<Note>
+Disabling a rule removes it from Cline's context, but keeps the file intact. You can re-enable it anytime.
+</Note>
+
+### Enterprise Remote Rules
+
+<Info>
+Enterprise deployments can configure **remote global rules** that apply to all team members. These are managed through your infrastructure configuration and cannot be toggled off by individual developers.
+
+See [Self-Hosted Configuration](/enterprise-solutions/configuration/infrastructure-configuration/overview) for details on remote rules.
+</Info>
+
+## Compatible Formats
+
+Cline also respects rules from other AI coding tools:
+
+| File/Directory | Tool | Location |
+|----------------|------|----------|
+| `.cursorrules` | Cursor | Workspace root (single file) |
+| `.cursor/rules/` | Cursor | Workspace directory (`.mdc` files) |
+| `.windsurfrules` | Windsurf | Workspace root (single file) |
+| `AGENTS.md` | Various | Workspace root + recursive search |
+
+<Note>
+**AGENTS.md behavior:** Cline only searches for nested `AGENTS.md` files recursively if a top-level `AGENTS.md` exists in your workspace root. If found, all `AGENTS.md` files are combined with their relative paths as headers.
+</Note>
+
+These files work the same way as `.clinerules/` files and can be toggled on/off independently.
+
+## Best Practices
+
+<AccordionGroup>
+  <Accordion title="Keep Rules Focused" icon="bullseye">
+    Each rule file should focus on one topic:
+    - ✅ `typescript-conventions.md`
+    - ✅ `react-component-structure.md`
+    - ❌ `everything-about-our-codebase.md`
+  </Accordion>
+  
+  <Accordion title="Be Specific, Not Generic" icon="crosshairs">
+    Base rules on actual team preferences, not assumptions:
+    - ✅ "We use React Query for server state management"
+    - ❌ "Use best practices for state management"
+  </Accordion>
+  
+  <Accordion title="Update Rules as Projects Evolve" icon="rotate">
+    Review and update rules periodically:
+    - When adopting new technologies
+    - After major architectural changes
+    - When team conventions evolve
+  </Accordion>
+  
+  <Accordion title="Don't Overdo It" icon="gauge-simple-high">
+    Too many rules can overwhelm Cline's context:
+    - Start with 3-5 essential rules
+    - Add more only when truly needed
+    - Remove outdated rules promptly
+  </Accordion>
+</AccordionGroup>
+
+## Example Rule Files
+
+<AccordionGroup>
+  <Accordion title="API Design Standards" icon="code">
+```markdown
+# API Design Standards
+
+## REST Conventions
+- Use plural nouns for endpoints (`/users`, not `/user`)
+- Use HTTP methods semantically (GET, POST, PUT, DELETE)
+- Return appropriate status codes
+
+## Response Format
+\`\`\`typescript
+{
+  data: T,
+  error?: string,
+  metadata?: {
+    page: number,
+    total: number
+  }
+}
+\`\`\`
+
+## Error Handling
+- Always return error messages in `error` field
+- Use 4xx for client errors, 5xx for server errors
+- Include request ID in error responses
+```
+  </Accordion>
+  
+  <Accordion title="Testing Requirements" icon="vial">
+```markdown
+# Testing Requirements
+
+## Test Organization
+- Place tests next to source files (`Button.test.tsx`)
+- Use `describe` blocks to group related tests
+- Write descriptive test names
+
+## Coverage Requirements
+- Unit tests for all utility functions
+- Integration tests for API endpoints
+- E2E tests for critical user flows
+- Minimum 80% coverage for new code
+
+## Mocking Strategy
+- Mock external API calls
+- Use test fixtures for complex data
+- Prefer dependency injection for testability
+```
+  </Accordion>
+</AccordionGroup>
+
+## Next Steps
+
+<CardGroup cols={2}>
+  <Card title="Workflows" icon="diagram-project" href="/enterprise-solutions/configuration/infrastructure-configuration/workflows">
+    Combine rules with automated workflows
+  </Card>
+  
+  <Card title="Remote Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
+    Deploy global rules for your team
+  </Card>
+</CardGroup>
@@ -0,0 +1,324 @@
+---
+title: "Workflows"
+sidebarTitle: "Workflows"
+description: "Reusable instruction sets that can be invoked on-demand via slash commands"
+---
+
+Workflows are markdown files containing reusable instructions that you can invoke on-demand using slash commands. Think of them as "rules you can call when needed" rather than always-active guidelines.
+
+## What are Workflows?
+
+Workflows are similar to [Rules](/enterprise-solutions/configuration/infrastructure-configuration/rules), but with one key difference:
+
+<CardGroup cols={2}>
+  <Card title="Rules" icon="book">
+    **Always Active**
+    
+    Automatically applied to every task when toggled on
+    
+    Example: Coding standards, style guides
+  </Card>
+  
+  <Card title="Workflows" icon="diagram-project">
+    **On-Demand**
+    
+    Invoked only when you use the slash command
+    
+    Example: Deployment checklists, review processes
+  </Card>
+</CardGroup>
+
+<Tip>
+Workflows are just markdown files, no complex configuration needed!
+</Tip>
+
+## Quick Example
+
+Here's a simple deployment workflow:
+
+**File:** `.clinerules/workflows/deploy.md`
+
+```markdown
+# Deployment Workflow
+
+Before deploying to production, ensure:
+
+## Pre-Deployment Checklist
+1. All tests passing (unit, integration, e2e)
+2. Code review approved by 2+ engineers
+3. Staging environment tested successfully
+4. Database migrations reviewed
+5. Rollback plan documented
+
+## Deployment Steps
+1. Create deployment branch from main
+2. Run final test suite
+3. Deploy to production
+4. Monitor error rates for 30 minutes
+5. Verify key user flows
+
+## Post-Deployment
+1. Update deployment log
+2. Notify team in #deployments channel
+3. Monitor metrics for 24 hours
+```
+
+**Usage:**
+```
+/deploy
+
+I'm ready to deploy the new authentication feature
+```
+
+When invoked, Cline adds the workflow instructions to its context for that specific task.
+
+## Creating Workflows
+
+<Tabs>
+  <Tab title="Manual Creation">
+    Create workflow files in the `.clinerules/workflows/` directory:
+    
+    1. Create `.clinerules/workflows/` in your repository root
+    2. Add markdown files with your workflow instructions
+    3. Use descriptive names matching your slash command
+    
+    **File structure:**
+    ```
+    your-repo/
+    ├── .clinerules/
+    │   └── workflows/
+    │       ├── deploy.md
+    │       ├── code-review.md
+    │       └── bug-triage.md
+    └── src/
+    ```
+  </Tab>
+  
+  <Tab title="Slash Command">
+    You can also create workflows during a conversation:
+    
+    1. Have a conversation about a process you want to codify
+    2. Type `/newrule` and specify it should be a workflow
+    3. Cline creates the workflow file in `.clinerules/workflows/`
+    
+    <Note>
+    The `/newrule` command can create both rules and workflows - just specify your intent clearly.
+    </Note>
+  </Tab>
+</Tabs>
+
+## Using Workflows
+
+### Invoking Workflows
+
+Simply type `/` followed by the workflow filename (without `.md`):
+
+```
+/deploy
+/code-review  
+/bug-triage
+```
+
+The workflow instructions are added to Cline's context for the current task only.
+
+### Workflow Naming
+
+- Use lowercase with hyphens: `deploy.md`, `code-review.md`
+- Keep names short and memorable
+- Name should indicate the workflow's purpose
+
+<Warning>
+Workflow filenames become slash commands, so choose names that are easy to type and remember.
+</Warning>
+
+## Global vs Workspace Workflows
+
+<CardGroup cols={2}>
+  <Card title="Workspace Workflows" icon="folder">
+    **Location:** `.clinerules/workflows/` in your repository
+    
+    **Scope:** Specific to that project
+    
+    **Use for:** Project-specific processes and checklists
+  </Card>
+  
+  <Card title="Global Workflows" icon="globe">
+    **Location:** `Documents/Cline/Workflows/` directory
+    
+    **Scope:** All your projects
+    
+    **Use for:** Personal workflows that apply everywhere
+  </Card>
+</CardGroup>
+
+<Info>
+**Precedence:** Local workflows override global workflows if they have the same name.
+</Info>
+
+## Managing Workflows
+
+### Toggling Workflows
+
+You can enable or disable workflows:
+
+1. Click the rules icon in Cline's interface
+2. Switch to the "Workflows" tab
+3. Toggle workflows on/off as needed
+
+<Note>
+Disabling a workflow prevents it from being invoked, but keeps the file intact. The slash command won't work until you re-enable it.
+</Note>
+
+### Enterprise Remote Workflows
+
+<Info>
+Enterprise deployments can configure **remote global workflows** that are available to all team members. These are managed through your infrastructure configuration.
+
+See [Self-Hosted Configuration](/enterprise-solutions/configuration/infrastructure-configuration/overview) for details on remote workflows.
+</Info>
+
+## Example Workflows
+
+<AccordionGroup>
+  <Accordion title="Code Review Workflow" icon="code-review">
+```markdown
+# Code Review Workflow
+
+## Pre-Review Checklist
+- [ ] Code follows project style guide
+- [ ] All tests pass locally
+- [ ] No console.log or debugging code
+- [ ] Comments explain "why" not "what"
+- [ ] PR description is clear and complete
+
+## Review Focus Areas
+1. **Architecture**: Does this fit our existing patterns?
+2. **Security**: Any potential vulnerabilities?
+3. **Performance**: Any obvious bottlenecks?
+4. **Testing**: Are edge cases covered?
+5. **Documentation**: Is it clear how to use new features?
+
+## Review Response
+- Address all feedback within 24 hours
+- Mark conversations as resolved when addressed
+- Re-request review after major changes
+```
+  </Accordion>
+  
+  <Accordion title="Bug Triage Workflow" icon="bug">
+```markdown
+# Bug Triage Workflow
+
+## Information Gathering
+1. Reproduce the bug in local environment
+2. Identify affected versions/environments
+3. Check if similar issues exist
+4. Gather error logs and stack traces
+
+## Priority Assessment
+**P0 (Critical)**: Production down, data loss, security breach
+**P1 (High)**: Major feature broken, significant user impact
+**P2 (Medium)**: Minor feature broken, workaround available
+**P3 (Low)**: Cosmetic issue, minimal impact
+
+## Create Ticket
+- Use template: "Bug Report"
+- Add reproduction steps
+- Include screenshots/videos if applicable
+- Tag with affected component
+- Assign priority label
+
+## Next Steps
+- P0/P1: Immediate fix required
+- P2: Schedule for current sprint
+- P3: Add to backlog
+```
+  </Accordion>
+  
+  <Accordion title="Feature Planning Workflow" icon="lightbulb">
+```markdown
+# Feature Planning Workflow
+
+## Requirements Gathering
+1. Define the user problem we're solving
+2. List success criteria (measurable)
+3. Identify edge cases and constraints
+4. Document technical dependencies
+
+## Design Considerations
+1. How does this fit existing architecture?
+2. What data models are needed?
+3. What API changes are required?
+4. How will this impact performance?
+
+## Implementation Plan
+1. Break into smaller, shippable pieces
+2. Identify which pieces can be done in parallel
+3. Note any feature flags needed
+4. Plan for backwards compatibility
+
+## Testing Strategy
+1. What unit tests are needed?
+2. What integration tests are needed?
+3. How will we test edge cases?
+4. What manual testing is required?
+```
+  </Accordion>
+</AccordionGroup>
+
+## Best Practices
+
+<AccordionGroup>
+  <Accordion title="Keep Workflows Action-Oriented" icon="list-check">
+    Workflows should contain **actionable steps**, not general advice:
+    - ✅ "Run `npm test` and verify all tests pass"
+    - ❌ "Make sure testing is done properly"
+  </Accordion>
+  
+  <Accordion title="Use Checklists" icon="square-check">
+    Format workflows as checklists when possible:
+    - Easy to follow step-by-step
+    - Clear progress tracking
+    - Reduces missed steps
+  </Accordion>
+  
+  <Accordion title="Include Context" icon="circle-info">
+    Add **why** behind each step:
+    ```markdown
+    1. Check staging environment first
+       (Catching issues in staging prevents production incidents)
+    ```
+  </Accordion>
+  
+  <Accordion title="Version as Code" icon="code-branch">
+    Workflows live in your repository:
+    - Track changes in git
+    - Review updates in PRs
+    - Maintain history of process evolution
+  </Accordion>
+</AccordionGroup>
+
+## Workflows vs Rules: When to Use Each
+
+| Use Rules When | Use Workflows When |
+|----------------|-------------------|
+| Guidance should apply to every task | Process is invoked occasionally |
+| Standards that rarely change | Checklist for specific scenarios |
+| Always-on coding conventions | On-demand deployment processes |
+| General coding style | Specific review procedures |
+
+**Example:**
+- **Rule**: "Use TypeScript strict mode and explicit return types"
+- **Workflow**: "Follow these 10 steps when deploying to production"
+
+## Next Steps
+
+<CardGroup cols={2}>
+  <Card title="Rules" icon="book" href="/enterprise-solutions/configuration/infrastructure-configuration/rules">
+    Learn about always-active rules
+  </Card>
+  
+  <Card title="Remote Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
+    Deploy global workflows for your team
+  </Card>
+</CardGroup>
@@ -0,0 +1,97 @@
+---
+title: "Configuration Overview"
+sidebarTitle: "Overview"
+description: "Understanding enterprise configuration options for inference providers and system settings"
+---
+
+Cline offers two distinct approaches to configure inference providers and system settings for your organization. Understanding the difference between these approaches will help you choose the right configuration method for your needs.
+
+## Configuration Types
+
+<Info>
+**Need help choosing?** See the [Deployment Guide](/enterprise-solutions/configuration/choosing-your-deployment) for a detailed comparison and decision tree.
+</Info>
+
+<CardGroup cols={2}>
+  <Card title="SaaS Provider Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
+    **Simple cloud-based setup**
+    
+    Configure inference providers through the Cline [admin console](https://app.cline.bot/dashboard). Ideal for quick organizational deployment with minimal infrastructure requirements.
+  </Card>
+  
+  <Card title="Self-Hosted Configuration" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
+    **Advanced enterprise setup**
+    
+    Deep infrastructure integration with VPC endpoints, multi-account support, compliance features, and custom workflows on your own infrastructure.
+  </Card>
+</CardGroup>
+
+## Choosing the Right Configuration
+
+### Use SaaS Configuration When:
+- **Quick Setup**: You need to get your team up and running quickly
+- **Centralized Management**: You want simple, cloud-based provider management
+- **Standard Requirements**: Your organization has typical security and compliance needs
+- **Small to Medium Teams**: You're managing dozens to hundreds of users
+
+### Use Self-Hosted Configuration When:
+- **Enterprise Security**: You need advanced security features and compliance controls
+- **Complex Infrastructure**: You have existing AWS/GCP infrastructure to integrate with
+- **Custom Workflows**: You need custom rules, workflows, and automation
+- **Large Organizations**: You're managing hundreds to thousands of users
+- **Air-Gapped Environments**: You need on-premises or restricted network deployment
+
+## Configuration Comparison
+
+| Feature | SaaS Configuration | Self-Hosted Configuration |
+|---------|-------------------|---------------------------|
+| **Setup Complexity** | Simple | Advanced |
+| **Deployment Time** | Minutes | Days to Weeks |
+| **Infrastructure Required** | None | AWS/GCP/Azure |
+| **Compliance Features** | Basic | Advanced |
+| **Custom Rules** | No | Yes |
+| **Multi-Account Support** | No | Yes |
+| **VPC Integration** | No | Yes |
+| **Cost** | Lower | Higher |
+
+## Getting Started
+
+<Steps>
+<Step title="Evaluate Your Requirements">
+Review your organization's security, compliance, and infrastructure requirements to determine which configuration approach fits your needs.
+</Step>
+
+<Step title="Choose Your Path">
+Select either SaaS Configuration for simple setup or Self-Hosted Configuration for advanced enterprise features. Use the [Deployment Guide](/enterprise-solutions/configuration/choosing-your-deployment) if you need help deciding.
+</Step>
+
+<Step title="Follow Configuration Guide">
+Complete the setup process using the detailed guides for your chosen configuration type.
+</Step>
+
+<Step title="Onboard Team Members">
+Once configured, team members can connect using the provider-specific member guides.
+</Step>
+</Steps>
+
+---
+
+## Available Providers
+
+Both configuration approaches support the same core inference providers:
+
+<CardGroup cols={3}>
+  <Card title="AWS Bedrock" icon="aws">
+    Enterprise AI models with AWS infrastructure integration and security features.
+  </Card>
+  
+  <Card title="LiteLLM" icon="layer-group">
+    Unified proxy for accessing 100+ AI models through a single interface.
+  </Card>
+  
+  <Card title="Google Vertex AI" icon="google">
+    Google Cloud's AI platform with advanced ML capabilities and global infrastructure.
+  </Card>
+</CardGroup>
+
+The main difference lies in how these providers are configured and managed within your organization's infrastructure and security requirements.
@@ -4,7 +4,7 @@ sidebarTitle: "Configure AWS Bedrock (Member)"
 description: "Guide for engineers configuring AWS Bedrock credentials in VS Code after admin setup"
 ---

-As a team member, you can connect your local development environment to your organization's AWS Bedrock setup. This guide walks you through configuring your AWS credentials in VS Code so you can start using models through your organization's Bedrock infrastructure. Your administrator has already configured the provider settings-you just need to add your credentials to get started.
+As a team member, you can connect your local development environment to your organization's AWS Bedrock setup. This guide walks you through configuring your AWS credentials in VS Code so you can start using models through your organization's Bedrock infrastructure. Your administrator has already configured the provider settings—you just need to add your credentials to get started.

 ## Before You Begin

@@ -4,7 +4,7 @@ sidebarTitle: "Configure Google Vertex (Member)"
 description: "Guide for engineers connecting to their organization's Google Vertex AI setup through VS Code after admin setup"
 ---

-As a team member, you can connect your local development environment to your organization's Google Vertex AI setup. This guide walks you through configuring your Google Cloud credentials in VS Code so you can start using Vertex AI models through your organization's configured project and regional settings. Your administrator has already configured the provider settings-you just need to add your credentials to get started.
+As a team member, you can connect your local development environment to your organization's Google Vertex AI setup. This guide walks you through configuring your Google Cloud credentials in VS Code so you can start using Vertex AI models through your organization's configured project and regional settings. Your administrator has already configured the provider settings—you just need to add your credentials to get started.

 ## Before You Begin

@@ -4,7 +4,7 @@ sidebarTitle: "Configure LiteLLM (Member)"
 description: "Guide for engineers connecting to their organization's LiteLLM proxy through VS Code after admin setup"
 ---

-As a team member, you can connect your local development environment to your organization's LiteLLM proxy setup. This guide walks you through configuring your connection in VS Code so you can start using multiple AI models through your organization's unified proxy interface. Your administrator has already configured the provider settings-you just need to add your credentials to get started.
+As a team member, you can connect your local development environment to your organization's LiteLLM proxy setup. This guide walks you through configuring your connection in VS Code so you can start using multiple AI models through your organization's unified proxy interface. Your administrator has already configured the provider settings—you just need to add your credentials to get started.

 ## Before You Begin

@@ -0,0 +1,266 @@
+---
+title: "OpenTelemetry Integration Override"
+sidebarTitle: "OpenTelemetry Override"
+description: "Export Cline telemetry to your observability platform using OpenTelemetry Protocol (OTLP)"
+---
+
+Cline includes opt-in OpenTelemetry support for exporting metrics and logs to your own observability infrastructure using the OpenTelemetry Protocol (OTLP).
+
+<Note>
+OpenTelemetry integration is **optional** and intended for advanced users with existing observability infrastructure. Most users won't need this feature.
+</Note>
+
+## What is OpenTelemetry?
+
+[OpenTelemetry](https://opentelemetry.io/) is an industry-standard observability framework that provides a unified way to collect and export telemetry data (metrics, logs, and traces).
+
+Cline's OpenTelemetry support allows you to:
+- Export telemetry to your own systems
+- Integrate with observability platforms like Datadog, New Relic, Grafana Cloud, etc.
+- Maintain full control over your monitoring data
+- Use your organization's existing monitoring infrastructure
+
+## Supported Features
+
+Cline supports OpenTelemetry's **OTLP (OpenTelemetry Protocol)** export with:
+
+<CardGroup cols={2}>
+  <Card title="Metrics Export" icon="chart-bar">
+    Export metrics about Cline usage, performance, and errors
+  </Card>
+  
+  <Card title="Logs Export" icon="file-lines">
+    Export structured logs for debugging and analysis
+  </Card>
+</CardGroup>
+
+### Export Formats
+
+Cline supports three OTLP export protocols:
+
+- **gRPC** (default, recommended)
+- **HTTP/protobuf**
+- **HTTP/JSON**
+
+### Export Destinations
+
+You can export to:
+- **Console** (for testing)
+- **OTLP endpoint** (your own collector or observability platform)
+
+## Configuration
+
+OpenTelemetry is configured using environment variables before launching Cline.
+
+### Basic Setup
+
+Enable OpenTelemetry and configure an OTLP endpoint:
+
+```bash
+# Enable OpenTelemetry
+export CLINE_OTEL_TELEMETRY_ENABLED=true
+
+# Configure metrics and logs export
+export CLINE_OTEL_METRICS_EXPORTER=otlp
+export CLINE_OTEL_LOGS_EXPORTER=otlp
+
+# Set your OTLP endpoint
+export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://your-collector:4317
+
+# Optional: Set protocol (default is grpc)
+export CLINE_OTEL_EXPORTER_OTLP_PROTOCOL=grpc
+```
+
+### Environment Variables
+
+| Variable | Description | Default |
+|----------|-------------|---------|
+| `CLINE_OTEL_TELEMETRY_ENABLED` | Enable OpenTelemetry (`true`) | Disabled |
+| `CLINE_OTEL_METRICS_EXPORTER` | Metrics exporter type (`console`, `otlp`, or both) | None |
+| `CLINE_OTEL_LOGS_EXPORTER` | Logs exporter type (`console`, `otlp`, or both) | None |
+| `CLINE_OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP endpoint URL | None |
+| `CLINE_OTEL_EXPORTER_OTLP_PROTOCOL` | Protocol (`grpc`, `http/protobuf`, `http/json`) | `grpc` |
+| `CLINE_OTEL_EXPORTER_OTLP_INSECURE` | Allow insecure connections | `false` |
+| `CLINE_OTEL_EXPORTER_OTLP_HEADERS` | Custom headers (comma-separated `key=value` pairs) | None |
+
+### Advanced Configuration
+
+**Separate endpoints for metrics and logs:**
+```bash
+export CLINE_OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://metrics-collector:4317
+export CLINE_OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://logs-collector:4317
+```
+
+**Custom headers for authentication:**
+```bash
+export CLINE_OTEL_EXPORTER_OTLP_HEADERS="api-key=your-key,x-custom-header=value"
+```
+
+**Multiple exporters (console + OTLP):**
+```bash
+export CLINE_OTEL_METRICS_EXPORTER=console,otlp
+export CLINE_OTEL_LOGS_EXPORTER=console,otlp
+```
+
+**Export intervals:**
+```bash
+# Metrics export interval in milliseconds (default: 60000)
+export CLINE_OTEL_METRIC_EXPORT_INTERVAL=30000
+
+# Logs batch size and timeout
+export CLINE_OTEL_LOG_BATCH_SIZE=512
+export CLINE_OTEL_LOG_BATCH_TIMEOUT=5000
+export CLINE_OTEL_LOG_MAX_QUEUE_SIZE=2048
+```
+
+## Integration Examples
+
+### Datadog
+
+Export to Datadog using their OTLP endpoint:
+
+```bash
+export CLINE_OTEL_TELEMETRY_ENABLED=true
+export CLINE_OTEL_METRICS_EXPORTER=otlp
+export CLINE_OTEL_LOGS_EXPORTER=otlp
+export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://api.datadoghq.com
+export CLINE_OTEL_EXPORTER_OTLP_HEADERS="dd-api-key=YOUR_DD_API_KEY"
+```
+
+### New Relic
+
+Export to New Relic:
+
+```bash
+export CLINE_OTEL_TELEMETRY_ENABLED=true
+export CLINE_OTEL_METRICS_EXPORTER=otlp
+export CLINE_OTEL_LOGS_EXPORTER=otlp
+export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.nr-data.net:4317
+export CLINE_OTEL_EXPORTER_OTLP_HEADERS="api-key=YOUR_NEW_RELIC_LICENSE_KEY"
+```
+
+### Grafana Cloud
+
+Export to Grafana Cloud:
+
+```bash
+export CLINE_OTEL_TELEMETRY_ENABLED=true
+export CLINE_OTEL_METRICS_EXPORTER=otlp
+export CLINE_OTEL_LOGS_EXPORTER=otlp
+export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp-gateway-prod-us-central-0.grafana.net/otlp
+export CLINE_OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic YOUR_BASE64_CREDENTIALS"
+```
+
+
+## Testing Configuration
+
+Test your configuration with console output before sending to a real endpoint:
+
+```bash
+# Enable console output to see what data would be exported
+export CLINE_OTEL_TELEMETRY_ENABLED=true
+export CLINE_OTEL_METRICS_EXPORTER=console
+export CLINE_OTEL_LOGS_EXPORTER=console
+```
+
+Then launch Cline and check the console output for metrics and logs.
+
+## Troubleshooting
+
+### No Data Being Exported
+
+1. **Verify OpenTelemetry is enabled:**
+   ```bash
+   echo $CLINE_OTEL_TELEMETRY_ENABLED
+   ```
+   Should output `true`
+
+2. **Check exporters are configured:**
+   ```bash
+   echo $CLINE_OTEL_METRICS_EXPORTER
+   echo $CLINE_OTEL_LOGS_EXPORTER
+   ```
+
+3. **Test with console exporter first:**
+   ```bash
+   export CLINE_OTEL_METRICS_EXPORTER=console
+   export CLINE_OTEL_LOGS_EXPORTER=console
+   ```
+
+### Connection Errors
+
+1. **Verify endpoint is accessible:**
+   ```bash
+   curl -v https://your-otlp-endpoint:4317
+   ```
+
+2. **Check if insecure mode is needed:**
+   ```bash
+   export CLINE_OTEL_EXPORTER_OTLP_INSECURE=true
+   ```
+
+3. **Verify authentication headers:**
+   Double-check your API keys and authentication headers are correct
+
+### Debug Mode
+
+Enable debug logging to see detailed OpenTelemetry information:
+
+```bash
+export TEL_DEBUG_DIAGNOSTICS=true
+```
+
+This will output detailed information about:
+- Configuration being used
+- Exporters being created
+- Connection attempts
+- Export successes/failures
+
+## What Gets Exported
+
+When OpenTelemetry is enabled, Cline exports:
+
+### Metrics
+- Feature usage counts
+- Task execution metrics 
+- Error rates and types
+- Performance measurements
+
+### Logs
+- System events
+- Error logs with context
+- Operational information
+
+<Warning>
+Exported data is already anonymous and doesn't include code content, file paths, or sensitive information. However, you're responsible for securing the data once exported to your systems.
+</Warning>
+
+## Limitations
+
+Current OpenTelemetry support in Cline:
+- ✅ OTLP metrics export (console, gRPC, HTTP)
+- ✅ OTLP logs export (console, gRPC, HTTP)
+- ✅ Basic configuration via environment variables
+- ❌ Distributed tracing (not yet implemented)
+- ❌ Custom instrumentation API (not yet exposed)
+- ❌ Sampling configuration (uses defaults)
+
+## Best Practices
+
+1. **Test First**: Always test with console exporter before sending to production
+2. **Secure Credentials**: Never hardcode API keys; use secure environment variable management
+3. **Monitor Costs**: Be aware of data ingestion costs with your observability platform
+4. **Start Simple**: Begin with metrics only, add logs if needed
+5. **Use Compression**: OTLP supports compression; check if your endpoint requires it
+
+## Next Steps
+
+<CardGroup cols={2}>
+  <Card title="Cline Telemetry" icon="chart-simple" href="/enterprise-solutions/monitoring/telemetry">
+    Configure simple built-in telemetry
+  </Card>
+  
+  <Card title="OpenTelemetry Docs" icon="book" href="https://opentelemetry.io/docs/">
+    Learn more about OpenTelemetry
+  </Card>
+</CardGroup>
@@ -5,7 +5,7 @@ description: "This guide explains how administrators configure SSO provisioning
 ---

 ## Overview
-Cline Enterprise integrates with your existing identity provider (IdP) via WorkOS to deliver secure SSO and zero-touch user lifecycle management. In this guide, you'll connect your IdP (Okta, Azure AD, Google Workspace, or any SAML/OIDC provider), enable just-in-time (JIT) provisioning so new users are created automatically on first sign-in, and configure role mapping so permissions stay aligned with your directory-no manual invites or seat reconciliations required.
+Cline Enterprise integrates with your existing identity provider (IdP) via WorkOS to deliver secure SSO and zero-touch user lifecycle management. In this guide, you'll connect your IdP (Okta, Azure AD, Google Workspace, or any SAML/OIDC provider), enable just-in-time (JIT) provisioning so new users are created automatically on first sign-in, and configure role mapping so permissions stay aligned with your directory—no manual invites or seat reconciliations required.


 ## Prerequisites
@@ -90,6 +90,6 @@ Rolling out to your organization:
 - Review security architecture
 - Configure [cloud provider setup](/provider-config/aws-bedrock/api-key) (AWS Bedrock, Vertex AI, Azure)
 - Set up [MCP servers](/mcp/mcp-overview) for custom tooling
- Add [custom instructions](/customization/cline-rules) for your codebase
+- Add [custom instructions](/features/cline-rules) for your codebase

 Schedule a walkthrough to see how Cline Enterprise fits your infrastructure. We'll work with your security and compliance requirements to deploy in your environment.
@@ -0,0 +1,100 @@
+---
+title: "Cline Tools Reference Guide"
+---
+
+## What Can Cline Do?
+
+Cline is your AI assistant that can:
+
+-   Edit and create files in your project
+-   Run terminal commands
+-   Search and analyze your code
+-   Help debug and fix issues
+-   Automate repetitive tasks
+-   Integrate with external tools
+
+
+## Available Tools
+
+For the most up-to-date implementation details, you can view the full source code in the [Cline repository](https://github.com/cline/cline/blob/main/src/core/prompts/system-prompt/tools).
+
+Cline has access to the following tools for various tasks:
+
+1. **File Operations**
+
+    - `write_to_file`: Create or overwrite files
+    - `read_file`: Read file contents
+    - `replace_in_file`: Make targeted edits to files
+    - `search_files`: Search files using regex
+    - `list_files`: List directory contents
+
+2. **Terminal Operations**
+
+    - `execute_command`: Run CLI commands
+    - `list_code_definition_names`: List code definitions
+
+3. **MCP Tools**
+
+    - `use_mcp_tool`: Use tools from MCP servers
+    - `access_mcp_resource`: Access MCP server resources
+    - Users can create custom MCP tools that Cline can then access
+    - Example: Create a weather API tool that Cline can use to fetch forecasts
+
+4. **Interaction Tools**
+    - `ask_followup_question`: Ask user for clarification
+    - `attempt_completion`: Present final results
+
+
+Each tool has specific parameters and usage patterns. Here are some examples:
+
+-   Create a new file (write_to_file):
+
+    ```xml
+    <write_to_file>
+    <path>src/components/Header.tsx</path>
+    <content>
+    // Header component code
+    </content>
+    </write_to_file>
+    ```
+
+-   Search for a pattern (search_files):
+
+    ```xml
+    <search_files>
+    <path>src</path>
+    <regex>function\s+\w+\(</regex>
+    <file_pattern>*.ts</file_pattern>
+    </search_files>
+    ```
+
+-   Run a command (execute_command):
+    ```xml
+    <execute_command>
+    <command>npm install axios</command>
+    <requires_approval>false</requires_approval>
+    </execute_command>
+    ```
+
+## Common Tasks
+
+1. **Create a New Component**
+
+    - "Create a new React component called Footer"
+
+2. **Fix a Bug**
+
+    - "Fix the error in src/utils/format.ts"
+
+3. **Refactor Code**
+
+    - "Refactor the Button component to use TypeScript"
+
+4. **Run Commands**
+    - "Run npm install to add axios"
+
+## Getting Help
+
+-   [Join the Discord community](https://discord.gg/cline)
+-   Check the documentation
+-   Provide feedback to improve Cline
@@ -0,0 +1,386 @@
+---
+title: "New Task Tool"
+---
+
+### The `new_task` Tool & Context Management Strategies
+
+#### Overview
+
+Cline includes a powerful internal tool, `new_task`, designed to help manage workflow continuity and context preservation, especially during complex or long-running tasks. This tool, combined with Cline's awareness of its own context window usage and the flexibility of `.clinerules`, enables sophisticated strategies for breaking down work and ensuring seamless transitions between task sessions.
+
+Understanding the core capabilities and how they interact with custom rules is key to leveraging this feature effectively.
+
+#### Core Capabilities
+
+Two fundamental capabilities enable advanced context management:
+
+1. **The `new_task` Tool:**
+    - **Function:** Allows Cline, upon user approval, to end the current task session and immediately start a new one.
+    - **Context Preloading:** Crucially, Cline can **preload** this new task session with specific context provided within the tool's `<context>` block. This context can be anything Cline or a `.clinerules` file defines – summaries, code snippets, next steps, project state, etc.
+2. **Context Window Awareness:**
+    - **Tracking:** Cline internally tracks the percentage of its available context window currently being used during a task.
+    - **Visibility:** This information is visible in the `environment_details` provided to Cline in its prompt.
+
+#### Using the `/newtask` Slash Command
+
+As a quick alternative to Cline suggesting the `newtask` tool or defining complex rules, you can directly initiate the process using a Slash Command.
+
+-   **How:** Simply type `/newtask` in the chat input field.
+-   **Action:** Cline will propose creating a new task, typically suggesting context based on the current session (similar to its default behavior when using the tool). You will still get the `ask_followup_question` prompt to confirm and potentially modify the context before the new task is created.
+-   **Benefit:** Provides a fast, user-initiated way to leverage the `new_task` functionality for branching explorations or managing long sessions without waiting for Cline to suggest it.
+
+<Note>
+	For more details on using the `/newtask` slash command, see the [New Task Command](/features/slash-commands/new-task)
+	documentation.
+</Note>
+
+#### Default Behavior (Without `.clinerules`)
+
+By default, without specific `.clinerules` dictating its behavior:
+
+-   **Tool Availability:** The `new_task` tool exists, and Cline _can_ choose to use it.
+-   **Context Awareness:** Cline _is_ aware of its context usage percentage.
+-   **No Automatic Trigger:** Cline **will not** automatically initiate a task handoff _solely_ based on context usage reaching a specific percentage (like 50%). The decision to suggest using `new_task` comes from the AI model's reasoning based on the overall task progress and prompt instructions.
+-   **Basic Context Preloading:** If `new_task` is used without specific rules defining the `<context>` block structure, Cline will attempt to preload relevant information based on its current understanding (e.g., a basic summary of progress and next steps), but this may be less comprehensive than a rule-driven approach.
+
+#### The Power of `.clinerules`: Enabling Custom Workflows
+
+While the core capabilities exist by default, the true power, automation, and customization emerge when you combine `new_task` and context awareness with custom workflows defined in `.clinerules`. This allows you to precisely control _when_ and _how_ Cline manages context and task continuity.
+
+Key benefits of using `.clinerules` with `new_task`:
+
+-   **Automated Context Management:** Define rules to automatically trigger handoffs at specific context percentages (e.g., >50%, >70%) or token counts, ensuring optimal performance and preventing context loss.
+-   **Model-Specific Optimization:** Tailor handoff triggers based on known thresholds for different LLMs (e.g., trigger earlier for models known to degrade past a certain token count).
+-   **Intelligent Breakpoints:** Instruct Cline via rules to find logical stopping points (e.g., after completing a function or test) _after_ a context threshold is passed, ensuring cleaner handoffs.
+-   **Structured Task Decomposition:** Use Plan Mode to define subtasks, then use `.clinerules` to have Cline automatically create a new task via `new_task` upon completing each subtask, preloading the context for the _next_ subtask.
+-   **Custom Context Packaging:** Mandate the exact structure and content of the `<context>` block in `.clinerules` for highly detailed and consistent handoffs (see example below).
+-   **Improved Memory Persistence:** Use `new_task` context blocks as a primary, integrated way to persist information across sessions, potentially replacing or supplementing file-based memory systems.
+-   **Workflow Automation:** Define rules for specific scenarios, like always preloading certain setup instructions or project boilerplate when starting tasks of a particular type.
+
+#### Example Rule-Driven Workflow: Task Handoff Process
+
+A common workflow, **driven by specific `.clinerules` like the example below**, involves these steps:
+
+1. **Trigger Identification (Rule-Based):** Cline monitors for handoff points defined in the rules (e.g., context usage > 50%, task completion).
+2. **User Confirmation:** Cline uses `ask_followup_question` to propose creating a new task, often showing the intended context defined by the rules.
+
+    ```xml
+    <ask_followup_question>
+    <question>I've completed [specific accomplishment] and context usage is high (XX%). Would you like me to create a new task to continue with [remaining work], preloading the following context?</question>
+    <options>["Yes, create new task", "Modify context first", "No, continue this session"]</options>
+    </ask_followup_question>
+    ```
+
+3. **User Control:** You can approve, deny, or ask Cline to modify the context before the new task is created.
+4. **Context Packaging (`new_task` Tool):** If approved, Cline uses `new_task`, packaging the context according to the structure mandated by the `.clinerules`.
+5. **New Task Creation:** The current task ends, and a new session begins immediately, preloaded with the specified context.
+
+#### The Handoff Context Block (Rule-Defined Structure)
+
+The effectiveness of rule-driven handoffs depends heavily on how `.clinerules` define the `<context>` block. A comprehensive structure often includes:
+
+-   **`## Completed Work`**: Detailed list of accomplishments, files modified/created, key decisions.
+-   **`## Current State`**: Project status, running processes, key file states.
+-   **`## Next Steps`**: Clear, prioritized list of remaining tasks, implementation details, known challenges.
+-   **`## Reference Information`**: Links, code snippets, patterns, user preferences.
+-   **Actionable Start:** A clear instruction for the immediate next action.
+
+#### Potential Use Cases & Workflows
+
+The flexibility of `new_task` combined with `.clinerules` opens up many possibilities:
+
+-   **Proactive Context Window Management:** Automatically trigger handoffs at specific percentages (e.g., 50%, 70%) or token counts to maintain optimal performance.
+-   **Intelligent Breakpoints:** Instruct Cline to find logical stopping points (e.g., after completing a function or test) _after_ a context threshold is passed, ensuring cleaner handoffs.
+-   **Structured Task Decomposition:** Use Plan Mode to define subtasks, then use `.clinerules` to have Cline automatically create a new task via `new_task` upon completing each subtask.
+-   **Automated Session Summaries:** Configure the `<context>` block to always include a summary of the previous session's key discussion points.
+-   **Preloading Boilerplate/Setup:** Start new tasks related to specific projects preloaded with standard setup instructions or file templates.
+-   **"Memory Bank" Alternative:** Use `new_task` context blocks as the primary way to persist information across sessions, potentially replacing file-based memory systems.
+
+Experimenting with `.clinerules` is encouraged to discover workflows that best suit your needs!
+
+#### Example `.clinerules`: Task Handoff Strategy Guide
+
+Below is an example `.clinerules` file focused specifically on using `new_task` for context window management. **Remember, this is just one specific strategy; the core `new_task` tool can be used differently with other custom rules.**
+
+````markdown
+# You MUST use the `new_task` tool: Task Handoff Strategy Guide
+
+**CRITICAL INSTRUCTIONS - YOU MUST FOLLOW THESE GUIDELINES**
+
+This guide provides **MANDATORY** instructions for effectively breaking down complex tasks and implementing a smooth handoff process between tasks. You **MUST** follow these guidelines to ensure continuity, context preservation, and efficient task completion.
+
+## CONTEXT WINDOW MONITORING - MANDATORY ACTION REQUIRED
+
+You **MUST** monitor the context window usage displayed in the environment details. When usage exceeds 50% of the available context window, you **MUST** initiate a task handoff using the `new_task` tool.
+
+Example of context window usage over 50% with a 200K context window:
+
+\`\`\`text
+
+# Context Window Usage
+
+105,000 / 200,000 tokens (53%)
+Model: anthropic/claude-sonnet-4 (200K context window)
+\`\`\`
+
+**IMPORTANT**: When you see context window usage at or above 50%, you MUST:
+
+1. Complete your current logical step
+2. Use the `ask_followup_question` tool to offer creating a new task
+3. If approved, use the `new_task` tool with comprehensive handoff instructions
+
+## Task Breakdown in Plan Mode - REQUIRED PROCESS
+
+Plan Mode is specifically designed for analyzing complex tasks and breaking them into manageable subtasks. When in Plan Mode, you **MUST**:
+
+### 1. Initial Task Analysis - REQUIRED
+
+-   **MUST** begin by thoroughly understanding the full scope of the user's request
+-   **MUST** identify all major components and dependencies of the task
+-   **MUST** consider potential challenges, edge cases, and prerequisites
+
+### 2. Strategic Task Decomposition - REQUIRED
+
+-   **MUST** break the overall task into logical, discrete subtasks
+-   **MUST** prioritize subtasks based on dependencies (what must be completed first)
+-   **MUST** aim for subtasks that can be completed within a single session (15-30 minutes of work)
+-   **MUST** consider natural breaking points where context switching makes sense
+
+### 3. Creating a Task Roadmap - REQUIRED
+
+-   **MUST** present a clear, numbered list of subtasks to the user
+-   **MUST** explain dependencies between subtasks
+-   **MUST** provide time estimates for each subtask when possible
+-   **MUST** use Mermaid diagrams to visualize task flow and dependencies when helpful
+
+\`\`\`mermaid
+graph TD
+A[Main Task] --> B[Subtask 1: Setup]
+A --> C[Subtask 2: Core Implementation]
+A --> D[Subtask 3: Testing]
+A --> E[Subtask 4: Documentation]
+B --> C
+C --> D
+\`\`\`
+
+### 4. Getting User Approval - REQUIRED
+
+-   **MUST** ask for user feedback on the proposed task breakdown
+-   **MUST** adjust the plan based on user priorities or additional requirements
+-   **MUST** confirm which subtask to begin with
+-   **MUST** request the user to toggle to Act Mode when ready to implement
+
+## Task Implementation and Handoff Process - MANDATORY PROCEDURES
+
+When implementing tasks in Act Mode, you **MUST** follow these guidelines for effective task handoff:
+
+### 1. Focused Implementation - REQUIRED
+
+-   **MUST** focus on completing the current subtask fully
+-   **MUST** document progress clearly through comments and commit messages
+-   **MUST** create checkpoints at logical completion points
+
+### 2. Recognizing Completion Points - CRITICAL
+
+You **MUST** identify natural handoff points when:
+
+-   The current subtask is fully completed
+-   You've reached a logical stopping point in a larger subtask
+-   The implementation is taking longer than expected and can be continued later
+-   The task scope has expanded beyond the original plan
+-   **CRITICAL**: The context window usage exceeds 50% (e.g., 100,000+ tokens for a 200K context window)
+
+### 3. Initiating the Handoff Process - MANDATORY ACTION
+
+When you've reached a completion point, you **MUST**:
+
+1. Summarize what has been accomplished so far
+2. Clearly state what remains to be done
+3. **MANDATORY**: Use the `ask_followup_question` tool to offer creating a new task:
+
+\`\`\`xml
+<ask_followup_question>
+<question>I've completed [specific accomplishment]. Would you like me to create a new task to continue with [remaining work]?</question>
+<options>["Yes, create a new task", "No, continue in this session", "Let me think about it"]</options>
+</ask_followup_question>
+\`\`\`
+
+### 4. Creating a New Task with Context - REQUIRED ACTION
+
+If the user agrees to create a new task, you **MUST** use the `new_task` tool with comprehensive handoff instructions:
+
+\`\`\`xml
+<new_task>
+<context>
+
+# Task Continuation: [Brief Task Title]
+
+## Completed Work
+
+-   [Detailed list of completed items]
+-   [Include specific files modified/created]
+-   [Note any important decisions made]
+
+## Current State
+
+-   [Description of the current state of the project]
+-   [Any running processes or environment setup]
+-   [Key files and their current state]
+
+## Next Steps
+
+-   [Detailed list of remaining tasks]
+-   [Specific implementation details to address]
+-   [Any known challenges to be aware of]
+
+## Reference Information
+
+-   [Links to relevant documentation]
+-   [Important code snippets or patterns to follow]
+-   [Any user preferences noted during the current session]
+
+Please continue the implementation by [specific next action].
+</context>
+</new_task>
+\`\`\`
+
+### 5. Detailed Context Transfer - MANDATORY COMPONENTS
+
+When creating a new task, you **MUST** always include:
+
+#### Project Context - REQUIRED
+
+-   **MUST** include the overall goal and purpose of the project
+-   **MUST** include key architectural decisions and patterns
+-   **MUST** include technology stack and dependencies
+
+#### Implementation Details - REQUIRED
+
+-   **MUST** list files created or modified in the current session
+-   **MUST** describe specific functions, classes, or components implemented
+-   **MUST** explain design patterns being followed
+-   **MUST** outline testing approach
+
+#### Progress Tracking - REQUIRED
+
+-   **MUST** provide checklist of completed items
+-   **MUST** provide checklist of remaining items
+-   **MUST** note any blockers or challenges encountered
+
+#### User Preferences - REQUIRED
+
+-   **MUST** note coding style preferences mentioned by the user
+-   **MUST** document specific approaches requested by the user
+-   **MUST** highlight priority areas identified by the user
+
+## Best Practices for Effective Handoffs - MANDATORY GUIDELINES
+
+### 1. Maintain Continuity - REQUIRED
+
+-   **MUST** use consistent terminology between tasks
+-   **MUST** reference previous decisions and their rationale
+-   **MUST** maintain the same architectural approach unless explicitly changing direction
+
+### 2. Preserve Context - REQUIRED
+
+-   **MUST** include relevant code snippets in the handoff
+-   **MUST** summarize key discussions from the previous session
+-   **MUST** reference specific files and line numbers when applicable
+
+### 3. Set Clear Next Actions - REQUIRED
+
+-   **MUST** begin the handoff with a clear, actionable next step
+-   **MUST** prioritize remaining tasks
+-   **MUST** highlight any decisions that need to be made
+
+### 4. Document Assumptions - REQUIRED
+
+-   **MUST** clearly state any assumptions made during implementation
+-   **MUST** note areas where user input might be needed
+-   **MUST** identify potential alternative approaches
+
+### 5. Optimize for Resumability - REQUIRED
+
+-   **MUST** structure the handoff so the next session can begin working immediately
+-   **MUST** include setup instructions if environment configuration is needed
+-   **MUST** provide a quick summary at the top for rapid context restoration
+
+## Example Task Handoff
+
+### Example #1 of an effective task handoff:
+
+\`\`\`xml
+<new_task>
+<context>
+
+# Task Continuation: Implement User Authentication System
+
+## Completed Work
+
+-   Created basic Express.js server structure
+-   Implemented MongoDB connection and user schema
+-   Completed user registration endpoint with password hashing
+-   Added input validation using Joi
+-   Created initial test suite for registration endpoint
+
+## Current State
+
+-   Server runs successfully on port 3000
+-   MongoDB connection is established
+-   Registration endpoint (/api/users/register) is fully functional
+-   Test suite passes for all registration scenarios
+
+## Next Steps
+
+1. Implement login endpoint (/api/users/login)
+    - Use bcrypt to compare passwords
+    - Generate JWT token upon successful login
+    - Add proper error handling for invalid credentials
+2. Create authentication middleware
+    - Verify JWT tokens
+    - Extract user information
+    - Handle expired tokens
+3. Add protected routes that require authentication
+4. Implement password reset functionality
+
+## Reference Information
+
+-   JWT secret should be stored in .env file
+-   Follow the existing error handling pattern in routes/users.js
+-   User schema is defined in models/User.js
+-   Test patterns are established in tests/auth.test.js
+
+Please continue by implementing the login endpoint following the same patterns established in the registration endpoint.
+</context>
+</new_task>
+\`\`\`
+
+### Example #2 of an ineffective task handoff:
+
+_(Note: The example provided in the original rules showing "YOLO MODE Implementation" seems less like a direct handoff context block and more like a general status update with future considerations. A true ineffective handoff might lack detail in 'Current State' or 'Next Steps')._
+
+## When to Use Task Handoffs - MANDATORY TRIGGERS
+
+You **MUST** initiate task handoffs in these scenarios:
+
+1. **CRITICAL**: When context window usage exceeds 50% (e.g., 100,000+ tokens for a 200K context window)
+2. **Long-running projects** that exceed a single session
+3. **Complex implementations** with multiple distinct phases
+4. **When context window limitations** are approaching
+5. **When switching focus areas** within a larger project
+6. **When different expertise** might be beneficial for different parts of the task
+
+**FINAL REMINDER - CRITICAL INSTRUCTION**
+
+You **MUST** monitor the context window usage in the environment details section. When it exceeds 50% (e.g., "105,000 / 200,000 tokens (53%)"), you **MUST** proactively initiate the task handoff process using the `ask_followup_question` tool followed by the `new_task` tool. You MUST use the `new_task` tool.
+
+By strictly following these guidelines, you'll ensure smooth transitions between tasks, maintain project momentum, and provide the best possible experience for users working on complex, multi-session projects.
+
+```markdown
+## User Interaction & Workflow Considerations
+
+-   **Linear Flow:** Currently, using `new_task` creates a linear sequence. The old task ends, and the new one begins. The old task history remains accessible for backtracking.
+-   **User Approval:** You always have control, approving the handoff and having the chance to modify the context Cline proposes to carry forward.
+-   **Flexibility:** The core `new_task` tool is a flexible building block. Experiment with `.clinerules` to create workflows that best suit your needs, whether for strict context management, task decomposition, or other creative uses.
+```
+````
@@ -0,0 +1,113 @@
+---
+title: "Remote Browser Support"
+description: "Remote browser support allows Cline to utilize a remote Chrome instance, leveraging authentication tokens and session cookies relevant to certain web development test cases."
+---
+
+The Remote Browser feature in Cline allows the AI assistant to interact with web content directly through a controlled browser instance. This enables several powerful capabilities:
+
+-   Viewing and interacting with websites
+-   Testing locally running web applications
+-   Monitoring console logs and errors
+-   Performing browser actions like clicking, typing, and scrolling
+
+## Remote Browser in Cline
+
+### What is Remote Browser?
+
+Remote Browser allows Cline to view and interact with websites directly. This feature enables Cline to:
+
+-   Visit websites and view their content
+-   Test your locally running web applications
+-   Fill out forms and click on elements
+-   Capture screenshots of what it sees
+-   Scroll through pages to see more content
+
+### How to Use Remote Browser
+
+#### Basic Commands
+
+You can ask Cline to use the browser with simple instructions:
+
+-   **Open a website**: "Use the browser to check the website at [https://example.com](https://example.com/)"
+-   **Click on elements**: "Click the login button"
+-   **Type text**: "Type 'Hello world' in the search box"
+-   **Scroll the page**: "Scroll down to see more content"
+-   **Close the browser**: "Close the browser now"
+
+#### Example Workflows
+
+**Testing a Web Application:**
+
+```javascript
+Can you start my React app with "npm start" and then check if it's working properly at http://localhost:3000?
+```
+
+**Analyzing a Website:**
+
+```javascript
+Can you visit https://example.com and tell me what you think about its design and layout?
+```
+
+**Filling Out a Form:**
+
+```javascript
+Please go to https://example.com/contact, fill out the contact form with some test data, and submit it.
+```
+
+### Important Things to Know
+
+#### One Browser at a Time
+
+Cline can only use one browser at a time. If you want to visit a different website, you can either:
+
+-   Ask Cline to navigate to a new URL within the same browser session
+-   Ask Cline to close the current browser and open a new one
+
+#### Browser Must Be Closed Before Using Other Tools
+
+If you want Cline to edit files or run commands after using the browser, you must first ask it to close the browser:
+
+```javascript
+Close the browser and then update the CSS file to fix the alignment issue we saw.
+```
+
+#### What Cline Sees
+
+The browser has a fixed viewport size (900x600 pixels by default), similar to a small laptop screen. Cline will share screenshots after each action so you can see exactly what it sees.
+
+#### Console Logs
+
+Cline captures browser console logs, which can be helpful for debugging web applications. These logs are included with each screenshot.
+
+### Common Use Cases
+
+-   **Web Development**: Test your websites and web applications
+-   **UI/UX Review**: Get feedback on website design and usability
+-   **Content Research**: Have Cline browse websites to gather information
+-   **Form Testing**: Verify that forms work correctly
+-   **Responsive Design Testing**: Check how websites look at different screen sizes
+
+### Troubleshooting
+
+-   **If a website doesn't load**: Try providing a direct URL with the http:// or https:// prefix
+-   **If clicking doesn't work**: Try describing the location of the element more precisely
+-   **If the browser seems stuck**: Ask Cline to close the browser and try again
+
+### Using Remote Browser with VS Code in WSL
+
+When running VS Code in WSL, you'll need to configure Windows to allow WSL to connect to Chrome. Follow these steps:
+
+#### Open PowerShell as Administrator and Run:
+
+```powershell
+# Allow WSL to connect to Chrome's debugging port
+New-NetFirewallRule -DisplayName "WSL Chrome Debug" -Direction Inbound -LocalPort 9222 -Protocol TCP -Action Allow
+```
+
+#### Configure Cline in VS Code:
+
+1. Open VS Code settings
+2. Search for "Cline: Chrome Executable Path"
+3. Set the value to the path of your Chrome executable (e.g., `C:\Program Files\Google\Chrome\Application\chrome.exe`)
+
+Cline should now be able to use the Remote Browser feature from within WSL.
@@ -0,0 +1,45 @@
+---
+title: "File Mentions"
+sidebarTitle: "File Mentions"
+---
+
+File mentions let you pull any file from your workspace directly into your conversation with Cline. No more copying and pasting code snippets - just type `@/` and point to the file you need help with.
+
+When you type `@/` in the chat, Cline shows your workspace files. Navigate through folders, select the file you want, and it's instantly available to Cline - complete with all imports, related functions, and surrounding context.
+
+I use file mentions constantly when debugging. Instead of trying to figure out which parts of my code to copy over, I just reference the file directly:
+
+```
+I'm getting this error when my form submits: @terminal
+
+Here's my component: @/src/components/ContactForm.jsx
+
+And the API endpoint: @/src/api/contact.js
+
+What am I missing?
+```
+
+This gives Cline everything it needs - the error message, the component code, and the API endpoint - all without me having to copy anything. Cline can see imports, dependencies, and all the surrounding context that might be causing the issue.
+
+File mentions shine when you're dealing with complex bugs that span multiple files. Before, I'd have to carefully copy each relevant file, making sure I didn't miss anything important. Now I just reference each file with `@/` and Cline gets the complete picture.
+
+Next time you're stuck on a problem, try using file mentions instead of copying code. You'll save time and get better answers because Cline has all the context it needs.
+
+## How It Works Under the Hood
+
+When you use a file mention in your message, here's what happens behind the scenes:
+
+1. When you send your message, Cline detects the `@/path/to/file` pattern in your text
+2. The extension resolves the file path relative to your workspace root
+3. It checks if the file is binary (like an image) or text-based
+4. For text files, it reads the complete file content
+5. The file content is appended to your message in a structured format:
+    ```
+    <file_content path="path/to/file">
+    [Complete file content]
+    </file_content>
+    ```
+6. This enhanced message with the embedded file content is sent to the AI
+7. The AI can now "see" the complete file content as if you had copied and pasted it
+
+This seamless process happens automatically whenever you use a file mention, giving the AI full context without you having to manually copy anything.
@@ -0,0 +1,58 @@
+---
+title: "Folder Mentions"
+sidebarTitle: "Folder Mentions"
+---
+
+Folder mentions let you bring entire directories into your conversation with Cline. Just type `@/` followed by a folder path ending with a slash, and Cline gets access to the folder structure and its contents.
+
+When you type `@/` in chat, Cline shows your workspace files and folders. Navigate to the folder you want, make sure to include the trailing slash, and Cline will see the folder's structure and contents.
+
+I use folder mentions when I need help understanding or refactoring a whole section of my codebase. Instead of referencing individual files one by one, I can just point to the entire directory:
+
+```
+I'm trying to understand how the authentication flow works in my app.
+Can you explain the structure and relationships between the files in @/src/auth/?
+```
+
+Cline can then see all the files in the auth directory, their contents, and how they relate to each other. This gives it the full context to explain complex interactions between multiple files.
+
+Folder mentions are also perfect for getting help with project organization. When I'm unsure if my project structure makes sense, I'll ask Cline to review it:
+
+```
+I'm setting up a new React project. Does this folder structure make sense? @/src/
+What would you change to make it more maintainable as the project grows?
+```
+
+Next time you're working with multiple related files, try using folder mentions instead of referencing each file individually. You'll get more comprehensive help because Cline can see the bigger picture of how everything fits together.
+
+## How It Works Under the Hood
+
+When you use a folder mention in your message, here's what happens behind the scenes:
+
+1. When you send your message, Cline detects the `@/path/to/folder/` pattern (with trailing slash) in your text
+2. The extension resolves the folder path relative to your workspace root
+3. It calls `fs.readdir()` to get a list of all files and subdirectories in that folder
+4. For each file in the directory, it checks if it's binary or text-based
+5. For text files, it extracts the complete content
+6. The folder structure and file contents are appended to your message in a structured format:
+
+    ```
+    <folder_content path="path/to/folder">
+    ├── file1.txt
+    ├── file2.js
+    └── subfolder/
+
+    <file_content path="path/to/folder/file1.txt">
+    [File content]
+    </file_content>
+
+    <file_content path="path/to/folder/file2.js">
+    [File content]
+    </file_content>
+    </folder_content>
+    ```
+
+7. This enhanced message with the embedded folder structure and file contents is sent to the AI
+8. The AI can now "see" both the directory structure and the content of files within that directory
+
+This process happens automatically whenever you use a folder mention, giving the AI a comprehensive view of your project structure and file contents.
@@ -0,0 +1,84 @@
+---
+title: "Git Mentions"
+sidebarTitle: "Git Mentions"
+---
+
+Git mentions let you bring your repository's history and changes directly into your conversation with Cline. You can reference uncommitted changes with `@git-changes` or specific commits with `@[commit-hash]`.
+
+When you type `@` in chat, you can select "Git Changes" from the menu or type `@git-changes` directly. For specific commits, type `@` followed by the commit hash (at least 7 characters). Cline will immediately see the git status, diffs, commit messages, and other relevant information.
+
+I use git mentions constantly when I'm trying to understand code changes or troubleshoot issues introduced by recent commits. Instead of trying to copy and paste diffs or commit logs, I just ask:
+
+```
+I think this commit broke our authentication flow: @a1b2c3d
+
+Can you explain what changed and why it might be causing the issue?
+```
+
+This gives Cline the complete commit information, including the commit message, author, date, and the full diff. Cline can then analyze exactly what changed and how it might affect other parts of the codebase.
+
+The `@git-changes` mention is perfect when you're working on changes and want feedback before committing:
+
+```
+Here are my current changes: @git-changes
+
+I'm trying to implement a new feature for user profiles. Does my approach make sense?
+Are there any potential issues or improvements you'd suggest?
+```
+
+This shows Cline all your uncommitted changes, including new files, modified files, and their diffs. Cline can then review your changes and provide feedback on your implementation.
+
+Git mentions are especially powerful when combined with file mentions. When I'm investigating a bug, I'll often reference both:
+
+```
+I think this commit introduced a bug: @a1b2c3d
+
+Here's the current implementation: @/src/components/Auth.jsx
+
+How can I fix the issue while preserving the intended functionality?
+```
+
+Next time you're working with code changes or investigating issues, try using git mentions instead of manually describing or copying changes. You'll get more accurate help because Cline can see exactly what changed and in what context.
+
+## How It Works Under the Hood
+
+When you use git mentions in your message, here's what happens behind the scenes:
+
+### For Git Changes (`@git-changes`)
+
+1. When you send your message, Cline detects the `@git-changes` pattern in your text
+2. The extension runs git commands to get the current working state of your repository
+3. It captures the output of `git status` and `git diff` to see all uncommitted changes
+4. This information is appended to your message in a structured format:
+
+    ```
+    <git_working_state>
+    On branch main
+    Changes not staged for commit:
+      modified: src/components/Button.jsx
+      modified: src/styles/main.css
+
+    [Complete diff output with all changes]
+    </git_working_state>
+    ```
+
+### For Specific Commits (`@[commit-hash]`)
+
+1. When you send your message, Cline detects the `@` followed by a commit hash pattern
+2. The extension runs `git show` and related commands to get information about that commit
+3. It retrieves the commit message, author, date, and the complete diff
+4. This information is appended to your message in a structured format:
+
+    ```
+    <git_commit hash="a1b2c3d">
+    commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t
+    Author: Developer Name <dev@example.com>
+    Date: Mon May 20 14:30:45 2025 -0700
+
+    Fix authentication bug in login form
+
+    [Complete diff output showing all changes in the commit]
+    </git_commit>
+    ```
+
+This process happens automatically whenever you use git mentions, giving the AI complete visibility into your code changes without you having to copy and paste diffs or commit logs.
@@ -0,0 +1,118 @@
+---
+title: "@ Mentions Overview"
+sidebarTitle: "Overview"
+---
+
+@ mentions are one of Cline's most powerful features, letting you seamlessly bring external context into your conversations. Instead of copying and pasting code, error messages, or documentation, you can simply reference them with an @ symbol.
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/at-mentions.png" alt="@ Mentions Overview" />
+</Frame>
+
+When you type `@` in the chat input, Cline shows a menu of available mention types. These mentions let you reference files, folders, problems, terminal output, git changes, and even web content directly in your conversations.
+
+## Available @ Mentions
+
+Cline supports several types of @ mentions, each designed to bring different kinds of context into your conversations:
+
+<Columns cols={2}>
+  <Card title="File Mentions" icon="file" href="/features/at-mentions/file-mentions">
+    Reference any file in your workspace with `@/path/to/file`. Cline sees the complete file content, including imports, related
+    functions, and surrounding context.
+  </Card>
+
+{" "}
+
+<Card title="Folder Mentions" icon="folder" href="/features/at-mentions/folder-mentions">
+	Reference entire directories with `@/path/to/folder/`. Cline sees the folder structure and all file contents, perfect for
+	understanding complex interactions between multiple files.
+</Card>
+
+{" "}
+
+<Card title="Problem Mentions" icon="triangle-exclamation" href="/features/at-mentions/problem-mentions">
+	Use `@problems` to show Cline all the errors and warnings in your workspace. Cline sees the complete list with file locations
+	and error messages.
+</Card>
+
+{" "}
+
+<Card title="Terminal Mentions" icon="terminal" href="/features/at-mentions/terminal-mentions">
+	Use `@terminal` to share your recent terminal output. Cline sees the complete output with formatting preserved, perfect for
+	debugging build errors or test failures.
+</Card>
+
+{" "}
+
+<Card title="Git Mentions" icon="code-branch" href="/features/at-mentions/git-mentions">
+	Reference uncommitted changes with `@git-changes` or specific commits with `@[commit-hash]`. Cline sees the complete diff,
+	commit message, and other relevant information.
+</Card>
+
+  <Card title="URL Mentions" icon="globe" href="/features/at-mentions/url-mentions">
+    Reference web content with `@https://example.com`. Cline fetches and sees the complete webpage content, perfect for
+    referencing documentation or GitHub issues.
+  </Card>
+</Columns>
+
+## Why @ Mentions Matter
+
+@ mentions transform how you interact with Cline by:
+
+1. **Eliminating copy-paste**: No more copying and pasting code, error messages, or terminal output. Just reference them directly.
+
+2. **Preserving context**: Cline sees the complete context, including imports, related functions, and surrounding code that might be relevant.
+
+3. **Maintaining formatting**: Terminal output, error messages, and web content keep their formatting, making them easier to understand.
+
+4. **Enabling complex workflows**: Combine multiple @ mentions to give Cline a complete picture of your problem:
+
+    ```
+    I'm getting these errors: @problems
+
+    Here's my component: @/src/components/Form.jsx
+    And the API endpoint: @/src/api/users.js
+
+    The error happens when I submit: @terminal
+
+    I think this commit might have caused it: @a1b2c3d
+    ```
+
+## Getting Started
+
+To use @ mentions:
+
+1. Type `@` in the chat input
+2. Select the type of mention from the menu or continue typing
+3. For files and folders, navigate through your workspace structure
+4. Send your message as usual
+
+Cline will automatically process the mentions and include the referenced content in the context sent to the AI.
+
+Try using @ mentions in your next conversation with Cline - you'll be amazed at how much more efficient and effective your interactions become when you can seamlessly bring in external context.
+
+## How It Works Under the Hood
+
+When you use @ mentions in your messages, there's a sophisticated process happening behind the scenes:
+
+1. **Detection**: When you send a message, Cline scans the text for @ mention patterns using regular expressions
+2. **Processing**: For each detected mention, Cline:
+    - Determines the mention type (file, folder, problems, terminal, git, URL)
+    - Fetches the relevant content (file contents, terminal output, etc.)
+    - Formats the content appropriately
+3. **Enhancement**: The original message is enhanced with structured data:
+
+    ```
+    Your original message with @/path/to/file
+
+    <file_content path="/path/to/file">
+    [Complete file content]
+    </file_content>
+    ```
+
+4. **Context Inclusion**: This enhanced message with all the embedded content is sent to the AI model
+5. **Seamless Response**: The AI can now "see" all the referenced content as if you had manually copied and pasted it
+
+This entire process happens automatically and seamlessly whenever you use @ mentions, giving the AI complete context without you having to manually copy anything.
+
+Each type of @ mention has its own specific implementation details, which you can find in their respective documentation pages.
@@ -0,0 +1,52 @@
+---
+title: "Problem Mentions"
+sidebarTitle: "Problem Mentions"
+---
+
+The problems mention gives Cline instant access to all the errors and warnings in your workspace. Just type `@problems` and Cline can see every diagnostic issue VSCode has detected.
+
+When you type `@` in chat, select "Problems" from the menu or just type `@problems` directly. Cline will immediately see all the errors and warnings from your workspace, complete with file locations and error messages.
+
+I use the problems mention constantly when I'm stuck on build errors or TypeScript issues. Instead of trying to describe the errors or copy them one by one, I just ask:
+
+```
+I'm getting these TypeScript errors and I'm not sure how to fix them: @problems
+
+Can you help me understand what's wrong and how to fix it?
+```
+
+This gives Cline the complete list of errors with their exact locations and messages. Cline can then analyze the patterns across multiple errors and suggest comprehensive solutions.
+
+The problems mention is especially powerful when combined with file mentions. When I'm dealing with complex type errors, I'll reference both:
+
+```
+I'm getting these type errors: @problems
+
+Here's my component: @/src/components/DataTable.tsx
+And the types file: @/src/types/api.ts
+
+How can I fix these issues?
+```
+
+This approach gives Cline everything it needs - the exact errors, the component code, and the type definitions - all without me having to copy anything manually.
+
+Next time you're stuck on errors, try using `@problems` instead of copying error messages. You'll get more accurate help because Cline can see the complete error context and locations.
+
+## How It Works Under the Hood
+
+When you use the problems mention in your message, here's what happens behind the scenes:
+
+1. When you send your message, Cline detects the `@problems` pattern in your text
+2. The extension calls VSCode's built-in `vscode.languages.getDiagnostics()` API to get all errors and warnings
+3. It formats these diagnostics into a structured text representation with file paths, line numbers, and error messages
+4. The formatted problems list is appended to your message in a structured format:
+    ```
+    <workspace_diagnostics>
+    /path/to/file.js:10:5 - error TS2322: Type 'string' is not assignable to type 'number'.
+    /path/to/file.js:15:3 - warning: This variable is never used.
+    </workspace_diagnostics>
+    ```
+5. This enhanced message with the embedded diagnostics is sent to the AI
+6. The AI can now "see" all the errors and warnings in your workspace, complete with their locations and messages
+
+This process happens automatically whenever you use the problems mention, giving the AI a comprehensive view of all the issues in your workspace without you having to copy them manually.
@@ -0,0 +1,73 @@
+---
+title: "Terminal Mentions"
+sidebarTitle: "Terminal Mentions"
+---
+
+The terminal mention lets you bring your terminal output directly into your conversation with Cline. Just type `@terminal` and Cline can see the recent output from your terminal.
+
+When you type `@` in chat, select "Terminal" from the menu or just type `@terminal` directly. Cline will immediately see the recent output from your active terminal, including error messages, build logs, or command results.
+
+I use the terminal mention all the time when I'm dealing with build errors, test failures, or debugging output. Instead of trying to copy and paste terminal output (which often loses formatting), I just ask:
+
+```
+I'm getting this error when running my tests: @terminal
+
+What's causing this and how can I fix it?
+```
+
+This gives Cline the complete terminal output with all its formatting intact. Cline can then analyze the error messages, stack traces, and surrounding context to provide more accurate help.
+
+The terminal mention is especially powerful when combined with file mentions. When I'm debugging a failed API call, I'll reference both:
+
+```
+I'm getting this error when calling my API: @terminal
+
+Here's my API client code: @/src/api/client.js
+And the endpoint implementation: @/src/server/routes/users.js
+
+What am I doing wrong?
+```
+
+This approach gives Cline everything it needs - the exact error output, the client code, and the server implementation - all without me having to copy anything manually.
+
+Next time you're running into issues with command output or build errors, try using `@terminal` instead of copying the output. You'll get more accurate help because Cline can see the complete terminal context with proper formatting.
+
+## How It Works Under the Hood
+
+When you use the terminal mention in your message, here's what happens behind the scenes:
+
+1. When you send your message, Cline detects the `@terminal` pattern in your text
+2. The extension calls `getLatestTerminalOutput()` which accesses VSCode's terminal API
+3. It captures the recent output buffer from your active terminal
+4. The terminal output is appended to your message in a structured format:
+
+    ```
+    <terminal_output>
+    $ npm run test
+    > project@1.0.0 test
+    > jest
+
+    FAIL src/components/__tests__/Button.test.js
+    ● Button component › renders correctly
+
+    [Complete terminal output with formatting preserved]
+    </terminal_output>
+    ```
+
+5. This enhanced message with the embedded terminal output is sent to the AI
+6. The AI can now "see" the complete terminal output with all formatting preserved
+
+This process happens automatically whenever you use the terminal mention, giving the AI access to your command results, error messages, and other terminal output without you having to copy it manually.
+
+## Troubleshooting Terminal Issues
+
+If you're experiencing issues with terminal mentions or terminal integration in general (such as "Shell Integration Unavailable" or commands not showing output), please refer to our comprehensive [Terminal Integration Troubleshooting Guide](/troubleshooting/terminal-integration-guide).
+
+Common issues include:
+
+-   Terminal mentions not capturing output
+-   "Shell Integration Unavailable" messages in Cline chat
+-   Commands executing but output not visible to Cline
+-   Terminal integration working inconsistently
+
+The troubleshooting guide provides platform-specific solutions and detailed configuration steps to resolve these issues.
@@ -0,0 +1,65 @@
+---
+title: "URL Mentions"
+sidebarTitle: "URL Mentions"
+---
+
+URL mentions let you bring web content directly into your conversation with Cline. Just type `@` followed by any URL, and Cline can see the content of that webpage without you having to copy and paste anything.
+
+When you type `@` in chat followed by a URL (like `@https://example.com`), Cline will fetch the content of that webpage and include it in the context. This works for documentation pages, GitHub issues, Stack Overflow questions, or any other web content you want to reference.
+
+I use URL mentions constantly when I'm working with external APIs or libraries. Instead of trying to explain how an API works or copying documentation snippets, I just reference the docs directly:
+
+```
+I'm trying to implement authentication with this API: @https://api.example.com/docs/auth
+
+Can you help me write the code to get an access token based on these docs?
+```
+
+This gives Cline the complete documentation page, so it can see all the authentication requirements, endpoints, parameters, and examples. Cline can then provide more accurate and comprehensive help based on the official documentation.
+
+URL mentions are especially useful for referencing GitHub issues or discussions:
+
+```
+I'm trying to fix this issue in our project: @https://github.com/our-org/our-repo/issues/123
+
+Here's my current implementation: @/src/components/Feature.jsx
+
+What changes do I need to make to address the issue?
+```
+
+This shows Cline the complete GitHub issue, including the description, comments, and any code snippets or screenshots. Cline can then help you implement a solution that directly addresses the reported issue.
+
+Next time you're working with external documentation or online resources, try using URL mentions instead of copying and pasting content. You'll get more accurate help because Cline can see the complete context of the webpage, including formatting, code examples, and surrounding information.
+
+## How It Works Under the Hood
+
+When you use a URL mention in your message, here's what happens behind the scenes:
+
+1. When you send your message, Cline detects the `@http://...` or `@https://...` pattern in your text
+2. The extension launches a headless browser (Puppeteer) in the background
+3. It navigates to the URL and waits for the page to load completely
+4. The browser captures the page content, including text, formatting, and code examples
+5. The content is converted to a Markdown format that preserves the structure
+6. This content is appended to your message in a structured format:
+
+    ```
+    <url_content url="https://example.com/docs">
+    # Example API Documentation
+
+    ## Authentication
+
+    To authenticate with the API, you need to...
+
+    const token = await api.authenticate({
+      username: 'user',
+      password: 'pass'
+    });
+
+    [Complete webpage content in Markdown format]
+    </url_content>
+    ```
+
+7. The browser is then closed to free up resources
+8. This enhanced message with the embedded webpage content is sent to the AI
+
+This process happens automatically whenever you use a URL mention, giving the AI access to the complete content of the webpage without you having to copy and paste anything.
@@ -1,12 +1,12 @@
 ---
-title: "Auto Approve & YOLO Mode"
+title: "Auto Approve"
 sidebarTitle: "Auto Approve"
-description: "Control which actions Cline can take without asking for approval."
+description: "Let Cline take specific actions without asking for approval every time."
 ---

-Auto Approve lets you decide which actions Cline can take without prompting you each time. It keeps you out of approval popups during routine work while letting you keep tight control over high-risk actions.
+Auto Approve lets you decide which actions Cline can take without prompting you each time. It keeps you out of approval popups during routine work, while still letting you keep tight control over high-risk actions.

-If you find yourself repeatedly clicking approve for the same safe operations, Auto Approve fixes that.
+If you find yourself repeatedly clicking approve for the same safe operations, Auto Approve is the setting that fixes that. The goal is fewer interruptions without losing the ability to review changes when it matters.

 <Frame>
 	<video
@@ -18,100 +18,90 @@ If you find yourself repeatedly clicking approve for the same safe operations, A
 	/>
 </Frame>

-## How It Works
+## How it works

-Auto Approve is evaluated per tool call. When Cline is about to read a file, edit a file, run a command, or use the browser, it checks your Auto Approve settings for that category.
+Auto Approve is evaluated per tool call. When Cline is about to read a file, edit a file, run a command, or use the browser, Cline checks your Auto Approve settings for that category.

-A few details matter:
+A few details matter in practice:

- **Workspace vs outside workspace**: "Read all files" and "Edit all files" only extend the base toggle. If the base toggle is off, the "all files" option does nothing.
- **Terminal commands**: Cline treats commands as either safe or requiring approval. "Execute safe commands" covers safe commands. "Execute all commands" extends to commands flagged as requiring approval.
- **Notifications**: If enabled, Cline sends OS-level notifications when approval is required, and when an auto-approved terminal command has been running for 30 seconds.
+- **Workspace vs outside your workspace**: “Read all files” and “Edit all files” only extend the base toggle. If the base toggle is off, the “all files” option does nothing.
+
+- **Terminal commands**: Cline treats terminal commands as either safe or requiring approval. “Execute safe commands” covers the first category. “Execute all commands” extends this to commands flagged as requiring approval.
+
+- **Notifications**: If enabled, Cline sends OS-level notifications when approval is required, and when an auto-approved terminal command has been running for 30 seconds and may need attention.
+
+<Note>
+	[YOLO mode](/features/yolo-mode) bypasses these granular approvals.
+</Note>

 ## Permissions

-| Setting | What It Allows |
-|---------|----------------|
-| Read project files | Read files, list files, search in your workspace |
-| Read all files | Read files outside your workspace (requires base toggle) |
-| Edit project files | Create and edit files in your workspace |
-| Edit all files | Edit files outside your workspace (requires base toggle) |
-| Execute safe commands | Run terminal commands marked safe |
-| Execute all commands | Run commands requiring approval (requires base toggle) |
-| Use the browser | Browser tool for web fetching and searching |
-| Use MCP servers | MCP tools and resources |
-| Enable notifications | Notifies you about long-running commands |
+These labels match what you see in the Auto Approve menu.
+
+| Setting | What it allows | Notes |
+|--------|-----------------|------|
+| Read project files | Read files, list files, search in your workspace | Good default for most tasks |
+| Read all files | Read files outside your workspace | Requires “Read project files” |
+| Edit project files | Create and edit files in your workspace | Consider using checkpoints |
+| Edit all files | Edit files outside your workspace | Requires “Edit project files” |
+| Execute safe commands | Run terminal commands marked safe | Can still run long |
+| Execute all commands | Run commands marked as requiring approval | Requires “Execute safe commands” |
+| Use the browser | Allows use of the browser tool for web fetching and searching | Proxy issues can apply |
+| Use MCP servers | Use MCP tools and access MCP resources | Some servers also have per-tool auto-approve |
+| Enable notifications | Notifies you about long-running auto-approved commands | Accessible directly in the Auto Approve menu |

 <Warning>
-"Read all files" and "Edit all files" only matter if their base toggle is enabled. They extend access outside your workspace.
+	“Read all files” and “Edit all files” only matter if their base toggle is enabled. They extend access outside your workspace.
 </Warning>

-## Safe vs Approval-Required Commands
+<Card title="Networking & proxies" icon="globe" href="/troubleshooting/networking-and-proxies">
+	If browser-based tools fail in corporate networks, this page covers the common fixes.
+</Card>

-Cline does not use a fixed allowlist. The model marks each command with a `requires_approval` flag based on the command and arguments. These are examples, not guarantees.
+## Safe vs approval-required command examples

-**Commonly treated as safe:**
- `npm run build`, `npm test` - Build/test output
- `git status`, `ls -la`, `cat package.json` - Read-only commands
+Cline does not use a fixed allowlist of safe or unsafe commands. The model marks each command with a `requires_approval` flag based on the command and its arguments, and Auto Approve uses that flag.
+
+These are examples, not guarantees.
+
+### Commonly treated as safe
+
+| Example | Why it is usually safe |
+|--------|-------------------------|
+| `npm run build` | Build output, no direct file deletions |
+| `npm test` | Runs tests |
+| `git status` | Read-only |
+| `ls -la` | Read-only |
+| `cat package.json` | Read-only |
+
+### Commonly requires approval
+
+| Example | Why it often needs approval |
+|--------|------------------------------|
+| `npm install <pkg>` | Modifies dependencies and lockfiles |
+| `rm -rf <path>` | Deletes files |
+| `mv <a> <b>` | Moves files (can overwrite) |
+| `sed -i ...` | In-place file edits |
+| `curl https://...` | Downloads and executes remote code |
+
+<Note>
+	Whether a command is treated as safe depends on the exact command, flags, and the current task. When in doubt, keep command auto-approval off and approve commands manually.
+</Note>
+
+## Enable notifications
+
+Auto-approved actions can run for a while, especially long terminal commands. If you enable notifications, Cline can notify you when an auto-approved command has been running for a while and may need attention.
+
+The **Enable notifications** toggle is located at the bottom of the Auto Approve menu, below a separator line. This puts the notification setting right where you manage your auto-approval permissions, making it easy to discover and adjust.

-**Commonly requires approval:**
- `npm install <pkg>` - Modifies dependencies
- `rm -rf <path>` - Deletes files
- `mv <a> <b>` - Moves files (can overwrite)
- `sed -i ...` - In-place file edits

 ## Recommendations

-A good default setup:
+A good default setup is:
+
 - Enable **Read project files**
- Leave edits, commands, browser, and MCP off until you have a specific reason
+- Leave **Edit project files**, **Execute safe commands**, **Use the browser**, and **Use MCP servers** off until you have a specific reason to enable them

-If you enable edits, use [Checkpoints](/core-workflows/checkpoints) so you can roll back quickly.
+If you enable edits, use [Checkpoints](/features/checkpoints) so you can roll back quickly.

---
-
-## YOLO Mode
-
-YOLO mode is Auto Approve on steroids. Check the box and Cline auto-approves everything: file changes, terminal commands, browser actions, MCP tools, and mode transitions.
-
-<Note>
-**Warning: This is dangerous.** YOLO mode disables all safety checks. Cline executes whatever it decides without asking permission.
-</Note>
-
-### What Gets Auto-Approved
-
-When YOLO mode is enabled:
- All file operations anywhere on your system
- All terminal commands including potentially destructive ones
- Browser actions
- MCP server tools
- Mode transitions (Plan to Act)
-
-### When to Use YOLO Mode
-
-**Rapid prototyping** where you want zero friction and don't care about potential mistakes. Perfect for throwaway experiments.
-
-**Trusted, repetitive tasks** where you've validated Cline's approach and want to eliminate approval overhead.
-
-**Demonstration purposes** where you want to show Cline's capabilities without interruptions.
-
-### What Could Go Wrong
-
-Cline could:
- Delete important files without warning
- Execute commands that modify system settings
- Make network requests to external services
- Overwrite configuration files
- Install or uninstall packages
- Commit and push changes to version control
-
-### Best Practices for YOLO Mode
-
- **Start with isolated environments.** Use throwaway projects or sandboxed environments first.
- **Be specific with requests.** Vague instructions + unlimited permissions = unpredictable results.
- **Monitor the output.** Cline still shows what it's doing. Watch the terminal and file changes.
- **Keep version control handy.** Git becomes your safety net.
-
-### Enabling YOLO Mode
-
-Navigate to Cline Settings, then Features, and check "YOLO Mode." No confirmation dialogs. Once enabled, Cline auto-approves all actions immediately. Uncheck to disable.
+If you’re working in a sensitive environment (production credentials, personal files, corporate devices), keep external file access and command execution locked down and approve actions manually as you go.
@@ -1,64 +1,75 @@
 ---
-title: "Auto Compact"
+title: "Automatic Context Summarization"
 sidebarTitle: "Auto Compact"
-description: "Automatic context summarization to keep working when approaching context limits."
 ---

-When your conversation approaches the model's context window limit, Cline automatically summarizes it to free up space and keep working.
+When your conversation approaches the model's context window limit, Cline automatically summarizes it to free up space and keep working. 

 <Frame>
 	<img
 		src="https://storage.googleapis.com/cline_public_images/docs/assets/condensing.png"
-		alt="Auto-compact condensing conversation context"
+		alt="Auto-compact feature condensing conversation context"
 	/>
 </Frame>

 ## How It Works

-Cline monitors token usage during your conversation. When you're getting close to the limit, it:
+Cline monitors token usage during your conversation. When you're getting close to the limit, he:

 1. Creates a comprehensive summary of everything that's happened
-2. Preserves all technical details, code changes, and decisions
+2. Preserves all the technical details, code changes, and decisions
 3. Replaces the conversation history with the summary
-4. Continues exactly where it left off
+4. Continues exactly where he left off

-You'll see a summarization tool call when this happens, showing the cost like any other API call.
+You'll see a summarization tool call when this happens, showing the total cost like any other api call in the chat view.

 ## Why This Matters

-Previously, Cline would truncate older messages when hitting context limits, losing important context.
+Previously, Cline would truncate older messages when hitting context limits. This meant losing important context from earlier in the conversation.

 Now with summarization:
 - All technical decisions and code patterns are preserved
 - File changes and project context remain intact
- Cline remembers everything it's done
+- Cline remembers everything he's done
 - You can work on much larger projects without interruption

 <Tip>
-Auto Compact works beautifully with [Focus Chain](/features/focus-chain). When Focus Chain is enabled, todo lists persist across summarizations. Cline can work on long-horizon tasks spanning multiple context windows while staying on track.
+Context Summarization synergizes beautifully with [Focus Chain](/features/focus-chain). When Focus Chain is enabled, todo lists persist across summarizations. This means Cline can work on long-horizon tasks that span multiple context windows while staying on track with the todo list guiding him through each reset.
 </Tip>

+## Technical Details
+
+The summarization happens through your configured API provider using the same model you're already using. It leverages prompt caching to minimize costs.
+
+1. Cline uses a [summarization prompt](https://github.com/cline/cline/blob/main/src/core/prompts/contextManagement.ts) to request a summary of the conversation.
+
+2. Once the summary is generated, Cline replaces the conversation history with a [continuation prompt](https://github.com/cline/cline/blob/main/src/core/prompts/contextManagement.ts#L69) that asks Cline to keep working and provides the summary as context.
+
+Different models have different context window thresholds for when auto-summarization kicks in. You can see how thresholds are determined in [context-window-utils.ts](https://github.com/cline/cline/blob/main/src/core/context/context-management/context-window-utils.ts). 
+
 ## Cost Considerations

 Summarization leverages your existing prompt cache from the conversation, so it costs about the same as any other tool call.

-Since most input tokens are already cached, you're primarily paying for summary generation (output tokens), making it cost-effective.
+Since most input tokens are already cached, you're primarily paying for the summary generation (output tokens), making it very cost-effective.

-## Supported Models
+## Restoring Context with Checkpoints

-Auto Compact uses advanced LLM-based summarization for these models:
-
- Claude 4 series
- Gemini 2.5 series
- GPT-5
- Grok 4
+You can use [checkpoints](/features/checkpoints) to restore your task state from before a summarization occurred. This means you never truly lose context - you can always roll back to previous versions of your conversation. 

 <Note>
-With other models, Cline falls back to standard rule-based context truncation, even if Auto Compact is enabled.
+  Editing a message before a summarization tool call will work similarly to a checkpoint, allowing you to restore the conversation to that point.
 </Note>

-## Restoring Context
+## Next Generation Model Support

-You can use [checkpoints](/core-workflows/checkpoints) to restore your task state from before a summarization occurred. You never truly lose context since you can always roll back.
+Auto Compact uses advanced LLM-based summarization which we've found works significantly better for next-generation models. We currently support this feature for the following models:

-Editing a message before a summarization tool call works similarly, restoring the conversation to that point.
+- **Claude 4 series**
+- **Gemini 2.5 series**
+- **GPT-5**
+- **Grok 4**
+
+<Note>
+When using other models, Cline automatically falls back to the standard rule-based context truncation method, even if Auto Compact is enabled in settings.
+</Note>
@@ -0,0 +1,103 @@
+---
+title: "Checkpoints"
+sidebarTitle: "Checkpoints"
+---
+
+Checkpoints automatically save snapshots of your workspace after each step in a task. This feature lets you track changes, roll back when needed, and experiment confidently with your code.
+
+## How Checkpoints Work
+
+Cline creates a checkpoint after each tool use (file edits, commands, etc.). These checkpoints:
+
+-   Work alongside your Git workflow without interference
+-   Maintain context between restores
+-   Use a shadow Git repository to track changes
+
+For example, if you're working on a feature and Cline makes multiple file changes, each change creates a checkpoint. This means you can review each modification and, if needed, roll back to any point without affecting your main Git repository.
+
+## Enabling or Disabling Checkpoints
+
+Checkpoints are enabled by default in Cline. To toggle this feature:
+
+1. Open the Cline settings by clicking the gear icon in the Cline panel
+2. Go to "Feature Settings"
+3. Toggle the **"Enable Checkpoints"** checkbox on or off
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/checkpoints.gif"
+		alt="Checkpoints toggle in settings"
+	/>
+</Frame>
+
+### When to Disable Checkpoints
+
+While checkpoints provide valuable safety nets, you might want to disable them in certain situations:
+
+-   **Large repositories**: If you're working with very large codebases, checkpoints may use additional storage space
+-   **Performance concerns**: On systems with limited resources, disabling checkpoints can slightly improve performance
+-   **Simple tasks**: For quick, low-risk operations where rollback isn't needed
+
+
+## Viewing Changes & Restoring
+
+After each tool use, you can:
+
+1. Click the "Compare" button to see modified files
+2. Click the "Restore" button to open restore options
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(13).png"
+		alt="Checkpoint comparison and restore options"
+	/>
+</Frame>
+
+## Restore Options
+
+To restore to a previous point:
+
+1. Click the "Restore" button next to any step
+2. Choose from three options:
+    - **Restore Task and Workspace**: Reset both codebase and task to that point
+    - **Restore Task Only**: Keep codebase changes but revert task context
+    - **Restore Workspace Only**: Reset codebase while preserving task context
+
+Example: If Cline makes changes you don't like while styling a component, you can use "Restore Workspace Only" to revert the code changes while keeping the conversation context, allowing you to try a different approach.
+
+<Frame caption="Reverting both codebase and task to before any changes were made to start fresh">
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/checkpointsDemo.gif" alt="Checkpoint restore demo" />
+</Frame>
+
+## Use Cases
+
+Checkpoints let you be more experimental with Cline. While human coding is often methodical and iterative, AI can make substantial changes quickly. Checkpoints help you track these changes and revert if needed.
+
+### Using Auto-Approve Mode
+
+-   Provides safety net for rapid iterations
+-   Makes it easy to undo unexpected results
+
+### Testing Different Approaches
+
+-   Try multiple solutions confidently
+-   Compare different implementations
+-   Quickly revert to working states
+-   Ideal for exploring different design patterns or architectural approaches
+
+## Best Practices
+
+1. Use checkpoints as safety nets when experimenting
+2. Leverage auto-approve mode more confidently, knowing you can always roll back
+3. Restore selectively based on needs:
+    - Use "Restore Task and Workspace" for a fresh start
+    - Use "Restore Task Only" to try different prompts, but keep file changes
+    - Use "Restore Workspace Only" to attempt different implementations while preserving conversation context
+
+## Relationship with Message Editing
+
+The [message editing feature](/features/editing-messages) uses checkpoints under the hood when you select the "Restore All" option. This allows you to not only edit and resubmit your message but also restore your workspace to the state it was in at that point in the conversation.
+
+## Deleting Checkpoints
+
+You can delete all checkpoints by using the **"Delete All History"** button in the task history menu. Note that this will also delete all tasks. Checkpoints are stored in VS Code's globalStorage.
@@ -0,0 +1,267 @@
+---
+title: "Conditional Rules"
+sidebarTitle: "Conditional Rules"
+description: "Activate rules automatically based on which files you're working with"
+---
+
+Conditional rules let you scope rules to specific parts of your codebase. Rules activate only when you're working with matching files, keeping your context focused and relevant.
+
+For an introduction to Cline Rules, see the [Overview](/features/cline-rules/overview).
+
+- **Without conditionals**: every rule loads for every request. 
+- **With conditionals**, rules activate only when your current files match their defined scope.
+
+For example, React component rules should appear when you're working with React components, not when you're editing Python or documentation.
+
+## How It Works
+
+Conditional rules use YAML frontmatter at the top of your rule files. When Cline processes a request, it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule's conditions, and activates matching rules.
+
+<Note>
+When a conditional rule activates, you'll see a notification: **"Conditional rules applied: workspace:frontend-rules.md"**
+</Note>
+
+## Writing Conditional Rules
+
+Add YAML frontmatter to the top of any rule file in your `.clinerules/` directory:
+
+```yaml
+---
+paths:
+  - "src/components/**"
+  - "src/hooks/**"
+---
+
+# React Component Guidelines
+
+When creating or modifying React components:
+- Use functional components with React hooks
+- Extract reusable logic into custom React hooks
+- Keep components focused on a single responsibility
+```
+
+The `---` markers delimit the frontmatter. Everything after the closing `---` is your rule content.
+
+### The `paths` Conditional
+
+Currently, `paths` is the supported conditional. It takes an array of glob patterns:
+
+```yaml
+---
+paths:
+  - "src/**"           # All files under src/
+  - "*.config.js"      # Config files in root
+  - "packages/*/src/"  # Monorepo package sources
+---
+```
+
+**Glob pattern syntax:**
+- `*` matches any characters except `/`
+- `**` matches any characters including `/` (recursive)
+- `?` matches a single character
+- `[abc]` matches any character in the brackets
+- `{a,b}` matches either pattern
+
+**Examples:**
+
+| Pattern | Matches |
+|---------|---------|
+| `src/**/*.ts` | All TypeScript files under `src/` |
+| `*.md` | Markdown files in root only |
+| `**/*.test.ts` | Test files anywhere in the project |
+| `packages/{web,api}/**` | Files in web or api packages |
+| `src/components/*.tsx` | TSX files directly in components (not nested) |
+
+### Behavior Details
+
+**Multiple patterns**: A rule activates if any pattern matches any file in your context.
+
+```yaml
+---
+paths:
+  - "frontend/**"
+  - "mobile/**"
+---
+# Activates when working in frontend OR mobile
+```
+
+**No frontmatter**: Rules without frontmatter are always active.
+
+**Empty paths array**: `paths: []` means the rule never activates. Use this to temporarily disable a rule.
+
+**Invalid YAML**: If frontmatter can't be parsed, Cline fails open: the rule activates with raw content visible to help debugging.
+
+## What Counts as "Current Context"
+
+Cline evaluates rules based on:
+
+1. **Your message**: File paths mentioned in your prompt (e.g., "update `src/App.tsx`")
+2. **Open tabs**: Files currently open in your editor
+3. **Visible files**: Files visible in your active editor panes
+4. **Edited files**: Files Cline has created, modified, or deleted during the task
+5. **Pending operations**: Files Cline is about to edit
+
+Conditional rules can activate on your first message, when relevant files are open, or mid-task when Cline starts working with matching files.
+
+<Tip>
+Be explicit about file paths in your prompts. "Update `src/services/user.ts`" reliably triggers path-based rules; "update the user service" may not.
+</Tip>
+
+## Practical Examples
+
+Copy these patterns and adapt them to your project structure.
+
+### Frontend vs Backend Rules
+
+Keep frontend and backend rules separate to avoid noise. Frontend rules only load when working with UI code, backend rules only load when working with API or service code.
+
+```yaml
+# .clinerules/frontend.md
+---
+paths:
+  - "src/components/**"
+  - "src/pages/**"
+  - "src/hooks/**"
+---
+
+# Frontend Guidelines
+
+- Use Tailwind CSS for styling
+- Prefer server components where possible
+- Keep client components small and focused
+```
+
+```yaml
+# .clinerules/backend.md
+---
+paths:
+  - "src/api/**"
+  - "src/services/**"
+  - "src/db/**"
+---
+
+# Backend Guidelines
+
+- Use dependency injection for services
+- All database queries go through repositories
+- Return typed errors, not thrown exceptions
+```
+
+### Test File Rules
+
+Enforce testing standards automatically. This rule activates only when you're writing or modifying tests, so testing guidance appears exactly when you need it.
+
+```yaml
+# .clinerules/testing.md
+---
+paths:
+  - "**/*.test.ts"
+  - "**/*.spec.ts"
+  - "**/__tests__/**"
+---
+
+# Testing Standards
+
+- Use descriptive test names: "should [expected behavior] when [condition]"
+- One assertion per test when possible
+- Mock external dependencies, not internal modules
+- Use factories for test data, not fixtures
+```
+
+### Documentation Rules
+
+Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you're writing code.
+
+```yaml
+# .clinerules/docs.md
+---
+paths:
+  - "docs/**"
+  - "**/*.md"
+  - "**/*.mdx"
+---
+
+# Documentation Guidelines
+
+- Use sentence case for headings
+- Include code examples for all features
+- Keep paragraphs short (3-4 sentences max)
+- Link to related documentation
+```
+
+## Combining with Rule Toggles
+
+Conditional rules work alongside the rule toggle UI. Toggle off a conditional rule to disable it entirely (it won't activate even if paths match). Toggle on to let it activate when conditions are met.
+
+This provides two levels of control: manual toggles and automatic condition-based activation.
+
+## Tips for Effective Conditional Rules
+
+### Start Broad, Then Narrow
+
+Begin with broader patterns and refine as you learn what works:
+
+```yaml
+# Start here
+paths:
+  - "src/**"
+
+# Then narrow down
+paths:
+  - "src/features/auth/**"
+```
+
+### Use Descriptive Filenames
+
+Name your rule files to indicate their scope:
+
+```
+.clinerules/
+├── api-endpoints.md      # Rules for API code
+├── database-models.md    # Rules for DB layer
+├── react-components.md   # Rules for React
+└── universal.md          # No frontmatter = always active
+```
+
+### Keep Universal Rules Separate
+
+Put always-on rules (coding standards, project conventions) in files without frontmatter. Reserve conditional rules for context-specific guidance.
+
+### Test Your Patterns
+
+Not sure if a pattern matches? Create a simple test rule:
+
+```yaml
+---
+paths:
+  - "your/pattern/here/**"
+---
+
+TEST: This rule should activate for your/pattern/here files.
+```
+
+Then work with a file in that path and check if you see the activation notification.
+
+## Troubleshooting
+
+**Rule not activating:**
+- Check that file paths in your context match the glob pattern
+- Verify the rule is toggled on in the rules panel
+- Ensure YAML frontmatter has proper `---` delimiters
+
+**Rule activating unexpectedly:**
+- Review glob patterns: `**` is recursive and may match more than intended
+- Check for open files that match the pattern
+- File paths mentioned in your message also count as context
+
+**Frontmatter showing in output:**
+- YAML couldn't be parsed
+- Check for syntax errors (unquoted special characters, improper indentation)
+
+## Related
+
+- [Cline Rules Overview](/features/cline-rules/overview) - Complete rules system guide
+- [Skills](/features/skills) - Load instructions on demand with `/skill` command
+- [Workflows](/features/slash-commands/workflows/index) - Define explicit task automation
+- [@ Mentions](/features/at-mentions/overview) - Add files to context explicitly
+- [Understanding Context Management](/prompting/understanding-context-management) - How Cline manages context window
@@ -0,0 +1,205 @@
+---
+title: "Cline Rules"
+sidebarTitle: "Overview"
+description: "Add persistent instructions and context to guide Cline's behavior"
+---
+
+Cline Rules provide system-level guidance for your projects. Rules persist across conversations, ensuring consistent behavior without repeating instructions in every chat.
+
+## How It Works
+
+Rules are loaded when Cline starts a task. Here's what happens:
+
+**Loading order**: Cline checks for rules in this sequence:
+1. `.clinerules/` folder (all `.md` files inside)
+2. Single `.clinerules` file
+3. `AGENTS.md` file
+
+**Scope precedence**: Workspace rules override global rules when both define the same guidance.
+
+**Multiple files**: When using a `.clinerules/` folder, all Markdown files are combined into one ruleset. Numeric prefixes (like `01-`, `02-`) control the order.
+
+**Conditional activation**: Rules with YAML frontmatter activate only when you're working with matching files. See [Conditional Rules](/features/cline-rules/conditional-rules) for details.
+
+## Supported Rule Files
+
+Cline reads rules from multiple file formats in your workspace root, letting you share rules across different AI coding tools:
+
+| File/Folder | Source | Notes |
+|-------------|--------|-------|
+| `.clinerules/` | Cline | Folder with `.md` files (recommended) |
+| `.cursor/rules/` | Cursor | Folder with `.mdc` files |
+| `.windsurf/rules` | Windsurf | Folder with multiple `md` files |
+| `AGENTS.md` | Universal | Follows [agents.md](https://agents.md/) standard, searched recursively |
+
+Cline prioritizes `.clinerules` when present. Other formats load only if no `.clinerules` exists (except `AGENTS.md`, which always searches subdirectories). All rules appear in the Rules popover where you can toggle them.
+
+## Creating Rules
+
+Click the `+` button in the Rules tab to create a new rule. This opens a file in your editor where you write your guidance.
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/cline-rules.png" alt="Create a Rule" />
+</Frame>
+
+When you save the file, it's stored in:
+- **Workspace rules**: `.clinerules/` in your project root
+- **Global rules**: Platform-specific location (see table below)
+
+You can also use the [`/newrule` slash command](/features/slash-commands/new-rule) to have Cline generate a rule based on your description.
+
+### Global Rules Location
+
+| Operating System | Default Location |
+|------------------|------------------|
+| **Windows** | `Documents\Cline\Rules` |
+| **macOS** | `~/Documents/Cline/Rules` |
+| **Linux/WSL** | `~/Documents/Cline/Rules` or `~/Cline/Rules` |
+
+<Note>
+Linux/WSL users: Check both locations if you don't find global rules in `~/Documents/Cline/Rules`.
+</Note>
+
+## Managing Rules
+
+The Rules popover (below the chat input) shows active rules and lets you toggle them on or off.
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(1).png" alt="Rules Popover" />
+</Frame>
+
+The popover displays:
+- **Global rules**: From your user-level Rules directory
+- **Workspace rules**: From `.clinerules/` in your project
+
+Toggle any rule to enable or disable it. Disabled rules won't load, even if they match conditions.
+
+## When to Use Rules
+
+Rules work best for persistent project context:
+
+- **Code standards**: Formatting preferences, naming conventions, project-specific patterns
+- **Documentation requirements**: Where to add docs, what format to follow
+- **Architecture decisions**: Design patterns, dependency rules, module boundaries
+- **Team conventions**: PR processes, branch naming, commit message format
+- **Technology constraints**: Required libraries, banned APIs, version requirements
+
+Rules are less effective for:
+- One-time instructions (just say it in the chat)
+- Complex multi-step workflows (use [Workflows](/features/slash-commands/workflows/index) instead)
+- Dynamic decisions that depend on runtime context
+
+## Example Rule
+
+```markdown
+# Backend API Guidelines
+
+## Route Handlers
+
+- Use async/await, not callbacks
+- Validate request bodies with Zod schemas
+- Return typed errors from `src/errors.ts`
+- All routes require authentication unless in `publicRoutes` array
+
+## Database Access
+
+- All queries go through repository classes in `src/repositories/`
+- Use transactions for multi-table updates
+- Never expose raw database errors to clients
+
+## Testing
+
+- Unit tests for business logic in `src/services/`
+- Integration tests for route handlers in `src/routes/`
+- Mock external APIs, not internal modules
+```
+
+This rule provides clear, actionable guidance without explaining obvious concepts or using vague language.
+
+## Using a Folder Structure
+
+For projects with many rules, organize them in a `.clinerules/` folder:
+
+```
+your-project/
+├── .clinerules/
+│   ├── 01-coding-standards.md
+│   ├── 02-documentation.md
+│   └── 03-testing.md
+├── src/
+└── ...
+```
+
+Cline loads all Markdown files in `.clinerules/` automatically. The numeric prefixes help you control ordering, but they're optional.
+
+### Organizing a Rules Bank
+
+Maintain a separate folder for rules you might need but don't always want active:
+
+```
+your-project/
+├── .clinerules/              # Active rules
+│   ├── 01-coding.md
+│   └── client-a.md
+│
+├── clinerules-bank/          # Available but inactive
+│   ├── clients/
+│   │   ├── client-a.md
+│   │   └── client-b.md
+│   └── frameworks/
+│       ├── react.md
+│       └── vue.md
+└── ...
+```
+
+Copy files from the bank to `.clinerules/` when you need them. This keeps your active context lean while maintaining a library of reusable guidance.
+
+Switch contexts with simple file operations:
+
+```bash
+# Switch to Client B
+rm .clinerules/client-a.md
+cp clinerules-bank/clients/client-b.md .clinerules/
+```
+
+<Tip>
+Consider git-ignoring `.clinerules/` while tracking `clinerules-bank/` so team members can activate the rules relevant to their current work.
+</Tip>
+
+## Conditional Rules
+
+Scope rules to specific file patterns using YAML frontmatter. This keeps React guidance out of Python code and backend rules away from frontend work.
+
+```yaml
+---
+paths:
+  - "src/components/**"
+  - "src/hooks/**"
+---
+
+# React Guidelines
+
+Use functional components with hooks. Extract reusable logic into custom hooks.
+```
+
+This rule activates only when working with files matching those patterns. Read the [Conditional Rules guide](/features/cline-rules/conditional-rules) for pattern syntax, behavior details, and more examples.
+
+## Tips for Effective Rules
+
+**Be specific**: "Use async/await for all database calls" beats "write good async code."
+
+**Show patterns**: Include file paths and real examples. "Follow the error handling in `src/utils/errors.ts`" gives Cline a concrete reference.
+
+**Focus on outcomes**: Describe what you want, not step-by-step instructions. Let Cline figure out how.
+
+**Test and refine**: Start with core standards. Add rules when you find yourself repeating the same feedback.
+
+**Use conditional rules**: Load guidance only when relevant. This keeps context efficient and reduces noise.
+
+## Related
+
+- [Conditional Rules](/features/cline-rules/conditional-rules) - Activate rules based on file patterns
+- [Skills](/features/skills) - Load instructions on demand with `/skill` command
+- [Workflows](/features/slash-commands/workflows/index) - Define explicit task automation
+- [New Rule Slash Command](/features/slash-commands/new-rule) - Generate rules with AI assistance
+- [Plan and Act Mode](/features/plan-and-act) - Use different rules for planning vs execution
@@ -0,0 +1,129 @@
+---
+title: "Code Commands"
+sidebarTitle: "Code Commands"
+---
+
+Cline's code commands bring AI assistance directly into your editor, letting you interact with your code without leaving your workflow. With a simple right-click, you can add code to Cline, and through the lightbulb menu, you can fix errors, get explanations, or improve your code.
+
+## Available Code Commands
+
+When you interact with code in your editor, you can access Cline commands in two ways:
+
+### Right-Click Context Menu
+
+When you right-click on selected code, you'll see:
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/code-commands.png" alt="Right Click Menu" />
+</Frame>
+
+#### Add to Cline
+
+The "Add to Cline" command sends your selected code to the Cline chat panel. This is perfect for:
+
+-   Asking questions about specific code snippets
+-   Requesting improvements or optimizations
+-   Getting explanations of complex logic
+
+When you use this command, Cline automatically includes:
+
+-   The file path (as a file mention)
+-   The selected code with proper formatting
+-   The programming language for accurate syntax highlighting
+
+### Lightbulb Menu (Code Actions)
+
+When you see a lightbulb icon in your editor, click it to access these Cline commands:
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/lightbulb-actions.png" alt="Lightbulb Menu" />
+</Frame>
+
+#### Fix with Cline
+
+The "Fix with Cline" command appears in the lightbulb menu when your code has errors or warnings. This command:
+
+1. Captures the selected code
+2. Identifies the errors or warnings from VSCode's diagnostics
+3. Sends both to Cline with a request to fix the issues
+4. Provides a solution that addresses the specific problems
+
+This is incredibly useful for quickly resolving syntax errors, linter warnings, or type issues without having to manually describe the problem.
+
+#### Explain with Cline
+
+The "Explain with Cline" command helps you understand complex code. When you select code and use this command from the lightbulb menu, Cline:
+
+1. Analyzes the selected code
+2. Provides a clear explanation of what the code does
+3. Breaks down complex logic into understandable parts
+4. Highlights important patterns or techniques used
+
+#### Improve with Cline
+
+The "Improve with Cline" command helps you enhance your code. When you select code and use this command from the lightbulb menu, Cline:
+
+1. Analyzes the selected code for potential improvements
+2. Suggests optimizations, refactorings, or better practices
+3. Explains the reasoning behind the suggested changes
+4. Provides improved code that maintains the original functionality
+
+## How to Use Code Commands
+
+Using Cline's code commands is simple:
+
+### For Right-Click Commands:
+
+1. Select the code you want to work with
+2. Right-click to open the context menu
+3. Choose "Add to Cline"
+4. View the result in the Cline chat panel
+
+### For Lightbulb Menu Commands:
+
+1. Select the code you want to work with
+2. Look for the lightbulb icon that appears in the editor gutter
+3. Click the lightbulb to see available actions
+4. Choose the appropriate Cline command (Fix, Explain, or Improve)
+5. View the result in the Cline chat panel
+
+After using any command, you can:
+
+-   Ask follow-up questions
+-   Request modifications to the solution
+-   Apply the changes back to your code
+
+## How It Works Under the Hood
+
+When you use a code command, here's what happens behind the scenes:
+
+1. **Code Selection**: The extension captures your selected code and its context
+2. **Metadata Collection**: Cline gathers important metadata:
+
+    - File path and name
+    - Programming language
+    - Any associated diagnostics (errors/warnings)
+    - Surrounding code context when relevant
+
+3. **Command Processing**:
+
+    - For "Add to Cline," the code is formatted and sent to the chat panel
+    - For "Fix with Cline," the code and diagnostics are analyzed and a fix is generated
+    - For "Explain with Cline," the code is analyzed to provide a clear explanation
+    - For "Improve with Cline," the code is analyzed for potential optimizations and improvements
+
+4. **Integration with Chat**: The results appear in the Cline chat panel, where you can:
+    - See the AI's response
+    - Ask follow-up questions
+    - Apply suggested changes
+
+This seamless integration between your editor and Cline's AI capabilities makes it easy to get assistance without disrupting your coding flow.
+
+## Tips for Effective Use
+
+-   **Select complete logical units**: When possible, select entire functions, classes, or modules to give Cline complete context
+-   **Include imports**: For language-specific help, include relevant imports so Cline understands dependencies
+-   **Combine with @ mentions**: For complex issues, use code commands along with file or problem mentions for more context
+-   **Use keyboard shortcuts**: Speed up your workflow by [assigning keyboard shortcuts](/features/commands-and-shortcuts/keyboard-shortcuts) to common code commands
+
+Next time you're struggling with a piece of code, try using Cline's code commands instead of switching to a separate chat interface. You'll be amazed at how much more efficient your workflow becomes when AI assistance is integrated directly into your editor.
@@ -0,0 +1,71 @@
+---
+title: "Generate Commit Message"
+sidebarTitle: "Generate Commit Message"
+---
+
+Cline's Git integration brings AI assistance directly to your version control workflow. Generate commit messages without leaving your editor.
+
+## Generate Commit Message
+
+One of the most useful Git integrations is the ability to automatically generate meaningful commit messages:
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/generate-commit-message-with-cline.png"
+		alt="Generate Commit Message with Cline"
+	/>
+</Frame>
+
+1. Make your changes and stage them in Git
+2. Click the robot icon in the Source Control view or run the "Generate Commit Message with Cline" command
+3. Cline analyzes your changes and generates a descriptive commit message
+4. The message is automatically inserted into the commit message input box
+
+The generated commit messages:
+
+-   Start with a concise summary (50-72 characters)
+-   Use imperative mood (e.g., "Add feature" not "Added feature")
+-   Describe what was changed and why
+-   Follow Git best practices
+
+This feature saves time and ensures your commit history is consistent and informative.
+
+<Tip>
+	For information about using `@git-changes` and `@[commit-hash]` mentions in your chat messages, see the [Git
+	Mentions](/features/at-mentions/git-mentions) documentation.
+</Tip>
+
+## How It Works
+
+When you use Cline's commit message generation feature, here's what happens behind the scenes:
+
+1. Cline retrieves the current Git diff using `getWorkingState()`
+2. It formats this diff into a specialized prompt for the AI
+3. The AI analyzes the changes and generates an appropriate commit message
+4. The message is extracted and inserted into the Git commit message input box
+
+This process uses your current Cline API configuration, so the quality of the generated messages matches your chosen AI model.
+
+## Tips for Effective Use
+
+-   **Generate commit messages for complex changes**: The AI excels at summarizing multiple related changes into a coherent message.
+
+-   **Review and edit generated messages**: While the AI generates high-quality messages, it's always good practice to review and adjust them if needed.
+
+-   **Stage related changes together**: For the best results, stage related changes together so the AI can generate a cohesive message.
+
+-   **Use for consistent commit history**: Using the generate commit message feature helps maintain a consistent style across your commit history.
+
+## How It Works Under the Hood
+
+The commit message generation leverages VSCode's Git extension API to access repository information:
+
+1. When you trigger the command:
+    - Cline gets the current diff
+    - It sends this to the AI with specific instructions for commit message formatting
+    - It parses the AI's response
+    - It accesses the Git extension API to set the commit message
+
+This integration with Git makes it easy to generate high-quality commit messages without disrupting your workflow.
+
+Next time you're struggling to write a good commit message, try using Cline's commit message generation. You'll save time and improve your version control workflow with AI assistance right where you need it.
@@ -0,0 +1,204 @@
+---
+title: "Keyboard Shortcuts"
+sidebarTitle: "Keyboard Shortcuts"
+---
+
+Speed up your workflow by accessing Cline's AI assistance without taking your hands off the keyboard.
+
+<Tip>
+**The One Shortcut You Need:** `Ctrl+'` (Windows/Linux) or `Cmd+'` (macOS)
+
+This context-aware shortcut handles your most common needs:
+- **With text selected:** Adds code to Cline chat
+- **Without selection:** Focuses the chat input
+
+Master this one shortcut, and you're 90% there.
+</Tip>
+
+## Default Shortcuts
+
+Cline has minimal default shortcuts by design, so they won't conflict with your existing VSCode setup:
+
+| Shortcut | Windows/Linux | macOS | What It Does |
+| -------- | ------------- | ----- | ------------ |
+| **Add to Chat / Focus Input** | `Ctrl+'` | `Cmd+'` | Context-aware: adds selected code or focuses chat |
+
+That's it! Everything else is available for you to customize.
+
+## Quick Workflow Examples
+
+Here's how keyboard shortcuts fit into real coding workflows:
+
+### Debug & Fix Workflow
+
+1. **Find error in code** → VSCode highlights it
+2. **Select the problematic code** → `Shift+Arrow` or `Ctrl+L` / `Cmd+L`
+3. **Send to Cline** → `Ctrl+'` / `Cmd+'`
+4. **Ask for help** → Type your question, hit `Enter`
+
+### Code Review Workflow
+
+1. **Review a function** → Select it with `Ctrl+L` / `Cmd+L`
+2. **Get AI review** → `Ctrl+'` / `Cmd+'` then ask "Review this"
+3. **Iterate** → Apply suggestions and repeat
+
+### Terminal Integration Workflow
+
+1. **Open terminal** → Press `` Ctrl+` `` / `` Cmd+` ``
+2. **Run your command** → Execute in terminal
+3. **Capture output** → Press `Alt+T` (after assigning shortcut)
+4. **Get help** → Ask Cline to interpret errors or output
+
+<Info>
+**Pro Tip:** Assign `Alt+T` to the `cline.addTerminalOutputToChat` command for quick terminal output capture. Without a shortcut, you can still right-click in the terminal and select "Add to Cline" - but the keyboard approach is much faster for frequent debugging workflows.
+</Info>
+
+## Customizing Shortcuts
+
+Want to assign shortcuts to more Cline commands? Here's how:
+
+**Step 1:** Open VSCode's Keyboard Shortcuts editor
+- Press `Ctrl+K Ctrl+S` (Windows/Linux) or `Cmd+K Cmd+S` (macOS)
+- Or: **File → Preferences → Keyboard Shortcuts**
+
+**Step 2:** Search for "Cline"
+
+**Step 3:** Click the ✏️ icon next to any command
+
+**Step 4:** Press your desired key combo, then `Enter`
+
+<Warning>
+**Avoid Conflicts:** Check that your shortcut doesn't override important VSCode commands. The shortcuts editor will warn you about conflicts.
+</Warning>
+
+## Available Commands Reference
+
+<Accordion title="Task Management Commands">
+
+These commands help you navigate and manage Cline tasks:
+
+| Command ID | Description | Suggested Shortcut |
+| ---------- | ----------- | ------------------ |
+| `cline.plusButtonClicked` | Start a new task | `Ctrl+Shift+N` / `Cmd+Shift+N` |
+| `cline.historyButtonClicked` | Open task history | `Ctrl+Shift+H` / `Cmd+Shift+H` |
+| `claude-dev.SidebarProvider.focus` | Open Cline sidebar | `Ctrl+Shift+L` / `Cmd+Shift+L` |
+
+**Note:** `claude-dev` prefix is for historical reasons - it works with Cline.
+
+</Accordion>
+
+<Accordion title="Code Interaction Commands">
+
+Work directly with your code:
+
+| Command ID | Description | Suggested Shortcut |
+| ---------- | ----------- | ------------------ |
+| `cline.addToChat` | Add selected code to chat | `Ctrl+'` / `Cmd+'` ⭐ (default) |
+| `cline.focusChatInput` | Focus chat input | `Ctrl+'` / `Cmd+'` ⭐ (default) |
+| `cline.explainCode` | Explain selected code | `Ctrl+Shift+E` / `Cmd+Shift+E` |
+| `cline.improveCode` | Suggest code improvements | `Ctrl+Shift+I` / `Cmd+Shift+I` |
+
+⭐ These share the same shortcut - it's context-aware!
+
+</Accordion>
+
+<Accordion title="Terminal Integration Commands">
+
+Connect Cline with your terminal:
+
+| Command ID | Description | Suggested Shortcut |
+| ---------- | ----------- | ------------------ |
+| `cline.addTerminalOutputToChat` | Add terminal output to Cline | `Alt+T` |
+
+**Tip:** Use this after running commands to get help interpreting output or fixing errors.
+
+</Accordion>
+
+<Accordion title="Git Integration Commands">
+
+Generate commit messages with AI:
+
+| Command ID | Description | Suggested Shortcut |
+| ---------- | ----------- | ------------------ |
+| `cline.generateGitCommitMessage` | Generate commit message | `Ctrl+Shift+G` / `Cmd+Shift+G` |
+| `cline.abortGitCommitMessage` | Stop generation | `Ctrl+Shift+Esc` / `Cmd+Shift+Esc` |
+
+</Accordion>
+
+<Accordion title="Settings & Configuration Commands (Advanced)">
+
+These commands open Cline's configuration panels. Most users access these via the sidebar buttons, but keyboard shortcuts can be useful for:
+
+- **Frequent MCP server developers** who constantly adjust server configurations
+- **Demo/presentation scenarios** where you need quick, keyboard-only navigation
+- **Accessibility workflows** where mouse usage is minimized
+
+| Command ID | Description | Suggested Shortcut |
+| ---------- | ----------- | ------------------ |
+| `cline.settingsButtonClicked` | Open Cline settings | `Ctrl+Alt+,` / `Cmd+Opt+,` |
+| `cline.mcpButtonClicked` | Open MCP servers config | `Ctrl+Alt+M` / `Cmd+Opt+M` |
+| `cline.accountButtonClicked` | Open account settings | `Ctrl+Alt+A` / `Cmd+Opt+A` |
+| `cline.openWalkthrough` | Open walkthrough guide | (not recommended) |
+
+**Our take:** Unless you're constantly tweaking settings or building MCP servers, the sidebar buttons are more convenient. But if you find yourself opening these panels frequently, shortcuts can save time.
+
+</Accordion>
+
+## What About "Fix with Cline"?
+
+<Warning>
+**You CAN'T assign a keyboard shortcut to "Fix with Cline"**
+
+This command only appears in the **lightbulb menu** (💡) when VSCode detects errors in your code. It needs the error context to work, so it's not available as a standalone command.
+
+**Workarounds:**
+- Click the 💡 lightbulb icon that appears next to errors
+- Or select code with errors and use `Ctrl+'` / `Cmd+'` to ask Cline to fix them
+- Or right-click and select "Add to Cline"
+</Warning>
+
+Learn more about code actions in our [Code Commands documentation](/features/commands-and-shortcuts/code-commands).
+
+## Best Practices
+
+<Tip>
+**Start Simple**
+
+Don't try to memorize 20 shortcuts on day one. Start with:
+1. `Ctrl+'` / `Cmd+'` (the essential one)
+2. Add 1-2 more based on your actual usage patterns
+3. Build muscle memory over time
+</Tip>
+
+**Choose Shortcuts Wisely:**
+- **Be ergonomic:** Use comfortable key combinations
+- **Create patterns:** Group related commands (e.g., all Cline shortcuts use `Ctrl+Shift+...`)
+- **Avoid conflicts:** Don't override VSCode essentials like `Ctrl+C` or `Ctrl+S`
+- **Use modifiers:** Combine `Ctrl`/`Cmd` + `Shift` + `Alt` to reduce conflicts
+
+**Build the Habit:**
+- Use shortcuts consistently for a week to build muscle memory
+- Keep a note of your custom shortcuts until they're automatic
+- Review monthly to see if your workflow has changed
+
+## Discovering Commands
+
+Not sure what commands are available? Use VSCode's Command Palette:
+
+1. Press `Ctrl+Shift+P` / `Cmd+Shift+P`
+2. Type "Cline" to filter
+3. Browse all available commands
+4. Assign shortcuts to your favorites
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/editor-integration.png"
+		alt="Editor Integration Overview"
+	/>
+</Frame>
+
+---
+
+<Info>
+**Remember:** The goal isn't to memorize every possible shortcut. Master `Ctrl+'` / `Cmd+'` first, then gradually add shortcuts for commands you use frequently. Quality over quantity!
+</Info>
@@ -0,0 +1,65 @@
+---
+title: "Commands & Shortcuts Overview"
+sidebarTitle: "Overview"
+---
+
+Cline integrates directly into VSCode's interface, letting you access AI assistance without disrupting your workflow. These integrations appear as commands in context menus, keyboard shortcuts, and quick fixes throughout the editor.
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/editor-integration.png"
+		alt="Editor Integration Overview"
+	/>
+</Frame>
+
+### What are Editor Integrations?
+
+Editor integrations are commands and shortcuts that let you use Cline right where you're working. Instead of switching to the Cline panel first, you can select code, right-click, and immediately send it to Cline for help.
+These integrations appear in different places throughout VSCode:
+
+-   In the editor context menu (right-click menu) - "Add to Cline"
+-   In the terminal context menu - "Add to Cline"
+-   In the Source Control view - "Generate Commit Message"
+-   As keyboard shortcuts - Various Cline commands
+-   As Quick Fix options (lightbulb menu) - "Fix with Cline", "Explain with Cline", "Improve with Cline"
+
+### Available Editor Integrations
+
+Cline offers several editor integrations, each designed to enhance different aspects of your development workflow:
+
+<Columns cols={2}>
+  <Card title="Code Commands" icon="code" href="/features/commands-and-shortcuts/code-commands">
+    Right-click on code to add it to Cline, or use the lightbulb menu to fix errors, explain code, or improve it. Cline sees the complete code context, including imports and surrounding functions.
+  </Card>
+
+{" "}
+
+<Card title="Terminal Integration" icon="terminal" href="/features/commands-and-shortcuts/terminal-integration">
+	Add terminal output to Cline with a right-click or use `@terminal` mentions. Perfect for debugging build errors, test
+	failures, or runtime issues.
+</Card>
+
+{" "}
+
+<Card title="Git Integration" icon="code-branch" href="/features/commands-and-shortcuts/git-integration">
+	Generate commit messages, explain diffs, or analyze changes with Cline's Git integration. Cline understands your version
+	control context.
+</Card>
+
+{" "}
+
+<Card title="Keyboard Shortcuts" icon="keyboard" href="/features/commands-and-shortcuts/keyboard-shortcuts">
+	Speed up your workflow with keyboard shortcuts for common Cline actions. Quickly add code to chat, fix errors, or improve your code.
+</Card>
+</Columns>
+
+### How They Work
+
+When you use these commands, Cline:
+
+-   Captures the relevant context (selected code, file path, terminal output, etc.)
+-   Focuses the Cline interface
+-   Creates a conversation with the captured context
+-   In some cases, automatically generates a suggested prompt
+
+Behind the scenes, these commands use VSCode's extension API to register commands, access editor state, and control VSCode's interface.
@@ -0,0 +1,98 @@
+---
+title: "Terminal Integration"
+sidebarTitle: "Terminal Integration"
+---
+
+Cline's terminal integration lets you bring your terminal output directly into your conversations with Cline. Instead of copying and pasting error messages or command results, you can send them to Cline with a simple right-click in the terminal.
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/terminal-integration.png"
+		alt="Terminal Integration"
+	/>
+</Frame>
+
+## Right-Click Terminal Integration
+
+When you're working in the VSCode terminal and see output you want to discuss with Cline:
+
+1. Right-click in the terminal
+2. Select "Add to Cline" from the context menu
+3. The terminal output is immediately sent to the Cline chat panel
+
+This is perfect for:
+
+-   Debugging build errors
+-   Understanding test failures
+-   Analyzing command output
+-   Getting help with error messages
+
+The right-click terminal integration is especially useful when you're already working in the terminal and encounter an issue.
+
+Instead of switching context to the Cline chat panel and typing a description of the problem, you can send the terminal output directly to Cline with just a couple of clicks.
+
+Alternatively, you can use the [`@terminal`](/features/at-mentions/terminal-mentions) mention to send the full terminal output to Cline.
+
+<Tip>
+	For information about using `@terminal` mentions in your chat messages, see the [Terminal
+	Mentions](/features/at-mentions/terminal-mentions) documentation.
+</Tip>
+
+## How Terminal Integration Works
+
+When you use the right-click terminal integration, Cline:
+
+1. Captures the terminal output with all formatting preserved
+2. Includes the complete context, including command history and results
+3. Formats it appropriately for the AI to understand
+4. Enables the AI to see exactly what you're seeing
+
+This gives Cline the full context it needs to provide accurate help with terminal-related issues.
+
+## Behind the Scenes
+
+The terminal integration uses a clever technique to capture terminal output:
+
+1. When you trigger the integration, Cline:
+
+    - Temporarily saves your current clipboard content
+    - Selects all terminal content (or uses your existing selection)
+    - Copies it to the clipboard
+    - Reads the clipboard to get the terminal content
+    - Restores your original clipboard content
+
+2. The terminal content is then:
+    - Formatted with proper syntax highlighting
+    - Added to your message or sent as a new message
+    - Enhanced with additional context when needed
+
+This approach ensures that all terminal output, including colors and formatting, is accurately captured without affecting your clipboard.
+
+## Tips for Effective Use
+
+-   **Use terminal integration for error messages**: When you encounter an error in the terminal, sending it to Cline often results in faster resolution than trying to describe the error.
+
+-   **Select specific output when needed**: By default, the integration captures all terminal content, but you can also select specific lines before right-clicking to focus on just the relevant output.
+
+-   **Combine terminal outputs with file mentions**: After sending terminal output to Cline, you can enhance your question by mentioning relevant files using the @ mentions feature.
+
+-   **Contextualize build & test outputs with the terminal**: Terminal integration is particularly useful for understanding complex build errors or test failures that span multiple lines.
+
+Next time you're staring at a cryptic error message in your terminal, try using Cline's terminal integration instead of copying and pasting. You'll get more accurate help because Cline can see the complete terminal context with proper formatting.
+
+## Troubleshooting Terminal Issues
+
+If you're experiencing issues with terminal integration, such as "Shell Integration Unavailable" or commands not showing output, please refer to our comprehensive [Terminal Integration Troubleshooting Guide](/troubleshooting/terminal-integration-guide).
+
+The troubleshooting guide covers:
+
+-   Common terminal integration issues and quick fixes
+-   Platform-specific solutions for Windows, macOS, and Linux
+-   Shell-specific configurations for zsh, bash, PowerShell, and more
+-   Advanced debugging techniques
+-   Terminal settings optimization
+
+<Tip>
+	**Quick Fix**: Most terminal issues can be resolved by switching to bash in the Cline settings and increasing the shell
+	integration timeout to 10 seconds.
+</Tip>
@@ -0,0 +1,79 @@
+---
+title: "Disable Terminal Pagers During Cline Sessions"
+description: "Make CLI output non-interactive when Cline runs commands by detecting the CLINE_ACTIVE environment variable and disabling pagers like less."
+---
+
+Many CLI tools (like Git) use a pager such as `less` for interactive, scrollable output. When Cline runs commands in your terminal, that interactivity gets in the way — the pager can pause on the first page and block progress. You can configure your shell so that when a terminal is spawned by Cline, pagers are disabled and output streams through normally.
+
+## How it works
+
+Cline sets an environment variable for terminals it opens to run commands:
+
+- `CLINE_ACTIVE` — non-empty when the shell is running under Cline
+
+You can detect this variable in your shell startup file and adjust environment variables or aliases only for Cline-run sessions. This keeps your normal interactive terminals unchanged.
+
+## Quick setup (Zsh/Bash)
+
+Add the following to your `~/.zshrc`, `~/.bashrc`, or `~/.bash_profile`:
+
+```bash
+# Disable pagers when the terminal is launched by Cline
+if [[ -n "$CLINE_ACTIVE" ]]; then
+  export PAGER=cat
+  export GIT_PAGER=cat
+  export SYSTEMD_PAGER=cat
+  export LESS="-FRX"
+fi
+```
+
+<Note>
+- `PAGER=cat` ensures generic pager-aware tools print directly to stdout
+- `GIT_PAGER=cat` prevents Git from invoking `less`
+- `SYSTEMD_PAGER=cat` disables paging in systemd tools (if present)
+- `LESS="-FRX"` makes `less` behave more like streaming output if a tool still calls it
+</Note>
+
+This configuration only applies when `CLINE_ACTIVE` is set, so your normal terminals keep their usual interactive behavior.
+
+## Verify
+
+- Open a task in Cline that runs terminal commands and check:
+  - `echo "$CLINE_ACTIVE"` prints a non-empty value
+  - `git log` or other long outputs should stream without pausing
+- If changes don't take effect:
+  - Make sure you updated the correct startup file for your shell
+  - Restart VS Code/Cursor so integrated terminals reload your shell config
+  - Confirm your terminal profile sources your `~/.zshrc` or `~/.bashrc`
+
+## Optional tweaks
+
+- Prefer command-line options when you don't want to rely on env vars:
+
+```bash
+# One-off usage (no aliases)
+git --no-pager log -n 50 --decorate --oneline
+systemctl --no-pager status nginx
+journalctl --no-pager -u nginx -n 200
+less -FRX README.md
+```
+
+- You can also override paging via shell aliases scoped to Cline sessions using options rather than env vars:
+
+```bash
+if [[ -n "$CLINE_ACTIVE" ]]; then
+  # Make 'less' non-interactive by default
+  alias less='less -FRX'
+  # Disable paging for common tools via CLI flags
+  alias git='command git --no-pager'
+  alias systemctl='command systemctl --no-pager'
+  alias journalctl='command journalctl --no-pager'
+fi
+```
+
+- If you prefer environment variables, many CLIs also respect a generic or tool-specific pager variable:
+  - Git: `GIT_PAGER=cat`
+  - Systemd: `SYSTEMD_PAGER=cat`
+  - Man pages: `MANPAGER=cat` (not typically needed for Cline-driven commands)
+
+- Aliases affect the current interactive shell, while environment variables propagate to child processes. Choose the approach that best fits your workflow.
@@ -0,0 +1,60 @@
+---
+title: "Opening Cline in the Right Sidebar"
+description: "Learn how to open Cline in the right sidebar in VS Code and Cursor"
+---
+
+By default, when you first install Cline, it appears in VS Code's left sidebar alongside your file explorer and other extensions. However, for a better coding experience, we recommend moving Cline to the right sidebar. This allows you to keep your project files visible in the left sidebar while chatting with Cline on the right, giving you full visibility of your codebase as Cline works on your project.
+
+## VS Code
+
+To open Cline in the right sidebar:
+
+<Steps>
+  <Step title="Align Extension View">
+    Make sure your extension view is aligned vertically to the left
+  </Step>
+  <Step title="Open Right Side View">
+    Click the button that opens the right side panel in VS Code (typically used to open GitHub Copilot chat). Optionally use the `Option + CMD/Ctrl + B` shortcut.
+  </Step>
+  <Step title="Drag Cline Icon">
+    Drag the Cline icon over to the nav panel at the top of that right view
+  </Step>
+</Steps>
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/vscode_right_view.gif"
+		alt="VS Code Right Sidebar Setup"
+	/>
+</Frame>
+
+## Cursor
+
+To open Cline in the right sidebar:
+
+<Steps>
+  <Step title="Align Extensions">
+    Cursor uses a horizontal activity bar by default to optimize space for the AI chat interface ([see here for details](https://cursor.com/docs/configuration/migrations/vscode#activity-bar-orientation)). To switch to vertical:
+    
+    1. Open the Command Palette (`CMD/Ctrl + Shift + P`)
+    2. Search for "Preferences: Open Settings (UI)"
+    3. Search for `workbench.activityBar.orientation`
+    4. Set the value to `vertical`
+    5. Restart Cursor for the changes to take effect
+  </Step>
+  <Step title="Open the AI Pane">
+    Click the Cursor cube icon button (AI Pane) that opens Cursor's agent (right side view panel)
+  </Step>
+  <Step title="Drag Cline to the AI Pane Sidebar">
+    Drag the Cline icon directly into the AI Pane sidebar.
+  </Step>
+</Steps>
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/Cursor-sidebar.gif"
+		alt="Cursor Right Sidebar Setup"
+	/>
+</Frame>
+
+Once set up, Cline will load on the right side and you can use it as normal.
@@ -1,129 +0,0 @@
---
-title: "Deep Planning"
-sidebarTitle: "Deep Planning"
-description: "Transform Cline into a meticulous architect who investigates your codebase and creates comprehensive implementation plans."
---
-
-Deep Planning (`/deep-planning`) turns Cline into an architect before it becomes a builder. Instead of jumping straight into code, Cline systematically explores your codebase, asks targeted questions, and produces a detailed implementation plan — all before writing a single line.
-
-<Tip>
-**When should you use this?** Use `/deep-planning` for features that touch multiple files, architectural changes, complex integrations, or any task where "just start coding" would lead to rework.
-</Tip>
-
-## How It Works
-
-Deep Planning follows a four-step process:
-
-<Steps>
-  <Step title="Silent Investigation">
-    Cline explores your codebase without asking you anything. It reads relevant files, traces dependencies, examines patterns, and builds a mental model of how your project is structured. You'll see Cline reading files and running searches during this phase.
-
-    This step is intentionally silent — Cline gathers context first so it can ask better questions next.
-  </Step>
-
-  <Step title="Discussion">
-    Based on what it learned, Cline asks you targeted, specific questions about your requirements and preferences. These aren't generic questions — they're informed by what Cline found in your code.
-
-    For example, instead of asking "how should authentication work?", Cline might ask "I see you're using JWT tokens in `auth/middleware.ts` with refresh token rotation. Should the new endpoint follow the same pattern, or do you want session-based auth for this feature?"
-
-    Answer these questions to shape the plan. The more specific you are, the better the implementation plan will be.
-  </Step>
-
-  <Step title="Plan Creation">
-    Cline generates a comprehensive `implementation_plan.md` file in your project. This plan typically includes:
-
-    - **Overview** of the feature and its scope
-    - **File-by-file changes** with specific descriptions of what to add, modify, or remove
-    - **Dependencies** between changes (what needs to happen first)
-    - **Edge cases** and error handling considerations
-    - **Testing strategy** for the implementation
-
-    The plan is saved as a markdown file you can review, edit, and share with your team before any code is written.
-  </Step>
-
-  <Step title="Task Creation">
-    After you approve the plan, Cline creates a new task with the implementation steps loaded as trackable items. This gives you a clean context window focused entirely on execution, with the plan serving as the roadmap.
-  </Step>
-</Steps>
-
-## Using Deep Planning
-
-### Invoking It
-
-Type `/deep-planning` in the Cline chat input, followed by a description of what you want to build:
-
-```
-/deep-planning Add a notification system that sends email and in-app 
-notifications when users receive comments on their posts
-```
-
-The more context you provide upfront, the more focused the investigation phase will be. Include:
-
- What you want to build
- Any constraints or preferences
- Which parts of the codebase are relevant (if you know)
-
-### Reviewing the Plan
-
-Once Cline generates `implementation_plan.md`, review it carefully:
-
-1. **Check the scope** — Does it cover everything you need? Is anything missing?
-2. **Verify the approach** — Does the technical approach match your preferences?
-3. **Review the order** — Are dependencies handled correctly?
-4. **Edit if needed** — It's a markdown file. Change anything that doesn't look right.
-
-Tell Cline about any adjustments before proceeding to implementation.
-
-## Model-Specific Optimization
-
-The deep planning prompt is optimized for each model family. Cline adapts its investigation and planning approach based on the strengths of whatever model you're using — whether that's Claude, GPT, Gemini, DeepSeek, or others.
-
-This means you get effective deep planning regardless of your model choice, though stronger reasoning models will generally produce more thorough plans.
-
-<Tip>
-Consider using a stronger reasoning model for the planning phase and a faster model for implementation. You can configure separate models for Plan and Act modes in Cline Settings. See [Plan & Act Mode](/core-workflows/plan-and-act#using-different-models-for-each-mode) for details.
-</Tip>
-
-## Pairing with Other Features
-
-Deep Planning works well with several other Cline features:
-
-| Feature | How It Helps |
-|---------|-------------|
-| [Focus Chain](/features/focus-chain) | Tracks implementation progress against the plan with a visible todo list |
-| [Memory Bank](/features/memory-bank) | Preserves project context across sessions so deep planning has richer input |
-| [Plan & Act Mode](/core-workflows/plan-and-act) | Use Plan mode for quick exploration, deep planning for thorough architecture |
-| [Checkpoints](/core-workflows/checkpoints) | Roll back implementation steps if something goes wrong during execution |
-
-<Tip>
-A powerful workflow: run `/deep-planning` to create the plan, enable [Focus Chain](/features/focus-chain) to track progress, then let Cline implement step by step. You get architecture-level thinking with granular progress visibility.
-</Tip>
-
-## Deep Planning vs Plan Mode
-
-Both involve thinking before doing, but they serve different purposes:
-
-| | Plan Mode | Deep Planning |
-|---|-----------|---------------|
-| **Scope** | Quick exploration and discussion | Thorough codebase investigation |
-| **Output** | Conversation context | `implementation_plan.md` file |
-| **Best for** | Medium tasks, understanding code | Large tasks, multi-file features |
-| **Duration** | Minutes | Longer — depends on codebase size |
-| **Persistence** | Lives in conversation history | Saved as a file you can reference later |
-
-For most development work, starting in Plan mode is sufficient. Reserve `/deep-planning` for tasks where you'd normally spend significant time planning on a whiteboard before coding.
-
-## Tips
-
- **Be specific in your initial prompt.** "Add authentication" gives a vague plan. "Add OAuth2 authentication with Google and GitHub providers, using our existing user model in `models/user.ts`" gives a focused one.
- **Point Cline at relevant files.** Use `@` mentions to highlight key files in your prompt so the investigation phase starts in the right place.
- **Edit the plan before implementing.** The generated plan is a starting point. Adjust priorities, remove unnecessary steps, or add details before Cline starts coding.
- **Save plans for reference.** The `implementation_plan.md` file is useful documentation even after the feature is built. Consider committing it or moving it to a docs folder.
- **Use for onboarding.** Run `/deep-planning` on a feature you're unfamiliar with to get Cline to map out the codebase and explain how things connect.
-
-## Related
-
- [Plan & Act Mode](/core-workflows/plan-and-act) — Cline's dual-mode system for structured development
- [Focus Chain](/features/focus-chain) — Automatic todo list tracking for long-running tasks
- [Memory Bank](/features/memory-bank) — Structured documentation for cross-session context
- [Using Commands](/core-workflows/using-commands) — All available slash commands
@@ -1,48 +1,152 @@
 ---
-title: "Dictation (Deprecated)"
-description: "Voice input feature has been removed from Cline"
+title: "Dictation"
+description: "Communicate with Cline using your voice for faster, more natural AI collaboration"
 ---

-# Dictation Feature Removed
+Dictation transforms how you work with AI. Instead of typing out complex thoughts, you speak naturally and share your complete intent. This isn't just about speed - though voice is faster - it's about enabling fluid collaboration that typing can't match.

-The dictation (voice-to-text) feature has been removed from Cline as of this release.
+## Why Voice Changes Everything

-## What Happened?
+When you type, you edit yourself. You simplify complex ideas, skip context, and lose nuance. When you speak, you share everything on your mind - the full problem, the constraints, the edge cases you're worried about.

-The voice input feature that allowed you to speak to Cline instead of typing has been discontinued and is no longer available in the extension.
+Use Dictation constantly in [Plan mode](/features/plan-and-act) for rapid back-and-forth discussions. Instead of typing careful, structured prompts, think about a problem. Cline asks clarifying questions, respond immediately, and iterate until having a solid plan.

-## Alternative Workflows
+The friction of typing was holding back real collaboration. Voice removes that friction.

-While the built-in dictation feature is no longer available, you can still work efficiently with Cline using these approaches:
+## Getting Started

-### 1. System-Level Voice Input
+**Enable Dictation:**
+1. Go to Settings → Features → Dictation
+2. Toggle "Enable Dictation" on
+3. Sign into your Cline account when prompted
+4. Install FFmpeg if you haven't already (Cline will guide you)

-Both macOS and Windows offer built-in dictation features that work across all applications:
+Once enabled, you'll see a microphone button in the chat input area.

- **macOS**: Press `Fn` twice (or `Fn Fn`) to activate dictation in any text field
- **Windows**: Press `Windows + H` to open voice typing
- **Linux**: Various desktop environments offer voice input through accessibility features
+**Using Dictation:**
+- Click the microphone button to start recording
+- Speak naturally
+- Click again to stop recording
+- Wait for transcription to appear in the chat

-These system-level tools will work in Cline's chat input just like any other text field.
+<Tip>
+Dictation works with any AI model you've configured. The transcription happens through Cline's service, but your conversation continues with whatever model you're using.
+</Tip>

-### 2. Copy-Paste from Voice Notes
+## System Requirements

-If you prefer to think out loud:
-1. Use your phone's voice recorder or a voice memo app
-2. Transcribe using your preferred tool (many phones have built-in transcription)
-3. Copy and paste the transcribed text into Cline
+<Note>
+Dictation is currently not available on Windows. Support for Windows is planned for a future release.
+</Note>

-### 3. Third-Party Transcription Tools
+Dictation uses FFmpeg to capture your voice across all platforms:

-Many standalone transcription tools can be used alongside Cline:
- Browser-based transcription services
- Desktop transcription applications
- AI-powered note-taking apps with transcription features
+- **macOS**: FFmpeg (via Homebrew: `brew install ffmpeg`)
+- **Linux**: FFmpeg (via apt: `sudo apt-get install ffmpeg`)

-## Why Was It Removed?
+If you don't have FFmpeg installed, Cline will automatically detect this and prompt you to install it with a single click.

-The dictation feature was removed to streamline Cline's core functionality and focus development efforts on the primary AI assistance capabilities.
+## Where Dictation Shines

-## Questions?
+### Plan Mode Conversations

-If you have questions about this change or need help setting up alternative voice input methods, please reach out through Cline's support channels.
+Dictation is perfect for [Plan mode](/features/plan-and-act) discussions. Instead of carefully crafting prompts, you can:
+
+- Dictate your entire problem context in one go
+- Respond to Cline's questions immediately
+- Iterate on ideas without typing friction
+- Think out loud while Cline listens
+
+Start a planning session by speaking for 2-3 minutes straight, explaining the full context of what you're trying to build, the constraints you're working with, and the specific challenges you're facing.
+
+### Complex Problem Explanation
+
+Some problems are hard to type out. When you're dealing with:
+- Multi-step workflows with edge cases
+- Integration challenges across multiple systems  
+- Performance issues with specific reproduction steps
+- UI/UX problems that need detailed context
+
+Speaking lets you explain the full situation naturally, including all the "oh, and also..." details that matter.
+
+### Code Review and Debugging
+
+When reviewing code or explaining bugs, voice lets you walk through your thought process:
+- "This function looks fine, but I'm worried about what happens when..."
+- "The issue might be in this section, or possibly this other area..."
+- "I tried X and Y, but neither worked because..."
+
+You can share your complete debugging journey instead of just the final question.
+
+## Technical Requirements
+
+**System Requirements:**
+- FFmpeg installed on your system
+- Active internet connection
+- Cline account with transcription credits
+
+**Audio Quality:**
+- Records in WebM format with Opus codec
+- Mono audio at 16kHz sample rate
+- Optimized for voice recognition
+
+**Privacy:**
+- Audio recorded locally on your machine
+- Only audio files sent for transcription
+- No audio stored after transcription
+- Temporary files automatically cleaned up
+
+## Cost and Credits
+
+Voice transcription costs $0.006 per minute through your Cline account. For most users, this works out to pennies per session.
+
+A typical 5-minute planning conversation costs about 3 cents. Even heavy voice users rarely spend more than a few dollars per month.
+
+<Note>
+Pricing is experimental and may change as we refine the service.
+</Note>
+
+## Best Practices
+
+**Speak Naturally**
+Don't try to speak like you type. Use your normal conversational tone and don't worry about perfect grammar.
+
+**Give Context First**
+Start with the big picture, then drill down into specifics. "I'm building a React app that needs to handle real-time data, and I'm running into performance issues with the WebSocket connection..."
+
+**Use Voice for Exploration**
+Dictation is perfect for exploratory conversations where you're not sure exactly what you need. Start talking through the problem and let the conversation evolve.
+
+**Combine with Text**
+You don't have to use voice for everything. Use voice for complex explanations and context, then switch to text for quick follow-ups or code snippets.
+
+## Troubleshooting
+
+**Microphone Not Working**
+- Check your IDE permissions for microphone access
+- Ensure FFmpeg is properly installed
+- Try refreshing VSCode/your editor
+
+**Poor Transcription Quality**
+- Speak clearly and at normal volume
+- Reduce background noise if possible
+- Check your microphone settings
+
+**Connection Issues**
+- Verify internet connection
+- Check if firewall is blocking Cline's servers
+- Try signing out and back into your Cline account
+
+**Authentication Issues**
+- Sign out and back into your Cline account if you see authentication errors
+- Check that your account has sufficient transcription credits
+- Verify your internet connection is stable
+
+**Audio Recording Issues**
+- Ensure FFmpeg is properly installed and accessible
+- Check that your browser/IDE has microphone permissions
+- Try restarting your editor if audio capture fails
+
+## The Future of AI Collaboration
+
+When you can speak your thoughts as fast as you think them, you stop self-editing. You share the full context, the edge cases, the "what if" scenarios that matter. This leads to better solutions and fewer back-and-forth clarifications.
@@ -0,0 +1,32 @@
+---
+title: "Drag & Drop"
+sidebarTitle: "Drag & Drop"
+---
+
+Dragging and dropping files into Cline is a quick way to add images, code, and other files to your conversations.
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/dran-n-drop.gif"
+		alt="Dragging and dropping files into Cline chat"
+	/>
+</Frame>
+
+<Note>Due to VS Code quirks, to drag and drop files into the Cline chat input, you need to hold `Shift` while dragging.</Note>
+
+Dragging and dropping workspace files into Cline will automatically create a [file mention](/features/at-mentions/file-mentions). This allows you to reference the file in your conversation without needing to type out the path.
+
+### Dragging from Finder/File Explorer
+
+You can drag files directly from your system's file manager into Cline:
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/drag-n-drop-finder.gif"
+		alt="Dragging files from Finder into Cline"
+	/>
+</Frame>
+
+### Supported File Types
+
+Cline supports dragging external images, pdfs, csv, excel, and other text files from your file system, as well as files from your workspace.
@@ -0,0 +1,67 @@
+---
+title: "Editing Messages"
+sidebarTitle: "Editing Messages"
+---
+
+Cline allows you to edit chat messages in a task after they've been submitted. This feature lets you refine your requests without starting a new task, helping you get better results with minimal disruption to your workflow.
+
+## When to Edit Messages
+
+You might want to edit a message when:
+
+-   You didn't get the results you wanted
+-   You thought of a better way to phrase your request
+-   You need to add more information or context
+-   You made a typo or error in your original message
+
+## How to Edit Messages
+
+1. Click on any message in the conversation (except the initial task message)
+2. Edit the text as needed
+3. Use the restore options to resubmit your request
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/message-editing.png"
+		alt="Message editing interface"
+	/>
+</Frame>
+
+## Restore Options
+
+When you edit a message, you have two options for restoring:
+
+### Restore Chat
+
+The "Restore Chat" option:
+
+-   Restores just the task state
+-   Re-submits an API request with your edited message
+-   Preserves all file changes made up to that point
+-   Is useful when you want to keep the current state of your workspace
+
+### Restore All
+
+The "Restore All" option:
+
+-   Restores both the task state and workspace state
+-   Re-submits an API request with your edited message
+-   Reverts your workspace to how it was at that point in the conversation
+-   Uses [checkpoints](/features/checkpoints) under the hood to restore your workspace
+-   Is useful when you want to try a completely different approach
+
+## Keyboard Shortcuts
+
+When editing a message, you can use these keyboard shortcuts:
+
+-   **Escape**: Exit edit mode without making changes
+-   **Enter**: Restore just the task (equivalent to "Restore Chat")
+-   **Cmd/Ctrl + Enter**: Restore the task and workspace (equivalent to "Restore All")
+-   **Shift + Enter**: Insert a new line / line break in your message
+
+## Best Practices
+
+-   Use message editing for minor adjustments to your requests
+-   For major changes in direction, consider starting a new task
+-   When using "Restore All," be aware that any file changes made after that message will be reverted
+-   Edit messages closer to the beginning of a conversation to avoid losing significant progress
@@ -0,0 +1,95 @@
+---
+title: "Explain Changes"
+sidebarTitle: "Explain Changes"
+---
+
+<Note>
+This feature is only available in **VS Code**. The diff view with inline comments requires VS Code's native diff capabilities.
+</Note>
+
+
+Explain Changes is an AI-powered code review feature that adds inline explanations to your code changes. When Cline makes modifications to your codebase, you can click a button to get streaming, contextual explanations that appear directly in VS Code's diff view.
+
+
+<Frame>
+	<video
+		autoPlay
+		loop
+		muted
+		playsInline
+		src="https://storage.googleapis.com/cline_public_images/explain-code-button.mp4"
+	/>
+</Frame>
+
+
+## How It Works
+<Note>
+Explain Changes requires **[Checkpoints](/features/checkpoints)** to be enabled. Make sure to enable checkpoints in your Cline settings before using this feature.
+</Note>
+
+After Cline completes a task that involves file changes, you'll see an "Explain Changes" button alongside the "View Changes" button in the completion message. Clicking this button:
+
+1. Opens a multi-file diff view showing all changed files
+2. Streams AI-generated explanations as inline comments
+3. Places comments at relevant code locations to explain what changed and why
+
+The AI uses the full conversation context to provide meaningful explanations, not just describing what code does, but explaining the reasoning behind the changes.
+
+## Interactive Comment Threads
+
+One of the most powerful aspects of Explain Changes is that the comments are fully interactive. You can have conversations directly within each comment thread.
+
+### Asking Follow-up Questions
+
+Each explanation comment has a reply input where you can ask questions about that specific piece of code:
+
+- "Why did you use this approach instead of X?"
+- "Can you explain this pattern in more detail?"
+- "What would happen if we changed this to Y?"
+
+The AI will respond with context-aware answers, understanding both the code being discussed and the original task context.
+
+### Moving to Main Chat
+
+If a conversation in a comment thread becomes complex or you want to continue working on that code, click the title area of the comment thread to move the entire conversation into Cline's main chat input. This lets you:
+
+- Continue the discussion with full Cline capabilities
+- Have Cline make additional changes based on the discussion
+- Keep the context from your review conversation
+
+## When to Use Explain Changes
+
+### Learning and Onboarding
+
+When you're new to a codebase or working with unfamiliar patterns, Explain Changes helps you understand not just what Cline did, but why. The explanations cover:
+
+- Design decisions and trade-offs
+- Technical concepts and patterns used
+- Relationships between different changes
+
+### Code Review
+
+Use Explain Changes as part of your review process:
+
+- Understand complex changes before committing
+- Verify the AI's reasoning matches your expectations
+- Catch potential issues by understanding the full context
+
+### Knowledge Transfer
+
+The explanations serve as documentation for your changes. When other team members review your code, they can see the reasoning behind each modification.
+
+## Best Practices
+
+1. **Ask specific questions**: The more specific your follow-up questions, the more useful the AI's responses will be.
+
+2. **Use for complex changes**: Explain Changes is most valuable for multi-file changes or complex logic. For simple changes, the diff view alone may be sufficient.
+
+3. **Move important discussions to chat**: If a comment thread reveals something that needs more work, move it to main chat to take action.
+
+4. **Review before committing**: Use Explain Changes as a final check before committing changes to ensure you understand everything Cline did.
+
+## Related Features
+
+- [Checkpoints](/features/checkpoints) - Required for Explain Changes to work
+- [/explain-changes](/features/slash-commands/explain-changes) - Slash command to explain any git diff
@@ -1,10 +1,9 @@
 ---
 title: "Focus Chain"
 sidebarTitle: "Focus Chain"
-description: "Automatic todo list management with real-time progress tracking for long-running tasks."
 ---

-Focus Chain is automatic todo list management with real-time progress tracking. It helps Cline work on longer tasks by maintaining a visible checklist that persists across context window resets.
+Focus Chain is a task management enhancement feature in Cline that provides automatic todo list management with real-time progress tracking throughout your tasks. 

 <Frame>
 	<img
@@ -13,53 +12,292 @@ Focus Chain is automatic todo list management with real-time progress tracking.
 	/>
 </Frame>

-## When to Use It
-
-Focus Chain works best for:
- Multi-step implementations (building a feature end-to-end)
- Tasks that might span multiple context windows
- Work where you want visibility into Cline's plan
-
-For quick, single-step requests, Focus Chain adds overhead without much benefit.
+This enables Cline to work on long-horizon tasks, seamlessly managing the context sent to LLMs, and keeping Cline on track across many context window resets.

 <Tip>
-Focus Chain pairs well with [Deep Planning](/features/deep-planning). Use `/deep-planning` to create a detailed implementation plan, then let Focus Chain track progress as you execute it.
+  Focus Chain works particularly well with Cline's [Deep Planning slash command](/features/slash-commands/deep-planning), providing seamless progress tracking for implementation tasks created through the [planning process](/features/plan-and-act).
 </Tip>

-## Enabling Focus Chain
+## Key Features

-1. Click the gear icon in the Cline sidebar
-2. Navigate to "Features"
-3. Check "Enable Focus Chain"
-4. Optionally adjust "Remind Cline Interval" (default: 6 messages)
+### Automatic Todo List Generation

-| Setting | Default | Description |
-|---------|---------|-------------|
-| Enable Focus Chain | Disabled | Enables enhanced task progress tracking |
-| Remind Cline Interval | 6 | How often Cline updates the todo list (1-100 messages) |
+Cline analyzes your task and automatically creates a comprehensive todo list with:
+- Clear, actionable items in markdown checklist format
+- Logical breakdown of complex tasks into manageable steps
+- Real-time updates as work progresses

-## How It Works
+### User-Editable Todo Lists

-When you start a task with Focus Chain enabled, Cline:
+Todo lists are stored as editable markdown files:
+- Direct editing through your preferred markdown editor
+- Automatic detection of changes you make
+- Seamless integration back into Cline's workflow
+- Quick access through the edit button in the task header

-1. Analyzes your request and creates a comprehensive todo list
-2. Stores it as an editable markdown file
-3. Updates progress in real-time as work progresses
-4. Shows a progress indicator in the task header (e.g., "3/8")
+### Visual Progress Tracking

-The todo list uses standard markdown checklist syntax:
+The task header displays clear progress indicators:
+- **Step counters** showing current progress (e.g., "3/8")
+- **Completed items** clearly marked with checkmarks
+- **Current work** highlighted with indicators
+- **Expandable view** to see the full todo list
+
+### Smart Reminder System
+
+Configurable reminders ensure todo lists stay current:
+- Default reminder every 6 messages (customizable 1-100)
+- Automatic prompts when switching from Plan Mode to Act Mode
+- User-triggered updates when todo lists are manually edited
+
+
+## Getting Started
+
+<Steps>
+  <Step title="Open Cline Settings">
+      - Click the gear icon in the Cline sidebar
+      - Navigate to the "Features" section
+  </Step>
+  <Step title="Enable Focus Chain">
+      - Check "Enable Focus Chain"
+      - Optionally adjust "Remind Cline Interval" (default: 6 messages)
+  </Step>
+  <Step title="Start a New Task">
+      - Begin a new task
+      - Cline will automatically start creating and managing todo lists
+  </Step>
+</Steps>
+
+| Setting | Default | Range | Description |
+|---------|---------|-------|-------------|
+| Enable Focus Chain | Disabled | On/Off | Enables enhanced task progress tracking |
+| Remind Cline Interval | 6 | 1-100 messages | How often Cline updates the todo list |
+
+## Usage Examples
+
+#### 1. Task Initiation
+
+When you start a new task with Focus Chain enabled:
+
+``` markdown User Request
+User: "Create a user authentication system for my React app"
+
+Cline: [Analyzes request and creates todo list]
+```
+
+#### 2. Todo List Created
+
+Cline creates a comprehensive plan for the task, stored in a markdown file:
+
+```markdown Todo List Created
+- [ ] Set up project structure
+- [ ] Install authentication dependencies
+- [ ] Create user registration component
+- [ ] Implement login functionality
+- [ ] Add password validation
+- [ ] Set up user database schema
+- [ ] Write authentication tests
+- [ ] Deploy to staging environment
+```
+
+#### 3. Progress Tracking
+
+As Cline works, the task header shows real-time progress:
+
+```markdown Todo List Header
+[3/8] Implement login functionality     ⌄
+```
+
+Click to expand and see the full list:
+
+```markdown Full Todo List
+✓ Set up project structure
+✓ Install authentication dependencies
+✓ Create user registration component
+○ Implement login functionality  ← Currently working
+○ Add password validation
+○ Set up user database schema
+○ Write authentication tests
+○ Deploy to staging environment
+```
+
+#### 4. User Editing
+
+Need to tweak the todo list? No problem.
+
+<Steps>
+  <Step title="Open the todo list">
+    Click the edit button in the expanded todo view
+  </Step>
+  <Step title="Edit the markdown file">
+    A markdown file opens in your editor:
+
+    ```markdown Editing Todo List
+    # Focus Chain Todo List for Task abc123
+
+    <!-- Edit this markdown file to update your focus chain todo list -->
+    <!-- Use - [ ] for incomplete items and - [x] for completed items -->
+
+    - [x] Set up project structure
+    - [x] Install authentication dependencies (e.g., Firebase Auth)
+    - [x] Create user registration component
+    - [ ] Implement login functionality
+    - [ ] Add password reset feature
+    - [ ] Set up protected routes
+    - [ ] Implement logout functionality
+    - [ ] Add user profile page
+    - [ ] Write authentication tests
+    - [ ] Deploy to staging environment
+
+    <!-- Save this file to update the task's todo list -->
+    ```
+  </Step>
+  <Step title="Make your changes">
+    Add, remove, or reorder items as needed
+  </Step>
+  <Step title="Save the file">
+    Cline automatically detects and uses your updates
+  </Step>
+</Steps>
+
+## File Structure
+
+### Todo List Storage
+
+Todo lists are stored as markdown files in your task directory:
+
+``` markdown
+<VSCode Global Storage>/
+  tasks/
+    <taskId>/
+      focus_chain_taskid_<taskId>.md
+      ... other task files
+```
+
+### Markdown Format
+
+Todo files use standard markdown checklist syntax:
+
+```markdown Example Todo Syntax
+# Focus Chain Todo List for Task abc123
+
+<!-- Edit this markdown file to update your focus chain todo list -->
+<!-- Use the format: - [ ] for incomplete items and - [x] for completed items -->

-```markdown
 - [x] Set up project structure
 - [x] Install authentication dependencies
 - [ ] Create user registration component
- [ ] Implement login functionality  ← Currently working
+- [ ] Implement login functionality
 - [ ] Add password validation
+- [ ] Set up user database schema
 - [ ] Write authentication tests
+- [ ] Deploy to staging environment
+
+<!-- Save this file and the todo list will be updated in the task -->
 ```

-## Editing Todo Lists

-Need to adjust the plan? Click the edit button in the expanded todo view. A markdown file opens in your editor where you can add, remove, or reorder items. Save the file and Cline automatically detects your updates.
+## Integration with Plan/Act Mode

-For complex projects, start with [Plan Mode](/core-workflows/plan-and-act) to discuss the approach before committing to a todo list.
+Focus Chain works seamlessly with Cline's [Plan/Act mode](/features/plan-and-act):
+
+- **Plan Mode**: Optional todo lists for presenting concrete steps
+- **Act Mode**: Automatic todo creation when switching from Plan Mode
+
+<Tip>
+  For complex projects, start in Plan Mode to discuss and refine your approach before switching to Act Mode for implementation.
+</Tip>
+
+## Best Practices
+
+<AccordionGroup>
+  <Accordion title="For Effective Todo Lists">
+    1. **Start with Clear Requests**
+      - Provide detailed initial task descriptions
+      - Include specific requirements and constraints
+      - Mention any preferred technologies or approaches
+
+    2. **Review Generated Lists**
+      - Check that Cline's breakdown aligns with your expectations
+      - Verify that all important steps are included
+      - Ensure the order makes sense for your project
+
+    3. **Edit When Needed**
+      - Add missing steps you identify
+      - Remove unnecessary items
+      - Reorder steps for better workflow
+      - Add more specific details to general items
+  </Accordion>
+  <Accordion title="For Complex Projects">
+    1. **Use Plan Mode First**
+      - Discuss the approach before implementation
+      - Refine requirements through conversation
+      - Switch to Act Mode when ready to begin work
+
+    2. **Break Down Large Tasks**
+      - Split complex projects into smaller, manageable tasks
+      - Create separate todo lists for different components
+      - Focus on one major area at a time
+
+    3. **Regular Reviews**
+      - Check progress periodically during long tasks
+      - Update todo lists as requirements evolve
+      - Communicate changes to Cline through edits
+  </Accordion>
+  <Accordion title="For Collaboration">
+    1. **Share Todo Files**
+      - Todo markdown files can be shared with team members
+      - Include in version control for project documentation
+      - Use as basis for project planning discussions
+
+    2. **Consistent Format**
+      - Follow the standard markdown checklist format
+      - Keep item descriptions clear and actionable
+      - Use consistent terminology across todo lists
+  </Accordion>
+</AccordionGroup>
+
+
+## Troubleshooting
+
+Having issues? Try these quick fixes:
+
+<AccordionGroup>
+  <Accordion title="Todo list not updating?">
+    - Check that Focus Chain is enabled in settings
+    - Focus Chain may not work as well with smaller, less capable models
+    - Ensure file permissions are correct in the task directory
+  </Accordion>
+  <Accordion title="Can't edit todo file?">
+    - Verify your editor supports markdown
+    - Check VSCode has write permissions for the directory
+  </Accordion>
+  <Accordion title="Progress not displaying?">
+    - Ensure todo items use correct syntax (`- [ ]` and `- [x]`)
+    - Verify the markdown file is properly formatted
+  </Accordion>
+</AccordionGroup>
+
+Still stuck? Use the [/reportbug](/features/slash-commands/report-bug) command in Cline to get help.
+
+## Technical Details (for the curious)
+
+<AccordionGroup>
+  <Accordion title="File Monitoring">
+    - Real-time file watching detects changes to todo markdown files
+    - Automatic synchronization between file edits and UI updates
+    - Graceful handling of file creation, modification, and deletion
+  </Accordion>
+  <Accordion title="Progress Calculation">
+    - Dynamic counting of completed vs. total todo items
+    - Support for both `- [x]` and `- [X]` completion syntax
+    - Unicode symbols (✓, ○) for enhanced visual display
+  </Accordion>
+  <Accordion title="Privacy Considerations">
+    - Todo lists stored locally in VSCode workspace
+    - No todo content transmitted to external services
+    - Usage telemetry (can be disabled in settings)
+  </Accordion>
+</AccordionGroup>
+
+Focus Chain turns Cline into your personal project manager, keeping you on track and your tasks organized. Give it a try on your next project!
@@ -0,0 +1,437 @@
+---
+title: "Hook Reference"
+sidebarTitle: "Hook Reference"
+description: "Complete API reference for all Cline hook types, JSON schemas, and field documentation"
+---
+
+This reference provides complete technical documentation for all hook types, their JSON schemas, input/output formats, and communication protocols.
+
+## 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 Hooks
+
+These hooks intercept and validate tool operations before and after they execute. Use them to enforce policies, track changes, and learn from operations.
+
+#### `PreToolUse`
+
+Triggered immediately before Cline uses any tool (see the [Cline Tools Reference Guide](/cline-tools) for all available tools). 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": {}
+  }
+}
+```
+
+**Example Usage:**
+```bash
+#!/usr/bin/env bash
+input=$(cat)
+
+# Block creating .js files in TypeScript projects
+tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
+if [[ "$tool_name" == "write_to_file" ]]; then
+  file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path')
+  if [[ "$file_path" == *.js ]] && [[ -f "tsconfig.json" ]]; then
+    echo '{"cancel": true, "errorMessage": "JavaScript files not allowed in TypeScript project"}'
+    exit 0
+  fi
+fi
+
+echo '{"cancel": false}'
+```
+
+#### `PostToolUse`
+
+Triggered immediately after Cline uses any tool (see the [Cline Tools Reference Guide](/cline-tools) for all available tools). 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
+  }
+}
+```
+
+**Example Usage:**
+```bash
+#!/usr/bin/env bash
+input=$(cat)
+
+# Log slow operations for performance monitoring
+execution_time=$(echo "$input" | jq -r '.postToolUse.executionTimeMs')
+tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
+
+if (( execution_time > 5000 )); then
+  context="PERFORMANCE: Slow operation detected - $tool_name took ${execution_time}ms"
+  echo "{\"cancel\": false, \"contextModification\": \"$context\"}"
+else
+  echo '{"cancel": false}'
+fi
+```
+
+### User Interaction Hooks
+
+These hooks monitor and enhance user communication with Cline. Use them to validate input, inject context, and track interaction patterns.
+
+#### `UserPromptSubmit`
+
+Triggered when the user enters text into the prompt box and presses enter to start a new task, continue a completed task, or resume a cancelled task. 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"]
+  }
+}
+```
+
+**Example Usage:**
+```bash
+#!/usr/bin/env bash
+input=$(cat)
+
+# Inject coding standards context for certain keywords
+prompt=$(echo "$input" | jq -r '.userPromptSubmit.prompt')
+context=""
+
+if echo "$prompt" | grep -qi "component\|react"; then
+  context="CODING_STANDARDS: Follow React functional component patterns with proper TypeScript types"
+elif echo "$prompt" | grep -qi "api\|endpoint"; then
+  context="CODING_STANDARDS: Use consistent REST API patterns with proper error handling"
+fi
+
+if [[ -n "$context" ]]; then
+  jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+else
+  echo '{"cancel": false}'
+fi
+```
+
+### Task Lifecycle Hooks
+
+These hooks monitor and respond to task state changes from start to finish. Use them to track progress, restore state, and trigger workflows.
+
+#### `TaskStart`
+
+Triggered once at the beginning of a new task. 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"
+    }
+  }
+}
+```
+
+**Example Usage:**
+```bash
+#!/usr/bin/env bash
+input=$(cat)
+
+# Detect project type and inject relevant context
+context=""
+
+if [[ -f "package.json" ]]; then
+  if grep -q "react" package.json; then
+    context="PROJECT_TYPE: React application detected. Follow component-based architecture."
+  elif grep -q "express" package.json; then
+    context="PROJECT_TYPE: Express.js API detected. Follow RESTful patterns."
+  else
+    context="PROJECT_TYPE: Node.js project detected."
+  fi
+elif [[ -f "requirements.txt" ]] || [[ -f "pyproject.toml" ]]; then
+  context="PROJECT_TYPE: Python project detected. Follow PEP 8 standards."
+elif [[ -f "Cargo.toml" ]]; then
+  context="PROJECT_TYPE: Rust project detected. Follow Rust conventions."
+fi
+
+if [[ -n "$context" ]]; then
+  jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+else
+  echo '{"cancel": false}'
+fi
+```
+
+#### `TaskResume`
+
+Triggered when the user resumes a task that has been cancelled or aborted. 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`
+
+Triggered when the user cancels a task or aborts a hook execution. 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"
+    }
+  }
+}
+```
+
+#### `TaskComplete`
+
+Triggered when Cline finishes its work and successfully executes the `attempt_completion` tool to finalize the task output. Use it to track completion metrics, generate reports, log task outcomes, and trigger completion workflows.
+
+**Input Fields:**
+```json
+{
+  "clineVersion": "string",
+  "hookName": "TaskComplete",
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "taskComplete": {
+    "taskMetadata": {
+      "taskId": "string",
+      "ulid": "string"
+    }
+  }
+}
+```
+
+**Example Usage:**
+```bash
+#!/usr/bin/env bash
+input=$(cat)
+
+# Extract task metadata
+task_id=$(echo "$input" | jq -r '.taskComplete.taskMetadata.taskId // "unknown"')
+ulid=$(echo "$input" | jq -r '.taskComplete.taskMetadata.ulid // "unknown"')
+
+# Log completion
+completion_log="$HOME/.cline_completions/$(date +%Y-%m-%d).log"
+mkdir -p "$(dirname "$completion_log")"
+
+echo "$(date -Iseconds): Task $task_id completed (ULID: $ulid)" >> "$completion_log"
+
+# Provide context about completion
+context="TASK_COMPLETED: Task $task_id finished successfully. Completion logged."
+jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+```
+
+### System Events Hooks
+
+These hooks monitor internal Cline operations and system-level events. Use them to track context usage, log system behavior, and analyze performance patterns.
+
+## JSON Communication Protocol
+
+Hooks receive JSON via stdin and return JSON via stdout.
+
+### Input Format
+
+All hooks receive a JSON object through stdin with this base structure:
+
+```json
+{
+  "clineVersion": "string",
+  "hookName": "string", 
+  "timestamp": "string",
+  "taskId": "string",
+  "workspaceRoots": ["string"],
+  "userId": "string",
+  "[hookSpecificField]": {
+    // Hook-specific data structure
+  }
+}
+```
+
+### Output Format
+
+Your hook script must output a JSON response as the final stdout content:
+
+```json
+{
+  "cancel": false,
+  "contextModification": "WORKSPACE_RULES: Use TypeScript",
+  "errorMessage": "Error details if blocking"
+}
+```
+
+**Field Descriptions:**
+
+- **`cancel`** (required): Boolean controlling whether execution continues
+  - `true`: Block the current action
+  - `false`: Allow the action to proceed
+
+- **`contextModification`** (optional): String that gets injected into the conversation
+  - Affects future AI decisions, not the current one
+  - Use clear prefixes like `WORKSPACE_RULES:`, `PERFORMANCE:`, `SECURITY:` for categorization
+  - Maximum length: 50KB
+
+- **`errorMessage`** (optional): String shown to user when `cancel` is `true`
+  - Only displayed when blocking an action
+  - Should explain why the action was blocked
+
+### Logging During Execution
+
+Your hook script can output logging or diagnostic information to stdout during execution, as long as the JSON response is the last thing written:
+
+```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}'
+```
+
+Cline will parse only the final JSON object from stdout.
+
+### Error Handling
+
+Hook execution errors don't prevent task execution - only returning `"cancel": true` can halt a task. All other errors are treated as hook failures, not reasons to abort the task.
+
+**Hook Status Display:**
+
+- **Completed** (grey): Hook executed successfully, regardless of whether it returned `"cancel": false` or no JSON output
+- **Failed** (red): Hook exited with non-zero status, output invalid JSON, or timed out. The UI displays the error details (e.g., exit code number)
+- **Aborted** (red): Hook returned `"cancel": true`, halting the task. User must manually resume the task to continue
+
+**Important:** Even when a hook fails (non-zero exit, invalid JSON, timeout), Cline continues with the task. Only `"cancel": true` stops execution.
+
+### Context Modification 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**: Use for blocking bad actions + injecting context for next decision
+- **PostToolUse hooks**: Use for learning from completed actions
+
+### Helpful Tip: String Escaping in JSON
+
+When your hook needs to include strings containing unescaped quote characters (`"`) in JSON output, use jq's `--arg` flag for proper escaping:
+
+```bash
+#!/usr/bin/env bash
+
+# When $output contains unescaped quote characters (")...
+output='{"foo":"bar"}'
+
+# Use the --arg flag for automatic string escaping
+jq -n --arg ctx "$output" '{cancel: false, contextModification: $ctx}'
+
+# This will result in:
+# {
+#     "cancel": false,
+#     "contextModification": "{\"foo\":\"bar\"}"
+# }
+```
+
+The `--arg` flag automatically escapes special characters, preventing JSON parsing errors when your context modification includes complex strings or nested JSON structures.
+
+## Hook Execution Environment
+
+### Execution Context
+
+Hooks are executable scripts that run with the same permissions as VS Code. They have unrestricted access to:
+- The entire filesystem (any file the user can access)
+- All environment variables
+- System commands and tools
+- Network resources
+
+Hooks can perform any operation the user could perform in a terminal, including reading and writing files outside the workspace, making network requests, and executing system commands.
+
+### Security Considerations
+
+<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>
+
+### Performance Guidelines
+
+Hooks have a 30 second timeout. As long as your hook completes within this time, it can perform any operations needed, including network calls or heavy computations.
+
+### Hook Discovery
+
+Cline searches for hooks in this order:
+1. Project-specific: `.clinerules/hooks/` in workspace root
+2. User-global: `~/Documents/Cline/Hooks/`
+
+Project-specific hooks override global hooks with the same name.
@@ -0,0 +1,166 @@
+---
+title: "Hooks Overview"
+sidebarTitle: "Overview"
+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
+
+## Getting Started
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/hooks.gif" alt="Hooks in action" />
+</Frame>
+
+<Note>
+Hooks work across all platforms: Windows, macOS, and Linux. The bash examples in this documentation work with standard shells on all platforms (including Git Bash or WSL on Windows).
+</Note>
+
+Setting up hooks in Cline is user-friendly with the built-in hooks management interface. Here's how to get started:
+
+<Steps>
+<Step title="Access the Hooks Interface">
+Navigate to the Hooks management interface:
+
+<Frame>
+  <img src="/assets/hooks/hooks-interface-with-dropdown.png" alt="Hooks management interface showing Global Hooks and project-specific hooks with dropdown menu" />
+</Frame>
+
+1. Open Cline (ensure hooks are enabled in settings)
+2. Look for the **Hooks** tab at the top (alongside Rules and Workflows)
+3. Click on **Hooks** to open the hooks management panel
+
+The interface shows you all available hook types and existing hooks organized by workspace.
+</Step>
+
+<Step title="Understand Hook Locations">
+Hooks are automatically organized by location in the interface:
+
+**Global Hooks** - Apply to all workspaces:
+- Stored in `~/Documents/Cline/Hooks/`
+- Perfect for personal coding standards and universal rules
+
+**Project-Specific Hooks** - Apply only to current project:
+- Stored in `.clinerules/hooks/` within your repo
+- Great for project-specific validation and team workflows
+- Can be committed to version control for team sharing
+
+Multi-root workspaces run hooks from all of the repos in your open workspace, making it easy to manage and run hooks across different repos within the same workspace.
+</Step>
+
+<Step title="Create Your First Hook">
+Use the intuitive interface to create hooks:
+
+<Frame>
+  <img src="/assets/hooks/hooks-empty-state.png" alt="Empty hooks interface showing New hook... dropdowns for both Global Hooks and project-specific hooks before any hooks are created" />
+</Frame>
+
+1. **Choose your location**: Decide between Global Hooks or project-specific hooks
+2. **Select hook type**: Click the **"New hook..."** dropdown in your chosen location
+3. **Pick a hook type**: The dropdown shows all available hook types that haven't been created yet in this location. Only one of each hook type is allowed per hooks directory, so the dropdown automatically filters to show only the remaining available types.
+
+<Frame>
+  <img src="/assets/hooks/new-hook-dropdown.png" alt="Creating a new hook with the dropdown menu showing UserPromptSubmit selected with description" />
+</Frame>
+
+4. **Review and edit the hook**: Click the pencil icon to review the hook's code and add your custom logic
+5. **Enable the hook**: Once you understand and approve of the hook's behavior, toggle the switch to activate it
+
+<Frame>
+  <img src="/assets/hooks/hook-controls.png" alt="Hook management controls showing toggle, edit, and delete buttons for each hook" />
+</Frame>
+
+<Warning>
+Always review a hook's code before enabling it. Hooks execute automatically during your workflow, so it's important to understand what they do before activation.
+</Warning>
+</Step>
+
+<Step title="Test Your Hook">
+To develop and refine your hook, you'll need to trigger it multiple times during testing. Each hook type is triggered by different events in Cline's workflow. For example:
+
+- **TaskStart** hooks trigger when you start a new task
+- **PreToolUse** hooks trigger before Cline executes tools like file editing
+- **PostToolUse** hooks trigger after tool execution completes
+- **UserPromptSubmit** hooks trigger when you submit a message to Cline
+
+For complete details on when each hook type is triggered and how to test them effectively, see the [Hook Reference](/features/hooks/hook-reference) documentation. This includes the specific conditions that trigger each hook and examples of how to invoke them during development.
+</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>
+
+## What You Can Build
+
+Once you understand the basics, hooks open up creative possibilities:
+
+<CardGroup cols={2}>
+  <Card title="Intelligent Code Review" icon="code-branch">
+    Run linters or custom validators before files get saved. Block commits that don't pass checks. Track code quality metrics over time.
+  </Card>
+  
+  <Card title="Security Enforcement" icon="shield-halved">
+    Prevent operations that violate security policies. Detect when sensitive data might be exposed. Audit all file access for compliance.
+  </Card>
+  
+  <Card title="Development Analytics" icon="chart-line">
+    Measure how long different operations take. Identify patterns in how the AI works. Generate productivity reports from hook data.
+  </Card>
+  
+  <Card title="Integration Hub" icon="plug">
+    Connect to issue trackers when certain keywords appear. Update project management tools. Sync with external APIs at the right moments.
+  </Card>
+</CardGroup>
+
+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.
+
+## Explore the Documentation
+
+<CardGroup cols={2}>
+  <Card title="Hook Reference" icon="book" href="/features/hooks/hook-reference">
+    Complete API reference for all hook types, JSON schemas, and field documentation.
+  </Card>
+  
+  <Card title="Samples" icon="code" href="/features/hooks/samples">
+    Practical examples and complete working scripts for common use cases.
+  </Card>
+</CardGroup>
+
+## CLI support
+
+Hooks are also available in the [Cline CLI](/cline-cli/overview). You can enable or disable hooks when running tasks from the command line:
+
+```bash
+# Enable hooks for a task
+cline "What does this repo do?" -s hooks_enabled=true
+
+# Configure hooks globally via CLI
+cline config set hooks-enabled=true
+cline config get hooks-enabled
+```
+
+This allows you to integrate hooks into automated workflows, CI/CD pipelines, and headless task execution.
+
+<Note>
+Hooks in the CLI are only supported on macOS and Linux. Windows support is not yet available.
+</Note>
+
+## 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
+- [Cline CLI](/cline-cli/overview) enables hooks in terminal-based and automated workflows
@@ -0,0 +1,755 @@
+---
+title: "Samples"
+sidebarTitle: "Samples"
+description: "Practical hook examples organized by complexity level - from beginner to advanced patterns"
+---
+
+This page provides complete, production-ready hook examples organized by skill level. Each example includes full working code, detailed explanations, and guidance on when to use each pattern.
+
+## How to Use These Samples
+
+Each sample is designed to be:
+- **Copy-and-paste ready**: Use them directly or as starting points
+- **Educational**: Learn hook concepts through progressive complexity
+- **Practical**: Solve real development workflow challenges
+
+Choose samples based on your experience level and gradually work up to more advanced patterns.
+
+---
+
+## Beginner Examples
+
+Perfect for getting started with hooks. These examples demonstrate core concepts with straightforward logic.
+
+### 1. Project Type Detection
+
+**Hook:** `TaskStart`
+
+```bash
+#!/usr/bin/env bash
+# Project Type Detection Hook
+# 
+# Overview: Automatically detects project type at task start and injects relevant
+# coding standards and best practices into the AI context. This helps Cline understand
+# your project structure and apply appropriate conventions from the beginning.
+#
+# Demonstrates: Basic hook input/output, file system checks, conditional logic,
+# and context injection to guide AI behavior.
+
+input=$(cat)
+
+# Read basic JSON structure and detect project type
+context=""
+
+# Check for different project indicators
+if [[ -f "package.json" ]]; then
+  if grep -q "react" package.json; then
+    context="PROJECT_TYPE: React application detected. Follow component-based architecture and use functional components."
+  elif grep -q "express" package.json; then
+    context="PROJECT_TYPE: Express.js API detected. Follow RESTful patterns and proper middleware structure."
+  else
+    context="PROJECT_TYPE: Node.js project detected. Use proper npm scripts and dependency management."
+  fi
+elif [[ -f "requirements.txt" ]] || [[ -f "pyproject.toml" ]]; then
+  context="PROJECT_TYPE: Python project detected. Follow PEP 8 standards and use virtual environments."
+elif [[ -f "Cargo.toml" ]]; then
+  context="PROJECT_TYPE: Rust project detected. Follow Rust conventions and use proper error handling."
+elif [[ -f "go.mod" ]]; then
+  context="PROJECT_TYPE: Go project detected. Follow Go conventions and use proper package structure."
+fi
+
+# Return the context to guide Cline's behavior
+if [[ -n "$context" ]]; then
+  jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+else
+  echo '{"cancel": false}'
+fi
+```
+
+**Key Concepts:**
+- Reading hook input with `input=$(cat)`
+- Using file system checks to detect project type
+- Returning context to influence AI behavior
+- Basic JSON output with `jq`
+
+### 2. File Extension Validator
+
+**Hook:** `PreToolUse`
+
+```bash
+#!/usr/bin/env bash
+# File Extension Validator Hook
+#
+# Overview: Enforces TypeScript file extensions in TypeScript projects by blocking
+# creation of .js and .jsx files. This prevents common mistakes where developers
+# accidentally create JavaScript files when they should be using TypeScript.
+#
+# Demonstrates: PreToolUse blocking, parameter extraction, conditional validation,
+# and providing clear error messages to guide users toward correct file extensions.
+
+input=$(cat)
+
+# Extract tool information
+tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
+
+# Only process file creation tools
+if [[ "$tool_name" != "write_to_file" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Check if this is a TypeScript project
+if [[ ! -f "tsconfig.json" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Get the file path from tool parameters
+file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path // empty')
+
+if [[ -z "$file_path" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Block .js files in TypeScript projects
+if [[ "$file_path" == *.js ]]; then
+  echo '{"cancel": true, "errorMessage": "JavaScript files (.js) are not allowed in TypeScript projects. Use .ts extension instead."}'
+  exit 0
+fi
+
+# Block .jsx files, suggest .tsx
+if [[ "$file_path" == *.jsx ]]; then
+  echo '{"cancel": true, "errorMessage": "JSX files (.jsx) are not allowed in TypeScript projects. Use .tsx extension instead."}'
+  exit 0
+fi
+
+# Everything is OK
+echo '{"cancel": false}'
+```
+
+**Key Concepts:**
+- Extracting tool name and parameters
+- Conditional logic based on project state
+- Blocking operations with `"cancel": true`
+- Providing helpful error messages
+
+### 3. Basic Performance Monitor
+
+**Hook:** `PostToolUse`
+
+```bash
+#!/usr/bin/env bash
+# Basic Performance Monitor Hook
+#
+# Overview: Monitors tool execution times and logs operations that exceed a 3-second
+# threshold. This helps identify performance bottlenecks and provides feedback to
+# users about system resource issues that may be slowing down Cline's operations.
+#
+# Demonstrates: PostToolUse hook usage, arithmetic operations in bash, simple file
+# logging, and conditional context injection based on performance metrics.
+
+input=$(cat)
+
+# Extract performance information
+tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
+execution_time=$(echo "$input" | jq -r '.postToolUse.executionTimeMs // 0')
+success=$(echo "$input" | jq -r '.postToolUse.success')
+
+# Log slow operations (threshold: 3 seconds)
+if (( execution_time > 3000 )); then
+  # Create simple log directory
+  mkdir -p "$HOME/.cline_logs"
+  
+  # Log the slow operation
+  echo "$(date -Iseconds): SLOW OPERATION - $tool_name took ${execution_time}ms" >> "$HOME/.cline_logs/performance.log"
+  
+  # Provide feedback to user
+  context="PERFORMANCE: Operation $tool_name took ${execution_time}ms. Consider checking system resources if this happens frequently."
+  jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+else
+  echo '{"cancel": false}'
+fi
+```
+
+**Key Concepts:**
+- Processing results after tool execution
+- Basic arithmetic operations in bash
+- Simple file logging
+- Conditional context injection
+
+## Intermediate Examples
+
+These examples demonstrate more advanced concepts including external tool integration, pattern matching, and structured logging.
+
+### 4. Code Quality with Linting
+
+**Hook:** `PreToolUse`
+
+```bash
+#!/usr/bin/env bash
+# Code Quality Linting Hook
+#
+# Overview: Integrates ESLint and Flake8 to enforce code quality standards before
+# files are written. Blocks file creation if linting errors are detected, ensuring
+# all code meets quality standards. Supports TypeScript, JavaScript, and Python files.
+#
+# Demonstrates: External tool integration, temporary file handling, regex pattern
+# matching, and comprehensive error reporting with actionable feedback.
+
+input=$(cat)
+
+tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
+
+# Only lint file write operations
+if [[ "$tool_name" != "write_to_file" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path // empty')
+
+# Skip non-code files
+if [[ ! "$file_path" =~ \.(ts|tsx|js|jsx|py|rs)$ ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Get file content from the tool parameters  
+content=$(echo "$input" | jq -r '.preToolUse.parameters.content // empty')
+
+if [[ -z "$content" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Create temporary file for linting
+temp_file=$(mktemp)
+echo "$content" > "$temp_file"
+
+# Run appropriate linter based on file extension
+lint_errors=""
+if [[ "$file_path" =~ \.(ts|tsx)$ ]] && command -v eslint > /dev/null; then
+  lint_output=$(eslint "$temp_file" --format=json 2>/dev/null || true)
+  if [[ "$lint_output" != "[]" ]] && [[ -n "$lint_output" ]]; then
+    error_count=$(echo "$lint_output" | jq '.[0].errorCount // 0')
+    if (( error_count > 0 )); then
+      messages=$(echo "$lint_output" | jq -r '.[0].messages[] | "\(.line):\(.column) \(.message)"')
+      lint_errors="ESLint errors found:\n$messages"
+    fi
+  fi
+elif [[ "$file_path" =~ \.py$ ]] && command -v flake8 > /dev/null; then
+  lint_output=$(flake8 "$temp_file" 2>/dev/null || true)
+  if [[ -n "$lint_output" ]]; then
+    lint_errors="Flake8 errors found:\n$lint_output"
+  fi
+fi
+
+# Cleanup
+rm -f "$temp_file"
+
+# Block if linting errors found
+if [[ -n "$lint_errors" ]]; then
+  error_message="Code quality check failed. Please fix these issues:\n\n$lint_errors"
+  jq -n --arg msg "$error_message" '{"cancel": true, "errorMessage": $msg}'
+else
+  echo '{"cancel": false}'
+fi
+```
+
+**Key Concepts:**
+- Temporary file creation and cleanup
+- External tool integration (eslint, flake8)
+- Complex pattern matching with regex
+- Structured error reporting
+
+### 5. Security Scanner
+
+**Hook:** `PreToolUse`
+
+```bash
+#!/usr/bin/env bash
+# Security Scanner Hook
+#
+# Overview: Scans file content for hardcoded secrets (API keys, tokens, passwords)
+# before files are written. Blocks creation of files containing secrets except in
+# safe locations like .env.example files or documentation, preventing credential leaks.
+#
+# Demonstrates: Pattern matching with regex arrays, file path exception handling,
+# security-focused validation, and clear user guidance in error messages.
+
+input=$(cat)
+
+tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
+
+# Only check file operations
+if [[ "$tool_name" != "write_to_file" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+content=$(echo "$input" | jq -r '.preToolUse.parameters.content // empty')
+file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path // empty')
+
+# Skip if no content
+if [[ -z "$content" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Define secret patterns (simplified for readability)
+secrets_found=""
+
+# Check for API keys
+if echo "$content" | grep -qi "api[_-]*key.*[=:].*['\"][a-z0-9_-]{10,}['\"]"; then
+  secrets_found+="- API key pattern detected\n"
+fi
+
+# Check for tokens
+if echo "$content" | grep -qi "token.*[=:].*['\"][a-z0-9_-]{10,}['\"]"; then
+  secrets_found+="- Token pattern detected\n"
+fi
+
+# Check for passwords
+if echo "$content" | grep -qi "password.*[=:].*['\"][^'\"]{8,}['\"]"; then
+  secrets_found+="- Password pattern detected\n"
+fi
+
+# Allow secrets in safe files
+safe_patterns=("\.env\.example$" "\.env\.template$" "/docs/" "\.md$")
+is_safe_file=false
+for safe_pattern in "${safe_patterns[@]}"; do
+  if [[ "$file_path" =~ $safe_pattern ]]; then
+    is_safe_file=true
+    break
+  fi
+done
+
+if [[ -n "$secrets_found" ]] && [[ "$is_safe_file" == false ]]; then
+  error_message="🔒 SECURITY ALERT: Potential secrets detected in $file_path
+
+$secrets_found
+Please use environment variables or a secrets management service instead."
+
+  jq -n --arg msg "$error_message" '{"cancel": true, "errorMessage": $msg}'
+else
+  echo '{"cancel": false}'
+fi
+```
+
+**Key Concepts:**
+- Pattern arrays and iteration
+- File path exception handling  
+- Security-focused validation
+- Clear user guidance in error messages
+
+### 6. Git Workflow Assistant
+
+**Hook:** `PostToolUse`
+
+```bash
+#!/usr/bin/env bash
+# Git Workflow Assistant Hook
+#
+# Overview: Analyzes file modifications and provides intelligent git workflow suggestions
+# based on file types and current branch. Encourages best practices like feature branches
+# for components and test branches for test files, with actionable git commands.
+#
+# Demonstrates: Git integration, branch analysis, file path pattern matching, and
+# contextual suggestions to guide users toward better git practices.
+
+input=$(cat)
+
+tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
+success=$(echo "$input" | jq -r '.postToolUse.success')
+
+# Only process successful file modifications
+if [[ "$success" != "true" ]] || [[ "$tool_name" != "write_to_file" && "$tool_name" != "replace_in_file" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Check if we're in a git repository
+if ! git rev-parse --git-dir > /dev/null 2>&1; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+file_path=$(echo "$input" | jq -r '.postToolUse.parameters.path // empty')
+current_branch=$(git branch --show-current 2>/dev/null || echo "main")
+
+# Analyze file type and suggest appropriate branch naming
+context=""
+if [[ "$file_path" == *"component"* ]] && [[ "$current_branch" == "main" || "$current_branch" == "master" ]]; then
+  component_name=$(basename "$file_path" .tsx .ts .jsx .js)
+  context="GIT_WORKFLOW: Consider creating a feature branch: git checkout -b feature/add-${component_name,,}-component"
+elif [[ "$file_path" == *"test"* ]] || [[ "$file_path" == *"spec"* ]]; then
+  if [[ "$current_branch" == "main" || "$current_branch" == "master" ]]; then
+    context="GIT_WORKFLOW: Consider creating a test branch: git checkout -b test/add-tests-$(basename "$(dirname "$file_path")")"
+  fi
+fi
+
+# Add staging guidance
+if [[ -n "$context" ]]; then
+  context="$context After completing changes, use 'git add $file_path' to stage for commit."
+else
+  context="GIT_WORKFLOW: File modified: $file_path. Use 'git add $file_path' when ready to commit."
+fi
+
+jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+```
+
+**Key Concepts:**
+- Git repository detection
+- Branch analysis and suggestions
+- File path analysis for context
+- Actionable user guidance
+
+## Advanced Examples
+
+These examples showcase sophisticated patterns including external integrations, asynchronous processing, and complex state management.
+
+### 7. Comprehensive Task Lifecycle Manager
+
+**Hook:** `TaskComplete`
+
+```bash
+#!/usr/bin/env bash
+# Comprehensive Task Lifecycle Manager Hook
+#
+# Overview: Tracks task completions by generating detailed markdown reports with
+# workspace information and git state, and optionally sends webhook notifications
+# to external systems. Perfect for enterprise environments requiring audit trails.
+#
+# Demonstrates: Complex data extraction, structured report generation, markdown
+# heredocs, asynchronous webhook notifications, and robust error handling.
+
+input=$(cat)
+
+# Extract task metadata using proper API field paths
+task_id=$(echo "$input" | jq -r '.taskId')
+ulid=$(echo "$input" | jq -r '.taskComplete.taskMetadata.ulid // "unknown"')
+completion_time=$(echo "$input" | jq -r '.timestamp')
+
+# Create completion report directory with error handling
+reports_dir="$HOME/.cline_reports"
+if [[ ! -d "$(dirname "$reports_dir")" ]]; then
+  echo '{"cancel": false, "errorMessage": "Cannot access home directory"}' 
+  exit 0
+fi
+mkdir -p "$reports_dir" || exit 0
+
+# Generate safe, unique report filename
+safe_task_id=$(echo "$task_id" | tr -cd '[:alnum:]_-' | head -c 50)
+report_file="$reports_dir/completion_$(date +%Y%m%d_%H%M%S)_${safe_task_id}.md"
+
+# Collect comprehensive workspace information
+git_branch=$(git branch --show-current 2>/dev/null || echo "No git repository")
+git_status_count=$(git status --porcelain 2>/dev/null | wc -l || echo "0")
+project_name=$(basename "$PWD")
+
+# Generate detailed completion report
+cat > "$report_file" << EOF
+# Cline Task Completion Report
+
+**Task ID:** $task_id  
+**ULID:** $ulid  
+**Completed:** $(date -Iseconds)  
+**Completion Time:** $completion_time
+
+## Workspace Information
+- **Project:** $project_name
+- **Git Branch:** $git_branch
+- **Modified Files:** $git_status_count
+
+## Completion Status
+✅ Task completed successfully
+
+## Next Steps
+- Review changes made during this task
+- Consider committing changes if appropriate  
+- Run tests to verify functionality
+EOF
+
+# Send webhook notification if configured
+webhook_url="${COMPLETION_WEBHOOK_URL:-}"
+if [[ -n "$webhook_url" ]]; then
+  payload=$(jq -n \
+    --arg task_id "$task_id" \
+    --arg ulid "$ulid" \
+    --arg workspace "$project_name" \
+    --arg timestamp "$completion_time" \
+    '{
+      event: "task_completed",
+      task_id: $task_id,
+      ulid: $ulid,
+      workspace: $workspace,
+      timestamp: $timestamp
+    }')
+  
+  # Send notification in background with timeout
+  (curl -X POST \
+    -H "Content-Type: application/json" \
+    -d "$payload" \
+    "$webhook_url" \
+    --max-time 5 \
+    --silent > /dev/null 2>&1) &
+fi
+
+context="TASK_COMPLETED: ✅ Task $task_id finished successfully. Report saved to: $(basename "$report_file")"
+jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+```
+
+**Key Concepts:**
+- Complex data extraction and validation
+- Structured report generation
+- Asynchronous webhook notifications
+- Error handling and resource management
+
+### 8. Intelligent User Input Enhancer  
+
+**Hook:** `UserPromptSubmit`
+
+```bash
+#!/usr/bin/env bash
+# Intelligent User Input Enhancer Hook
+#
+# Overview: Analyzes user prompts to detect potentially harmful commands, logs user
+# activity for analytics, and intelligently injects project and git context based on
+# prompt keywords. Provides safety guards while enhancing AI responses with relevant context.
+#
+# Demonstrates: UserPromptSubmit hook usage, multi-pattern safety validation, intelligent
+# context detection from prompts, structured JSON logging, and dynamic suggestion generation.
+
+input=$(cat)
+
+user_prompt=$(echo "$input" | jq -r '.userPromptSubmit.prompt')
+task_id=$(echo "$input" | jq -r '.taskId')
+user_id=$(echo "$input" | jq -r '.userId')
+
+# Log user activity for analytics
+activity_log="$HOME/.cline_user_activity/$(date +%Y-%m-%d).log"
+mkdir -p "$(dirname "$activity_log")"
+
+activity_entry=$(jq -n \
+  --arg timestamp "$(date -Iseconds)" \
+  --arg task_id "$task_id" \
+  --arg user_id "$user_id" \
+  --arg prompt_length "${#user_prompt}" \
+  '{
+    timestamp: $timestamp,
+    task_id: $task_id,
+    user_id: $user_id,
+    prompt_length: ($prompt_length | tonumber),
+    workspace: env.PWD
+  }')
+
+echo "$activity_entry" >> "$activity_log"
+
+context_modifications=""
+cancel_request=false
+
+# Safety validation
+harmful_patterns=("rm -rf" "delete.*all" "format.*drive" "sudo.*passwd")
+for pattern in "${harmful_patterns[@]}"; do
+  if echo "$user_prompt" | grep -qi "$pattern"; then
+    cancel_request=true
+    error_message="🚨 SAFETY ALERT: Potentially harmful command detected. Please review your request."
+    break
+  fi
+done
+
+# Intelligent context enhancement
+if [[ "$cancel_request" == false ]]; then
+  # Detect project context
+  if echo "$user_prompt" | grep -qi "file\|directory\|folder"; then
+    if [[ -f "package.json" ]]; then
+      project_name=$(jq -r '.name // "unknown"' package.json 2>/dev/null)
+      context_modifications+="PROJECT_CONTEXT: Working in Node.js project '$project_name'. "
+    elif [[ -f "requirements.txt" ]]; then
+      context_modifications+="PROJECT_CONTEXT: Working in Python project. "
+    fi
+  fi
+  
+  # Git context enhancement
+  if echo "$user_prompt" | grep -qi "git\|commit\|branch" && git rev-parse --git-dir > /dev/null 2>&1; then
+    current_branch=$(git branch --show-current 2>/dev/null)
+    uncommitted=$(git status --porcelain | wc -l)
+    context_modifications+="GIT_CONTEXT: On branch '$current_branch' with $uncommitted uncommitted changes. "
+  fi
+  
+  # Tool suggestions
+  if echo "$user_prompt" | grep -qi "search.*code\|find.*function"; then
+    context_modifications+="SUGGESTION: Consider using search_files tool for code exploration. "
+  fi
+fi
+
+# Return response
+if [[ "$cancel_request" == true ]]; then
+  jq -n --arg msg "$error_message" '{"cancel": true, "errorMessage": $msg}'
+else
+  if [[ -n "$context_modifications" ]]; then
+    jq -n --arg ctx "$context_modifications" '{"cancel": false, "contextModification": $ctx}'
+  else
+    echo '{"cancel": false}'
+  fi
+fi
+```
+
+**Key Concepts:**
+- User interaction analysis and logging
+- Multi-pattern safety validation
+- Intelligent context detection
+- Dynamic suggestion generation
+
+### 9. Multi-Service Integration Hub
+
+**Hook:** `PostToolUse`
+
+```bash
+#!/usr/bin/env bash
+# Multi-Service Integration Hub Hook
+#
+# Overview: Detects file modifications by type (dependencies, CI/CD, frontend, backend, tests)
+# and sends asynchronous webhook notifications to multiple external services like Slack and
+# CI/CD systems. Enables seamless integration of Cline operations into enterprise workflows.
+#
+# Demonstrates: Advanced pattern matching with associative arrays, multi-service webhook
+# orchestration, asynchronous background processing, and enterprise notification patterns.
+
+input=$(cat)
+
+tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
+success=$(echo "$input" | jq -r '.postToolUse.success')
+file_path=$(echo "$input" | jq -r '.postToolUse.parameters.path // empty')
+
+# Only process successful file operations
+if [[ "$success" != "true" ]] || [[ "$tool_name" != "write_to_file" && "$tool_name" != "replace_in_file" ]]; then
+  echo '{"cancel": false}'
+  exit 0
+fi
+
+# Define workflow triggers
+declare -A triggers=(
+  ["package\\.json|yarn\\.lock"]="dependencies"
+  ["\\.github/workflows/"]="ci_cd"
+  ["src/.*component"]="frontend"
+  ["api/.*\\.(ts|js)"]="backend"
+  [".*\\.(test|spec)\\."]="testing"
+)
+
+# Determine triggered workflows
+triggered_workflows=""
+for pattern in "${!triggers[@]}"; do
+  if [[ "$file_path" =~ $pattern ]]; then
+    workflow_type="${triggers[$pattern]}"
+    triggered_workflows+="$workflow_type "
+  fi
+done
+
+context="WORKFLOW: File modified: $file_path"
+
+if [[ -n "$triggered_workflows" ]]; then
+  # Slack notification (async)
+  slack_webhook="${SLACK_WEBHOOK_URL:-}"
+  if [[ -n "$slack_webhook" ]]; then
+    slack_payload=$(jq -n \
+      --arg file "$file_path" \
+      --arg workflows "$triggered_workflows" \
+      --arg workspace "$(basename "$PWD")" \
+      '{
+        text: ("🔧 Cline modified `" + $file + "` in " + $workspace),
+        color: "good",
+        fields: [{
+          title: "Triggered Workflows",
+          value: $workflows,
+          short: true
+        }]
+      }')
+    
+    (curl -X POST -H "Content-Type: application/json" -d "$slack_payload" "$slack_webhook" --max-time 5 --silent > /dev/null 2>&1) &
+  fi
+
+  # CI/CD webhook (async)  
+  ci_webhook="${CI_WEBHOOK_URL:-}"
+  if [[ -n "$ci_webhook" ]]; then
+    ci_payload=$(jq -n \
+      --arg file "$file_path" \
+      --arg workflows "$triggered_workflows" \
+      '{
+        event: "file_modified",
+        file_path: $file,
+        workflows: ($workflows | split(" "))
+      }')
+    
+    (curl -X POST -H "Content-Type: application/json" -d "$ci_payload" "$ci_webhook" --max-time 5 --silent > /dev/null 2>&1) &
+  fi
+
+  context+=" Triggered workflows: $triggered_workflows. Notifications sent to configured services."
+fi
+
+jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
+```
+
+**Key Concepts:**
+- Multi-service integration patterns
+- Asynchronous webhook orchestration  
+- Complex workflow detection
+- Enterprise notification systems
+
+## Usage Tips
+
+### Running Multiple Hooks
+
+You can use multiple hooks together by creating separate files for each hook type:
+
+```bash
+# Create hooks directory
+mkdir -p .clinerules/hooks
+
+# Create multiple hooks
+touch .clinerules/hooks/PreToolUse
+touch .clinerules/hooks/PostToolUse
+touch .clinerules/hooks/TaskStart
+
+# Make them executable
+chmod +x .clinerules/hooks/*
+```
+
+### Environment Configuration
+
+Set up environment variables for external integrations:
+
+```bash
+# Add to your .bashrc or .zshrc
+export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..."
+export JIRA_URL="https://yourcompany.atlassian.net"
+export JIRA_USER="your-email@company.com"
+export JIRA_TOKEN="your-api-token"
+export CI_WEBHOOK_URL="https://your-ci-system.com/hooks/cline"
+```
+
+### Testing Your Hooks
+
+Test hooks manually by simulating their input:
+
+```bash
+# Test a PreToolUse hook
+echo '{
+  "clineVersion": "1.0.0",
+  "hookName": "PreToolUse",
+  "timestamp": "2024-01-01T12:00:00Z",
+  "taskId": "test",
+  "workspaceRoots": ["/path/to/workspace"],
+  "userId": "test-user",
+  "preToolUse": {
+    "toolName": "write_to_file",
+    "parameters": {
+      "path": "test.js",
+      "content": "console.log(\"test\");"
+    }
+  }
+}' | .clinerules/hooks/PreToolUse
+```
+
+These examples provide a solid foundation for implementing hooks in your development workflow. Customize them based on your specific needs, tools, and integrations.
@@ -1,26 +1,25 @@
 ---
 title: "Jupyter Notebooks"
-sidebarTitle: "Jupyter Notebooks"
 description: "AI-assisted editing of Jupyter notebooks with cell-level context awareness"
 ---

+# Jupyter Notebooks
+
 Cline provides comprehensive support for Jupyter notebooks (`.ipynb` files), enabling AI-assisted editing with full cell-level context awareness. This feature was developed in collaboration with Amazon to bring AI coding assistance to data science workflows.

-## Getting Started
+## Getting started

 Jupyter notebook support is a built-in feature of Cline. To use it, you just need to have the Jupyter notebook extension enabled in VS Code. Once you open any `.ipynb` file, you'll see AI-assisted buttons in your notebook interface.

-## How to Use
+## How to use

 ### Generate Cell

-Click the sparkle icon in the notebook toolbar to generate new cells with AI assistance.
+Click the sparkle icon (✨) in the notebook toolbar to generate new cells with AI assistance.

-<Frame>
-  <img src="/assets/jupyter-generate-cell.gif" alt="Generating a new Jupyter cell with AI assistance" />
-</Frame>
+![Generate Cell demo](../assets/jupyter-generate-cell.gif)

-The AI receives context from surrounding cells, so it understands the variables and imports already in scope. This means you can reference existing DataFrames, functions, and other objects without re-explaining them.
+**How it works:** The AI receives context from surrounding cells, so it understands the variables and imports already in scope. This means you can reference existing DataFrames, functions, and other objects without re-explaining them.

 **Example prompt:** "Create a visualization showing the correlation matrix of numeric columns with a heatmap"

@@ -36,15 +35,13 @@ This is useful for:
 - Onboarding to a teammate's analysis
 - Understanding complex transformations

-Cline extracts the full cell context, including outputs, so explanations can reference actual results like column names, row counts, and computed values.
+**How it works:** Cline extracts the full cell context, including outputs, so explanations can reference actual results like column names, row counts, and computed values.

 ### Improve Cell

 Click the Improve button in any cell's title bar to enhance existing cells with AI suggestions.

-<Frame>
-  <img src="/assets/jupyter-explain-improve-cell.gif" alt="Explaining and improving a Jupyter cell with AI" />
-</Frame>
+![Explain and Improve Cell demo](../assets/jupyter-explain-improve-cell.gif)

 Use this to:

@@ -53,9 +50,9 @@ Use this to:
 - Refactor for clarity
 - Convert loops to vectorized operations

-Cline suggests improvements while preserving the cell's position and metadata in the notebook structure. The AI explains what was changed and why.
+**How it works:** Cline suggests improvements while preserving the cell's position and metadata in the notebook structure. The AI explains what was changed and why.

-## How Cell Context Works
+## How cell context works

 Unlike traditional file editing, Jupyter notebooks are JSON documents containing arrays of cells. Each cell has its own type, source content, metadata, execution count, and outputs.

@@ -69,7 +66,7 @@ When you use a Jupyter command, Cline extracts structured context that includes:

 This structured representation allows the AI to understand not just the code, but its context within the notebook and its actual output.

-### JSON Structure Preservation
+### JSON structure preservation

 Cline is designed to work carefully with the cell JSON structure, aiming to:

@@ -80,7 +77,7 @@ Cline is designed to work carefully with the cell JSON structure, aiming to:

 The AI is specifically prompted to preserve notebook structure, though you should always review changes to ensure your notebook format remains correct.

-## Keyboard Shortcuts
+## Keyboard shortcuts

 You can bind any of these commands to keyboard shortcuts for faster access:

@@ -88,7 +85,7 @@ You can bind any of these commands to keyboard shortcuts for faster access:
 2. Search for `cline.jupyterGenerateCell`, `cline.jupyterExplainCell`, or `cline.jupyterImproveCell`
 3. Assign your preferred key combinations

-## Tips for Best Results
+## Tips for best results

 **For Generate Cell:**
 - Be specific about what you want the cell to do
@@ -111,5 +108,5 @@ You can bind any of these commands to keyboard shortcuts for faster access:

 ## Related

- [All Cline Tools](/tools-reference/all-cline-tools) - Overview of all Cline tools
- [Model Selection Guide](/core-features/model-selection-guide) - Choosing the right model for your workflow
+- [Cline Tools Guide](/exploring-clines-tools/cline-tools-guide) -- Overview of all Cline commands
+- [Model Selection Guide](/core-features/model-selection-guide) -- Choosing the right model for your workflow
@@ -1,222 +0,0 @@
---
-title: "Memory Bank"
-sidebarTitle: "Memory Bank"
-description: "A structured documentation system that helps Cline maintain context across sessions."
---
-
-Memory Bank is a documentation methodology that transforms Cline from a stateless assistant into a persistent development partner. Through structured markdown files, Cline can "remember" your project details across sessions.
-
-## Quick Setup
-
-1. Copy the [custom instructions below](#memory-bank-custom-instructions)
-2. Add to custom instructions or a [`.clinerules` file](/customization/cline-rules)
-3. Ask Cline to "initialize memory bank"
-
-## How It Works
-
-Memory Bank files are regular markdown files in your project that both you and Cline can access. They're organized hierarchically to build a complete picture of your project:
-
-```text
-memory-bank/
-├── projectbrief.md      # Foundation document
-├── productContext.md    # Why this project exists
-├── activeContext.md     # Current work focus
-├── systemPatterns.md    # Architecture & patterns
-├── techContext.md       # Tech stack & setup
-└── progress.md          # Status & milestones
-```
-
-<Frame>
-	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(16).png" alt="Memory Bank file hierarchy showing projectbrief.md at the top flowing into productContext, systemPatterns, and techContext, which feed into activeContext and progress" />
-</Frame>
-
-## Core Files
-
-| File | Purpose |
-|------|---------|
-| `projectbrief.md` | Foundation document with core requirements and goals |
-| `productContext.md` | Why the project exists, problems it solves, UX goals |
-| `activeContext.md` | Current focus, recent changes, next steps (updates most frequently) |
-| `systemPatterns.md` | Architecture, design patterns, component relationships |
-| `techContext.md` | Tech stack, setup, constraints, dependencies |
-| `progress.md` | What works, what's left, known issues |
-
-## Key Commands
-
- **"follow your custom instructions"** - Tells Cline to read Memory Bank and continue where you left off
- **"initialize memory bank"** - Creates the initial structure for a new project
- **"update memory bank"** - Triggers a full documentation review and update
-
-These work alongside Cline's built-in [slash commands](/core-workflows/using-commands). In particular, [`/newtask`](/core-workflows/using-commands#newtask) and [`/smol`](/core-workflows/using-commands#smol) help you manage context windows without losing progress.
-
-## Working with Plan & Act Modes
-
-Memory Bank pairs naturally with [Plan & Act mode](/core-workflows/plan-and-act):
-
- **Plan mode**: Start here when resuming a project. Ask Cline to read the Memory Bank, review the current state, and discuss strategy before making changes.
- **Act mode**: Switch to Act mode once you have a plan. Cline retains everything from the planning session and can implement changes.
-
-For complex features, use [`/deep-planning`](/core-workflows/using-commands#deep-planning) to have Cline investigate your codebase and create a detailed implementation plan. The Memory Bank gives Cline the project context it needs to plan effectively.
-
-## Managing Context Windows
-
-Every AI model has a [context window](/core-workflows/task-management#context-window) that limits how much information it can process at once. As you work, this window fills with conversation history, file contents, and tool results. Memory Bank helps you preserve important knowledge when you need to free up space.
-
-### Manual approach
-
-When your context window fills up:
-
-1. Ask Cline to "update memory bank" to document the current state
-2. Start a new conversation
-3. Ask Cline to "follow your custom instructions"
-
-This preserves important context in your Memory Bank files before the window clears, letting you continue seamlessly in a fresh conversation.
-
-### Using slash commands
-
-Cline's built-in commands offer more targeted options:
-
- **[`/smol`](/core-workflows/using-commands#smol)** compresses your conversation history while keeping you in the same task. Use this when you want to free up space without starting over.
- **[`/newtask`](/core-workflows/using-commands#newtask)** distills key decisions, file changes, and progress into a fresh task with a clean context window. This is like a developer handoff that preserves what matters.
-
-### Automatic context management
-
-Enable [Auto-Compact](/features/auto-compact) to let Cline automatically compress context as you work. This reduces how often you need to manually manage the context window, though you should still update the Memory Bank after significant milestones.
-
-<Frame>
-	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(18).png" alt="Context window progress bar showing usage approaching the limit" />
-</Frame>
-
-## Memory Bank and Checkpoints
-
-Memory Bank and [Checkpoints](/core-workflows/checkpoints) solve different sides of the same problem:
-
- **Memory Bank** preserves *knowledge*: project context, decisions, patterns, and progress across sessions.
- **Checkpoints** preserve *code state*: file snapshots you can restore if something goes wrong.
-
-Together, they let you experiment freely. Checkpoints protect your code, and Memory Bank protects your understanding of the project. If you need to roll back code changes, your Memory Bank still has the context of what you were trying to do and why.
-
-## Reducing Your Context Footprint
-
-Memory Bank works best when your starting context is lean. If Cline loads your entire project into context, including dependencies, build artifacts, and generated files, you burn through tokens before the real work starts.
-
-**Add a [`.clineignore`](/customization/clineignore) file.** This is the single biggest improvement most users can make. It tells Cline which files to skip when scanning your project. Adding one can drop your starting context from 200k+ tokens to under 50k, which means faster responses, lower costs, and the ability to use smaller models effectively.
-
-**Keep Memory Bank files concise.** Each file adds to your context when Cline reads it at the start of a session. Keep `projectbrief.md` to one page, `activeContext.md` to current state only (not a running log), and `progress.md` to a summary rather than a detailed changelog. If a file grows beyond a page or two, split the detail into a separate doc and link to it. Cline can read linked files on demand.
-
-**Use [Cline Rules](/customization/cline-rules) strategically.** Rules load into every request. Use [conditional rules](/customization/cline-rules#conditional-rules) to activate rules only when working with matching files, so frontend rules don't load when you're editing backend code.
-
-## Best Practices
-
- Start with a basic project brief and let structure evolve
- Let Cline help create the initial structure
- `activeContext.md` changes most frequently; update it after each session
- `progress.md` tracks milestones; review it when resuming work
- Update after significant milestones or direction changes
- Use [Cline Rules](/customization/cline-rules) to store the Memory Bank instructions per-project
- Add a [`.clineignore`](/customization/clineignore) early to keep your starting context small
-
---
-
-## Memory Bank Custom Instructions
-
-Copy this into custom instructions or a `.clinerules` file:
-
-```markdown
-# Cline's Memory Bank
-
-I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
-
-## Memory Bank Structure
-
-The Memory Bank consists of core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
-
-### Core Files (Required)
-1. `projectbrief.md`
-   - Foundation document that shapes all other files
-   - Created at project start if it doesn't exist
-   - Defines core requirements and goals
-   - Source of truth for project scope
-
-2. `productContext.md`
-   - Why this project exists
-   - Problems it solves
-   - How it should work
-   - User experience goals
-
-3. `activeContext.md`
-   - Current work focus
-   - Recent changes
-   - Next steps
-   - Active decisions and considerations
-   - Important patterns and preferences
-   - Learnings and project insights
-
-4. `systemPatterns.md`
-   - System architecture
-   - Key technical decisions
-   - Design patterns in use
-   - Component relationships
-   - Critical implementation paths
-
-5. `techContext.md`
-   - Technologies used
-   - Development setup
-   - Technical constraints
-   - Dependencies
-   - Tool usage patterns
-
-6. `progress.md`
-   - What works
-   - What's left to build
-   - Current status
-   - Known issues
-   - Evolution of project decisions
-
-### Additional Context
-Create additional files/folders within memory-bank/ when they help organize:
- Complex feature documentation
- Integration specifications
- API documentation
- Testing strategies
- Deployment procedures
-
-## Documentation Updates
-
-Memory Bank updates occur when:
-1. Discovering new project patterns
-2. After implementing significant changes
-3. When user requests with **update memory bank** (MUST review ALL files)
-4. When context needs clarification
-
-REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
-```
-
-## FAQ
-
-**Custom instructions or .clinerules?**
-Either works. Custom instructions apply globally across all projects. A [`.clinerules` file](/customization/cline-rules) is project-specific and stored in your repo, which makes it easy to share with collaborators. You can also use [conditional rules](/customization/cline-rules#conditional-rules) to activate Memory Bank instructions only when working with `memory-bank/` files.
-
-**How often should I update?**
-After significant milestones or direction changes. For active development, every few sessions. You can also let [Auto-Compact](/features/auto-compact) handle routine context management and reserve manual "update memory bank" for important checkpoints.
-
-**How does Memory Bank relate to checkpoints?**
-[Checkpoints](/core-workflows/checkpoints) save your code state (file snapshots). Memory Bank saves your project knowledge (context, decisions, progress). They complement each other: checkpoints let you roll back code, Memory Bank lets you pick up where you left off intellectually.
-
-**How does Memory Bank relate to context window limitations?**
-Memory Bank stores important information in structured files that Cline can load efficiently at the start of each session. This prevents context bloat while keeping critical information available. For more on how context windows work, see [Task Management](/core-workflows/task-management#context-window).
-
-**Does this work with other AI tools?**
-Yes. Memory Bank is a documentation methodology that works with any AI that can read docs. Commands may differ but the approach works across tools.
-
-**Different from README files?**
-Memory Bank provides structured, comprehensive documentation designed for AI context management, going beyond what a single README covers. It includes files for active context and progress tracking that change frequently, unlike a typical README.
-
-For more information, see the [Memory Bank blog post](https://cline.bot/blog/memory-bank-how-to-make-cline-an-ai-agent-that-never-forgets).
-
-## Related
-
- [Plan & Act Mode](/core-workflows/plan-and-act) - Separate thinking from doing with structured planning sessions
- [Checkpoints](/core-workflows/checkpoints) - Roll back code changes while keeping your conversation context
- [Cline Rules](/customization/cline-rules) - Define persistent instructions including Memory Bank setup
- [Task Management](/core-workflows/task-management) - Understand tasks, context windows, and when to start fresh
@@ -19,7 +19,7 @@ Cline works with VSCode's multi-root workspaces, letting you manage multiple pro
 <Warning>
 Multi-root workspaces have two limitations:
 - **Cline rules** only work in the primary workspace folder
- **[Checkpoints](/core-workflows/checkpoints)** are disabled (restored when you return to a single folder)
+- **Checkpoints** are disabled (restored when you return to a single folder)

 See [Current Limitations](#current-limitations) for details.
 </Warning>
@@ -38,7 +38,7 @@ Cline can complete tasks that span multiple projects or repositories:
 - **Documentation**: Generate docs that reference code from multiple repositories

 **Example prompt:**
-```text
+```
 Update the User type in the contracts repo, then update both the frontend 
 and backend to use the new fields. Make sure the API validates the new 
 required field.
@@ -49,27 +49,19 @@ required field.

 **Monorepo**: One Git repository containing multiple projects or packages. All code shares the same version history.

-<Files>
-  <Folder name="my-company" defaultOpen>
-    <Folder name=".git" />
-    <Folder name="packages" defaultOpen>
-      <Folder name="web" icon="react">
-        <File name="..." />
-      </Folder>
-      <Folder name="api" icon="node-js">
-        <File name="..." />
-      </Folder>
-      <Folder name="shared">
-        <File name="..." />
-      </Folder>
-    </Folder>
-    <File name="package.json" />
-  </Folder>
-</Files>
+```
+my-company/                    # Single Git repo
+├── .git/
+├── packages/
+│   ├── web/                   # React frontend
+│   ├── api/                   # Node.js backend
+│   └── shared/                # Common utilities
+└── package.json
+```

 **Multiple Repositories**: Separate Git repositories, each with their own history, opened together in one VSCode workspace.

-```text
+```
 ~/projects/
 ├── fullstack.code-workspace   # Workspace config file
 ├── frontend/                  # git@github.com:acme/frontend.git
@@ -111,7 +103,7 @@ For each workspace folder, Cline detects:
 This means Cline understands that your frontend and backend might be at different commits, on different branches, or even use different version control systems.

 <Note>
-While Cline detects VCS information for all workspace folders, certain features only use the **primary workspace** (the first folder): [Cline rules](/customization/cline-rules), [workflows](/customization/workflows), and [Git-related features](/core-workflows/working-with-files) like `@git` mentions.
+While Cline detects VCS information for all workspace folders, certain features only use the **primary workspace** (the first folder): [Cline rules](/features/cline-rules), [workflows](/features/slash-commands/workflows/index), and [Git-related features](/features/at-mentions/git-mentions) like `@git` mentions.
 </Note>

 ## Referencing Files Across Workspaces
@@ -120,15 +112,15 @@ While Cline detects VCS information for all workspace folders, certain features

 Cline understands natural references to your workspaces:

-```text
+```
 "Read the package.json in the frontend folder"
 ```

-```text
+```
 "Compare the user model in backend with the TypeScript types in contracts"
 ```

-```text
+```
 "Search for TODO comments across all workspaces"
 ```

@@ -159,7 +151,7 @@ If two folders have the same name, append numbers or use the workspace file to g

 ### Monorepo Development

-```text
+```
 ~/projects/my-app/
 ├── my-app.code-workspace      # Workspace config file
 ├── web/          (React frontend)
@@ -174,7 +166,7 @@ All folders share one Git history. Changes across packages are atomic.

 ### Microservices with Separate Repos

-```text
+```
 ~/projects/services/
 ├── services.code-workspace    # Workspace config file
 ├── user-service/       (git: github.com/acme/user-service)
@@ -189,7 +181,7 @@ Each service has its own repository. Cline can update the proto definitions and

 ### Full-Stack with Shared Contracts

-```text
+```
 ~/projects/fullstack/
 ├── fullstack.code-workspace   # Workspace config file
 ├── client/         (git: github.com/acme/web-client)
@@ -201,7 +193,7 @@ The types repository defines interfaces used by both client and server. When you

 ### Hybrid Setup

-```text
+```
 ~/projects/project/
 ├── project.code-workspace     # Workspace config file
 ├── main-app/       (git: github.com/acme/main-app)
@@ -217,13 +209,13 @@ Two features have limitations in multi-root workspace mode:

 ### Cline Rules

-[Cline rules](/customization/cline-rules) (`.clinerules/` directory) only work in the **primary workspace** (the first folder in your workspace). Rules in other workspace folders are ignored.
+[Cline rules](/features/cline-rules) (`.clinerules/` directory) only work in the **primary workspace** (the first folder in your workspace). Rules in other workspace folders are ignored.

 **Workaround:** Place shared rules in the primary workspace, or use global rules (`~/Documents/Cline/Rules/`) which apply everywhere.

 ### Checkpoints

-[Checkpoints](/core-workflows/checkpoints) are disabled in multi-root workspace mode. Cline displays a warning when this happens.
+[Checkpoints](/features/checkpoints) are disabled in multi-root workspace mode. Cline displays a warning when this happens.

 **Why:** Checkpoints use a shadow Git repository to track changes. With multiple repositories, coordinating checkpoints across independent Git histories adds complexity that isn't yet supported.

@@ -250,7 +242,7 @@ Both limitations are restored when you return to a single-folder workspace.
 ### Working with Large Workspaces

 - Break large tasks into workspace-specific operations when possible
- Use [Plan mode](/core-workflows/plan-and-act) to let Cline understand structure first
+- Use [Plan mode](/features/plan-and-act) to let Cline understand structure first
 - Add a `.clineignore` file to reduce noise, speed up scanning, and keep Cline focused on source code:

 ```text
@@ -265,4 +257,4 @@ Both limitations are restored when you return to a single-folder workspace.
 **/.git/
 ```

-For more patterns and gotchas, see the [.clineignore File Guide](/customization/clineignore).
+For more patterns and gotchas, see the [.clineignore File Guide](/prompting/prompt-engineering-guide#clineignore-file-guide).
@@ -0,0 +1,163 @@
+---
+title: "Plan & Act"
+sidebarTitle: "Plan & Act"
+---
+
+Plan & Act modes represent Cline's approach to structured AI development, emphasizing thoughtful planning before implementation. This dual-mode system helps developers create more maintainable, accurate code while reducing iteration time.
+
+<Frame>
+	<iframe
+		style={{ width: "100%", aspectRatio: "16/9" }}
+		src="https://www.youtube.com/embed/b7o6URFPp64"
+		title="YouTube video player"
+		frameBorder="0"
+		allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
+		allowFullScreen></iframe>
+</Frame>
+
+#### Plan Mode: Think First
+
+Plan mode is where you and Cline figure out what you're trying to build and how you'll build it. In this mode, Cline:
+
+-   Can read your entire codebase to understand the context
+-   Won't make any changes to your files
+-   Focuses on understanding requirements and creating a strategy
+-   Helps identify potential issues before you write a single line of code
+
+<Tip>
+Try [Dictation](/features/dictation) in Plan mode - instead of typing out complex requirements, you can speak naturally and share your complete thought process. It's perfect for rapid back-and-forth planning discussions.
+</Tip>
+
+#### Act Mode: Build It
+
+Once you've got a plan, you switch to Act mode. Now Cline:
+
+-   Has all the building capabilities at its disposal
+-   Can make changes to your codebase
+-   Still remembers everything from your planning session
+-   Executes the strategy you worked out together
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(5).png" alt="Act mode capabilities" />
+</Frame>
+
+### Workflow Guide
+
+When I'm working on a new feature or fixing a complex bug, here's what works for me:
+
+1. I start in Plan mode and tell Cline what I want to build
+2. Cline helps me explore the codebase, looking at relevant files
+3. Together we figure out the best approach, considering edge cases and potential issues
+4. When I'm confident in our plan, I switch to Act mode
+5. Cline implements the solution based on our planning
+
+#### 1. Start with Plan Mode
+
+Begin every significant development task in Plan mode:
+
+In this mode:
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(5)%20(1).png" alt="Plan mode workflow" />
+</Frame>
+
+-   Share your requirements
+-   Let Cline analyze relevant files
+-   Engage in dialogue to clarify objectives
+-   Develop implementation strategy
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(2)%20(1)%20(1)%20(1).png"
+		alt="Planning phase"
+	/>
+</Frame>
+
+#### 2. Switch to Act Mode
+
+Once you have a clear plan, switch to Act mode:
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/switching-to-act.gif" alt="Switching to Act mode" />
+</Frame>
+
+Act mode allows Cline to:
+
+-   Execute against the agreed plan
+-   Make changes to your codebase
+-   Maintain context from planning phase
+
+#### 3. Iterate as Needed
+
+Complex projects often require multiple plan-act cycles:
+
+-   Return to Plan mode when encountering unexpected complexity
+-   Use Act mode for implementing solutions
+-   Maintain development momentum while ensuring quality
+
+### Best Practices
+
+#### Planning Phase
+
+1. Be comprehensive with requirements
+2. Share relevant context upfront
+3. Point Cline to relevant files if he hasn't read them
+4. Validate approach before implementation
+
+#### Implementation Phase
+
+1. Follow the established plan
+2. Monitor progress against objectives
+3. Track changes and their impact
+4. Document significant decisions
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(3)%20(1).png"
+		alt="Implementation best practices"
+	/>
+</Frame>
+
+### Power User Tips
+
+#### Enhancing Planning
+
+-   Use Plan mode to explore edge cases before implementation
+-   Switch back to Plan when encountering unexpected complexity
+-   Leverage [file reading](/features/at-mentions/file-mentions) to validate assumptions early
+-   Have Cline write markdown files of the plan for future reference
+
+### Common Patterns
+
+#### When to Use Each Mode
+
+I've found Plan mode works best when:
+
+-   Starting something new where the approach isn't obvious
+-   Debugging a tricky issue where I'm not sure what's wrong
+-   Making architectural decisions that will affect multiple parts of the codebase
+-   Trying to understand a complex workflow or feature
+
+And Act mode is perfect for:
+
+-   Implementing a solution we've already planned out
+-   Making routine changes where the approach is clear
+-   Following established patterns in the codebase
+-   Running tests and making minor adjustments
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(6).png" alt="Mode usage patterns" />
+</Frame>
+
+### Contributing
+
+Share your experiences and improvements:
+
+-   Join our [Discord community](https://discord.gg/cline)
+-   Participate in discussions
+-   Submit feature requests
+-   Report issues
+
+---
+
+Remember: The time invested in planning pays dividends in implementation quality and maintenance efficiency.
--- a/Show More
+++ b/Show More