Cline rules

1---
2description: Defines Cline's extension architecture, components, data flow, and development guidelines.
3author: https://github.com/cline
4version: 1.0
5category: "Cline Core"
6tags: ["architecture", "development-guide", "extension", "vscode", "core-behavior"]
7globs: ["*"]
8---
9# Cline Extension Architecture & Development Guide
10 
11## Project Overview
12 
13Cline is a VSCode extension that provides AI assistance through a combination of a core extension backend and a React-based webview frontend. The extension is built with TypeScript and follows a modular architecture pattern.
14 
15## Architecture Overview
16 
17```mermaid
18graph TB
19    subgraph VSCodeExtensionHost[VSCode Extension Host]
20        subgraph CoreExtension[Core Extension]
21            ExtensionEntry[Extension Entry<br/>src/extension.ts]
22            WebviewProvider[WebviewProvider<br/>src/core/webview/index.ts]
23            Controller[Controller<br/>src/core/controller/index.ts]
24            Task[Task<br/>src/core/task/index.ts]
25            GlobalState[VSCode Global State]
26            SecretsStorage[VSCode Secrets Storage]
27            McpHub[McpHub<br/>src/services/mcp/McpHub.ts]
28        end
29 
30        subgraph WebviewUI[Webview UI]
31            WebviewApp[React App<br/>webview-ui/src/App.tsx]
32            ExtStateContext[ExtensionStateContext<br/>webview-ui/src/context/ExtensionStateContext.tsx]
33            ReactComponents[React Components]
34        end
35 
36        subgraph Storage
37            TaskStorage[Task Storage<br/>Per-Task Files & History]
38            CheckpointSystem[Git-based Checkpoints]
39        end
40 
41        subgraph apiProviders[API Providers]
42            AnthropicAPI[Anthropic]
43            OpenRouterAPI[OpenRouter]
44            BedrockAPI[AWS Bedrock]
45            OtherAPIs[Other Providers]
46        end
47 
48        subgraph MCPServers[MCP Servers]
49            ExternalMcpServers[External MCP Servers]
50        end
51    end
52 
53    %% Core Extension Data Flow
54    ExtensionEntry --> WebviewProvider
55    WebviewProvider --> Controller
56    Controller --> Task
57    Controller --> McpHub
58    Task --> GlobalState
59    Task --> SecretsStorage
60    Task --> TaskStorage
61    Task --> CheckpointSystem
62    Task --> |API Requests| apiProviders
63    McpHub --> |Connects to| ExternalMcpServers
64    Task --> |Uses| McpHub
65 
66    %% Webview Data Flow
67    WebviewApp --> ExtStateContext
68    ExtStateContext --> ReactComponents
69 
70    %% Bidirectional Communication
71    WebviewProvider <-->|postMessage| ExtStateContext
72 
73    style GlobalState fill:#f9f,stroke:#333,stroke-width:2px
74    style SecretsStorage fill:#f9f,stroke:#333,stroke-width:2px
75    style ExtStateContext fill:#bbf,stroke:#333,stroke-width:2px
76    style WebviewProvider fill:#bfb,stroke:#333,stroke-width:2px
77    style McpHub fill:#bfb,stroke:#333,stroke-width:2px
78    style apiProviders fill:#fdb,stroke:#333,stroke-width:2px
79```
80 
81## Definitions 
82 
83- **Core Extension**: Anything inside the src folder, organized into modular components
84- **Core Extension State**: Managed by the Controller class in src/core/controller/index.ts, which serves as the single source of truth for the extension's state. It manages multiple types of persistent storage (global state, workspace state, and secrets), handles state distribution to both the core extension and webview components, and coordinates state across multiple extension instances. This includes managing API configurations, task history, settings, and MCP configurations.
85- **Webview**: Anything inside the webview-ui. All the react or view's seen by the user and user interaction components
86- **Webview State**: Managed by ExtensionStateContext in webview-ui/src/context/ExtensionStateContext.tsx, which provides React components with access to the extension's state through a context provider pattern. It maintains local state for UI components, handles real-time updates through message events, manages partial message updates, and provides methods for state modifications. The context includes extension version, messages, task history, theme, API configurations, MCP servers, marketplace catalog, and workspace file paths. It synchronizes with the core extension through VSCode's message passing system and provides type-safe access to state through a custom hook (useExtensionState).
87 
88### Core Extension Architecture
89 
90The core extension follows a clear hierarchical structure:
91 
921. **WebviewProvider** (src/core/webview/index.ts): Manages the webview lifecycle and communication
932. **Controller** (src/core/controller/index.ts): Handles webview messages and task management
943. **Task** (src/core/task/index.ts): Executes API requests and tool operations
95 
96This architecture provides clear separation of concerns:
97- WebviewProvider focuses on VSCode webview integration
98- Controller manages state and coordinates tasks
99- Task handles the execution of AI requests and tool operations
100 
101### WebviewProvider Implementation
102 
103The WebviewProvider class in `src/core/webview/index.ts` is responsible for:
104 
105- Managing multiple active instances through a static set (`activeInstances`)
106- Handling webview lifecycle events (creation, visibility changes, disposal)
107- Implementing HTML content generation with proper CSP headers
108- Supporting Hot Module Replacement (HMR) for development
109- Setting up message listeners between the webview and extension
110 
111The WebviewProvider maintains a reference to the Controller and delegates message handling to it. It also handles the creation of both sidebar and tab panel webviews, allowing Cline to be used in different contexts within VSCode.
112 
113### Core Extension State
114 
115The `Controller` class manages multiple types of persistent storage:
116 
117- **Global State:** Stored across all VSCode instances. Used for settings and data that should persist globally.
118- **Workspace State:** Specific to the current workspace. Used for task-specific data and settings.
119- **Secrets:** Secure storage for sensitive information like API keys.
120 
121The `Controller` handles the distribution of state to both the core extension and webview components. It also coordinates state across multiple extension instances, ensuring consistency.
122 
123State synchronization between instances is handled through:
124- File-based storage for task history and conversation data
125- VSCode's global state API for settings and configuration
126- Secrets storage for sensitive information
127- Event listeners for file changes and configuration updates
128 
129The Controller implements methods for:
130- Saving and loading task state
131- Managing API configurations
132- Handling user authentication
133- Coordinating MCP server connections
134- Managing task history and checkpoints
135 
136### Webview State
137 
138The `ExtensionStateContext` in `webview-ui/src/context/ExtensionStateContext.tsx` provides React components with access to the extension's state. It uses a context provider pattern and maintains local state for UI components. The context includes:
139 
140- Extension version
141- Messages
142- Task history
143- Theme
144- API configurations
145- MCP servers
146- Marketplace catalog
147- Workspace file paths
148 
149It synchronizes with the core extension through VSCode's message passing system and provides type-safe access to the state via a custom hook (`useExtensionState`).
150 
151The ExtensionStateContext handles:
152- Real-time updates through message events
153- Partial message updates for streaming content
154- State modifications through setter methods
155- Type-safe access to state through a custom hook
156 
157## API Provider System
158 
159Cline supports multiple AI providers through a modular API provider system. Each provider is implemented as a separate module in the `src/api/providers/` directory and follows a common interface.
160 
161### API Provider Architecture
162 
163The API system consists of:
164 
1651. **API Handlers**: Provider-specific implementations in `src/api/providers/`
1662. **API Transformers**: Stream transformation utilities in `src/api/transform/`
1673. **API Configuration**: User settings for API keys and endpoints
1684. **API Factory**: Builder function to create the appropriate handler
169 
170Key providers include:
171- **Anthropic**: Direct integration with Claude models
172- **OpenRouter**: Meta-provider supporting multiple model providers
173- **AWS Bedrock**: Integration with Amazon's AI services
174- **Gemini**: Google's AI models
175- **Ollama**: Local model hosting
176- **LM Studio**: Local model hosting
177- **VSCode LM**: VSCode's built-in language models
178 
179### API Configuration Management
180 
181API configurations are stored securely:
182- API keys are stored in VSCode's secrets storage
183- Model selections and non-sensitive settings are stored in global state
184- The Controller manages switching between providers and updating configurations
185 
186The system supports:
187- Secure storage of API keys
188- Model selection and configuration
189- Automatic retry and error handling
190- Token usage tracking and cost calculation
191- Context window management
192 
193### Plan/Act Mode API Configuration
194 
195Cline supports separate model configurations for Plan and Act modes:
196- Different models can be used for planning vs. execution
197- The system preserves model selections when switching modes
198- The Controller handles the transition between modes and updates the API configuration accordingly
199 
200## Task Execution System
201 
202The Task class is responsible for executing AI requests and tool operations. Each task runs in its own instance of the Task class, ensuring isolation and proper state management.
203 
204### Task Execution Loop
205 
206The core task execution loop follows this pattern:
207 
208```typescript
209class Task {
210  async initiateTaskLoop(userContent: UserContent, isNewTask: boolean) {
211    while (!this.abort) {
212      // 1. Make API request and stream response
213      const stream = this.attemptApiRequest()
214      
215      // 2. Parse and present content blocks
216      for await (const chunk of stream) {
217        switch (chunk.type) {
218          case "text":
219            // Parse into content blocks
220            this.assistantMessageContent = parseAssistantMessage(chunk.text)
221            // Present blocks to user
222            await this.presentAssistantMessage()
223            break
224        }
225      }
226      
227      // 3. Wait for tool execution to complete
228      await pWaitFor(() => this.userMessageContentReady)
229      
230      // 4. Continue loop with tool result
231      const recDidEndLoop = await this.recursivelyMakeClineRequests(
232        this.userMessageContent
233      )
234    }
235  }
236}
237```
238 
239### Message Streaming System
240 
241The streaming system handles real-time updates and partial content:
242 
243```typescript
244class Task {
245  async presentAssistantMessage() {
246    // Handle streaming locks to prevent race conditions
247    if (this.presentAssistantMessageLocked) {
248      this.presentAssistantMessageHasPendingUpdates = true
249      return
250    }
251    this.presentAssistantMessageLocked = true
252 
253    // Present current content block
254    const block = this.assistantMessageContent[this.currentStreamingContentIndex]
255    
256    // Handle different types of content
257    switch (block.type) {
258      case "text":
259        await this.say("text", content, undefined, block.partial)
260        break
261      case "tool_use":
262        // Handle tool execution
263        break
264    }
265 
266    // Move to next block if complete
267    if (!block.partial) {
268      this.currentStreamingContentIndex++
269    }
270  }
271}
272```
273 
274### Tool Execution Flow
275 
276Tools follow a strict execution pattern:
277 
278```typescript
279class Task {
280  async executeToolWithApproval(block: ToolBlock) {
281    // 1. Check auto-approval settings
282    if (this.shouldAutoApproveTool(block.name)) {
283      await this.say("tool", message)
284      this.consecutiveAutoApprovedRequestsCount++
285    } else {
286      // 2. Request user approval
287      const didApprove = await askApproval("tool", message)
288      if (!didApprove) {
289        this.didRejectTool = true
290        return
291      }
292    }
293 
294    // 3. Execute tool
295    const result = await this.executeTool(block)
296 
297    // 4. Save checkpoint
298    await this.saveCheckpoint()
299 
300    // 5. Return result to API
301    return result
302  }
303}
304```
305 
306### Error Handling & Recovery
307 
308The system includes robust error handling:
309 
310```typescript
311class Task {
312  async handleError(action: string, error: Error) {
313    // 1. Check if task was abandoned
314    if (this.abandoned) return
315    
316    // 2. Format error message
317    const errorString = `Error ${action}: ${error.message}`
318    
319    // 3. Present error to user
320    await this.say("error", errorString)
321    
322    // 4. Add error to tool results
323    pushToolResult(formatResponse.toolError(errorString))
324    
325    // 5. Cleanup resources
326    await this.diffViewProvider.revertChanges()
327    await this.browserSession.closeBrowser()
328  }
329}
330```
331 
332### API Request & Token Management
333 
334The Task class handles API requests with built-in retry, streaming, and token management:
335 
336```typescript
337class Task {
338  async *attemptApiRequest(previousApiReqIndex: number): ApiStream {
339    // 1. Wait for MCP servers to connect
340    await pWaitFor(() => this.controllerRef.deref()?.mcpHub?.isConnecting !== true)
341 
342    // 2. Manage context window
343    const previousRequest = this.clineMessages[previousApiReqIndex]
344    if (previousRequest?.text) {
345      const { tokensIn, tokensOut } = JSON.parse(previousRequest.text || "{}")
346      const totalTokens = (tokensIn || 0) + (tokensOut || 0)
347      
348      // Truncate conversation if approaching context limit
349      if (totalTokens >= maxAllowedSize) {
350        this.conversationHistoryDeletedRange = this.contextManager.getNextTruncationRange(
351          this.apiConversationHistory,
352          this.conversationHistoryDeletedRange,
353          totalTokens / 2 > maxAllowedSize ? "quarter" : "half"
354        )
355      }
356    }
357 
358    // 3. Handle streaming with automatic retry
359    try {
360      this.isWaitingForFirstChunk = true
361      const firstChunk = await iterator.next()
362      yield firstChunk.value
363      this.isWaitingForFirstChunk = false
364      
365      // Stream remaining chunks
366      yield* iterator
367    } catch (error) {
368      // 4. Error handling with retry
369      if (isOpenRouter && !this.didAutomaticallyRetryFailedApiRequest) {
370        await setTimeoutPromise(1000)
371        this.didAutomaticallyRetryFailedApiRequest = true
372        yield* this.attemptApiRequest(previousApiReqIndex)
373        return
374      }
375      
376      // 5. Ask user to retry if automatic retry failed
377      const { response } = await this.ask(
378        "api_req_failed",
379        this.formatErrorWithStatusCode(error)
380      )
381      if (response === "yesButtonClicked") {
382        await this.say("api_req_retried")
383        yield* this.attemptApiRequest(previousApiReqIndex)
384        return
385      }
386    }
387  }
388}
389```
390 
391Key features:
392 
3931. **Context Window Management**
394   - Tracks token usage across requests
395   - Automatically truncates conversation when needed
396   - Preserves important context while freeing space
397   - Handles different model context sizes
398 
3992. **Streaming Architecture**
400   - Real-time chunk processing
401   - Partial content handling
402   - Race condition prevention
403   - Error recovery during streaming
404 
4053. **Error Handling**
406   - Automatic retry for transient failures
407   - User-prompted retry for persistent issues
408   - Detailed error reporting
409   - State cleanup on failure
410 
4114. **Token Tracking**
412   - Per-request token counting
413   - Cumulative usage tracking
414   - Cost calculation
415   - Cache hit monitoring
416 
417### Context Management System
418 
419The Context Management System handles conversation history truncation to prevent context window overflow errors. Implemented in the `ContextManager` class, it ensures long-running conversations remain within model context limits while preserving critical context.
420 
421Key features:
422 
4231. **Model-Aware Sizing**: Dynamically adjusts based on different model context windows (64K for DeepSeek, 128K for most models, 200K for Claude).
424 
4252. **Proactive Truncation**: Monitors token usage and preemptively truncates conversations when approaching limits, maintaining buffers of 27K-40K tokens depending on the model.
426 
4273. **Intelligent Preservation**: Always preserves the original task message and maintains the user-assistant conversation structure when truncating.
428 
4294. **Adaptive Strategies**: Uses different truncation strategies based on context pressure - removing half of the conversation for moderate pressure or three-quarters for severe pressure.
430 
4315. **Error Recovery**: Includes specialized detection for context window errors from different providers with automatic retry and more aggressive truncation when needed.
432 
433### Task State & Resumption
434 
435The Task class provides robust task state management and resumption capabilities:
436 
437```typescript
438class Task {
439  async resumeTaskFromHistory() {
440    // 1. Load saved state
441    this.clineMessages = await getSavedClineMessages(this.getContext(), this.taskId)
442    this.apiConversationHistory = await getSavedApiConversationHistory(this.getContext(), this.taskId)
443 
444    // 2. Handle interrupted tool executions
445    const lastMessage = this.apiConversationHistory[this.apiConversationHistory.length - 1]
446    if (lastMessage.role === "assistant") {
447      const toolUseBlocks = content.filter(block => block.type === "tool_use")
448      if (toolUseBlocks.length > 0) {
449        // Add interrupted tool responses
450        const toolResponses = toolUseBlocks.map(block => ({
451          type: "tool_result",
452          tool_use_id: block.id,
453          content: "Task was interrupted before this tool call could be completed."
454        }))
455        modifiedOldUserContent = [...toolResponses]
456      }
457    }
458 
459    // 3. Notify about interruption
460    const agoText = this.getTimeAgoText(lastMessage?.ts)
461    newUserContent.push({
462      type: "text",
463      text: `[TASK RESUMPTION] This task was interrupted ${agoText}. It may or may not be complete, so please reassess the task context.`
464    })
465 
466    // 4. Resume task execution
467    await this.initiateTaskLoop(newUserContent, false)
468  }
469 
470  private async saveTaskState() {
471    // Save conversation history
472    await saveApiConversationHistory(this.getContext(), this.taskId, this.apiConversationHistory)
473    await saveClineMessages(this.getContext(), this.taskId, this.clineMessages)
474    
475    // Create checkpoint
476    const commitHash = await this.checkpointTracker?.commit()
477    
478    // Update task history
479    await this.controllerRef.deref()?.updateTaskHistory({
480      id: this.taskId,
481      ts: lastMessage.ts,
482      task: taskMessage.text,
483      // ... other metadata
484    })
485  }
486}
487```
488 
489Key aspects of task state management:
490 
4911. **Task Persistence**
492   - Each task has a unique ID and dedicated storage directory
493   - Conversation history is saved after each message
494   - File changes are tracked through Git-based checkpoints
495   - Terminal output and browser state are preserved
496 
4972. **State Recovery**
498   - Tasks can be resumed from any point
499   - Interrupted tool executions are handled gracefully
500   - File changes can be restored from checkpoints
501   - Context is preserved across VSCode sessions
502 
5033. **Workspace Synchronization**
504   - File changes are tracked through Git
505   - Checkpoints are created after tool executions
506   - State can be restored to any checkpoint
507   - Changes can be compared between checkpoints
508 
5094. **Error Recovery**
510   - Failed API requests can be retried
511   - Interrupted tool executions are marked
512   - Resources are cleaned up properly
513   - User is notified of state changes
514 
515## Plan/Act Mode System
516 
517Cline implements a dual-mode system that separates planning from execution:
518 
519### Mode Architecture
520 
521The Plan/Act mode system consists of:
522 
5231. **Mode State**: Stored in `chatSettings.mode` in the Controller's state
5242. **Mode Switching**: Handled by `togglePlanActModeWithChatSettings` in the Controller
5253. **Mode-specific Models**: Optional configuration to use different models for each mode
5264. **Mode-specific Prompting**: Different system prompts for planning vs. execution
527 
528### Mode Switching Process
529 
530When switching between modes:
531 
5321. The current model configuration is saved to mode-specific state
5332. The previous mode's model configuration is restored
5343. The Task instance is updated with the new mode
5354. The webview is notified of the mode change
5365. Telemetry events are captured for analytics
537 
538### Plan Mode
539 
540Plan mode is designed for:
541- Information gathering and context building
542- Asking clarifying questions
543- Creating detailed execution plans
544- Discussing approaches with the user
545 
546In Plan mode, the AI uses the `plan_mode_respond` tool to engage in conversational planning without executing actions.
547 
548### Act Mode
549 
550Act mode is designed for:
551- Executing the planned actions
552- Using tools to modify files, run commands, etc.
553- Implementing the solution
554- Providing results and completion feedback
555 
556In Act mode, the AI has access to all tools except `plan_mode_respond` and focuses on implementation rather than discussion.
557 
558## Data Flow & State Management
559 
560### Core Extension Role
561 
562The Controller acts as the single source of truth for all persistent state. It:
563- Manages VSCode global state and secrets storage
564- Coordinates state updates between components
565- Ensures state consistency across webview reloads
566- Handles task-specific state persistence
567- Manages checkpoint creation and restoration
568 
569### Terminal Management
570 
571The Task class manages terminal instances and command execution:
572 
573```typescript
574class Task {
575  async executeCommandTool(command: string): Promise<[boolean, ToolResponse]> {
576    // 1. Get or create terminal
577    const terminalInfo = await this.terminalManager.getOrCreateTerminal(cwd)
578    terminalInfo.terminal.show()
579 
580    // 2. Execute command with output streaming
581    const process = this.terminalManager.runCommand(terminalInfo, command)
582    
583    // 3. Handle real-time output
584    let result = ""
585    process.on("line", (line) => {
586      result += line + "\n"
587      if (!didContinue) {
588        sendCommandOutput(line)
589      } else {
590        this.say("command_output", line)
591      }
592    })
593 
594    // 4. Wait for completion or user feedback
595    let completed = false
596    process.once("completed", () => {
597      completed = true
598    })
599 
600    await process
601 
602    // 5. Return result
603    if (completed) {
604      return [false, `Command executed.\n${result}`]
605    } else {
606      return [
607        false,
608        `Command is still running in the user's terminal.\n${result}\n\nYou will be updated on the terminal status and new output in the future.`
609      ]
610    }
611  }
612}
613```
614 
615Key features:
6161. **Terminal Instance Management**
617   - Multiple terminal support
618   - Terminal state tracking (busy/inactive)
619   - Process cooldown monitoring
620   - Output history per terminal
621 
6222. **Command Execution**
623   - Real-time output streaming
624   - User feedback handling
625   - Process state monitoring
626   - Error recovery
627 
628### Browser Session Management
629 
630The Task class handles browser automation through Puppeteer:
631 
632```typescript
633class Task {
634  async executeBrowserAction(action: BrowserAction): Promise<BrowserActionResult> {
635    switch (action) {
636      case "launch":
637        // 1. Launch browser with fixed resolution
638        await this.browserSession.launchBrowser()
639        return await this.browserSession.navigateToUrl(url)
640 
641      case "click":
642        // 2. Handle click actions with coordinates
643        return await this.browserSession.click(coordinate)
644 
645      case "type":
646        // 3. Handle keyboard input
647        return await this.browserSession.type(text)
648 
649      case "close":
650        // 4. Clean up resources
651        return await this.browserSession.closeBrowser()
652    }
653  }
654}
655```
656 
657Key aspects:
6581. **Browser Control**
659   - Fixed 900x600 resolution window
660   - Single instance per task lifecycle
661   - Automatic cleanup on task completion
662   - Console log capture
663 
6642. **Interaction Handling**
665   - Coordinate-based clicking
666   - Keyboard input simulation
667   - Screenshot capture
668   - Error recovery
669 
670## MCP (Model Context Protocol) Integration
671 
672### MCP Architecture
673 
674The MCP system consists of:
675 
6761. **McpHub Class**: Central manager in `src/services/mcp/McpHub.ts`
6772. **MCP Connections**: Manages connections to external MCP servers
6783. **MCP Settings**: Configuration stored in a JSON file
6794. **MCP Marketplace**: Online catalog of available MCP servers
6805. **MCP Tools & Resources**: Capabilities exposed by connected servers
681 
682The McpHub class:
683- Manages the lifecycle of MCP server connections
684- Handles server configuration through a settings file
685- Provides methods for calling tools and accessing resources
686- Implements auto-approval settings for MCP tools
687- Monitors server health and handles reconnection
688 
689### MCP Server Types
690 
691Cline supports two types of MCP server connections:
692- **Stdio**: Command-line based servers that communicate via standard I/O
693- **SSE**: HTTP-based servers that communicate via Server-Sent Events
694 
695### MCP Server Management
696 
697The McpHub class provides methods for:
698- Discovering and connecting to MCP servers
699- Monitoring server health and status
700- Restarting servers when needed
701- Managing server configurations
702- Setting timeouts and auto-approval rules
703 
704### MCP Tool Integration
705 
706MCP tools are integrated into the Task execution system:
707- Tools are discovered and registered at connection time
708- The Task class can call MCP tools through the McpHub
709- Tool results are streamed back to the AI
710- Auto-approval settings can be configured per tool
711 
712### MCP Marketplace
713 
714The MCP Marketplace provides:
715- A catalog of available MCP servers
716- One-click installation
717- README previews
718- Server status monitoring
719 
720The Controller class manages MCP servers through the McpHub service:
721 
722```typescript
723class Controller {
724  mcpHub?: McpHub
725 
726  constructor(context: vscode.ExtensionContext, outputChannel: vscode.OutputChannel, webviewProvider: WebviewProvider) {
727    this.mcpHub = new McpHub(this)
728  }
729 
730  async downloadMcp(mcpId: string) {
731    // Fetch server details from marketplace
732    const response = await axios.post<McpDownloadResponse>(
733      "https://api.cline.bot/v1/mcp/download",
734      { mcpId },
735      {
736        headers: { "Content-Type": "application/json" },
737        timeout: 10000,
738      }
739    )
740 
741    // Create task with context from README
742    const task = `Set up the MCP server from ${mcpDetails.githubUrl}...`
743 
744    // Initialize task and show chat view
745    await this.initClineWithTask(task)
746  }
747}
748```
749 
750## Conclusion
751 
752This guide provides a comprehensive overview of the Cline extension architecture, with special focus on state management, data persistence, and code organization. Following these patterns ensures robust feature implementation with proper state handling across the extension's components.
753 
754Remember:
755- Always persist important state in the extension
756- The core extension follows a WebviewProvider -> Controller -> Task flow
757- Use proper typing for all state and messages
758- Handle errors and edge cases
759- Test state persistence across webview reloads
760- Follow the established patterns for consistency
761- Place new code in appropriate directories
762- Maintain clear separation of concerns
763- Install dependencies in correct package.json
764 
765## Contributing
766 
767Contributions to the Cline extension are welcome! Please follow these guidelines:
768 
769When adding new tools or API providers, follow the existing patterns in the `src/integrations/` and `src/api/providers/` directories, respectively. Ensure that your code is well-documented and includes appropriate error handling.
770 
771The `.clineignore` file allows users to specify files and directories that Cline should not access. When implementing new features, respect the `.clineignore` rules and ensure that your code does not attempt to read or modify ignored files.
772