> For the complete documentation index, see [llms.txt](https://modelmesh.gitbook.io/cline-zhong-wen-ban-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://modelmesh.gitbook.io/cline-zhong-wen-ban-docs/xin-jian-ren-wu-gong-ju.md). # 新建任务工具 ## **工具和上下文管理策略** ### **概述** Cline-胜算云增强版 包括一个强大的内部工具 `new_task`，旨在帮助管理工作流连续性和上下文保留，尤其是在复杂或长时间运行的任务期间。此工具与 Cline 对自身上下文窗口使用情况的感知以及 `.clinerules` 的灵活性相结合，支持分解工作并确保任务会话之间无缝过渡的复杂策略。 了解核心功能以及它们如何与自定义规则交互是有效利用此功能的关键。 ### **核心能力** 两个基本功能支持高级上下文管理： 1. **`new_task` 工具：** * **功能：** 允许 Cline 在用户批准后结束当前任务会话并立即启动新的任务会话。 * **上下文预加载：** 至关重要的是，Cline 可以在工具的 `` 块中提供特定上下文**来预加载**这个新的任务会话。此上下文可以是 Cline 或 `.clinerules` 文件定义的任何内容 - 摘要、代码片段、后续步骤、项目状态等。 2. **上下文窗口感知：** * **跟踪：**Cline 在内部跟踪任务期间当前使用的可用上下文窗口的百分比。 * **能见度：** 此信息显示在提示符中提供给 Cline 的 `environment_details` 中。 ### **默认行为（不带 `.clinerules`）** 默认情况下，没有特定的 `.clinerules` 规定其行为： * **工具可用性：**`new_task` 工具存在，Cline *可以选择*使用它。 * **情境感知：**Cline *知道*其上下文使用百分比。 * **无自动触发：**Cline **不会***仅*根据上下文使用率达到特定百分比（如 50%）自动启动任务移交。建议使用 `new_task` 的决定来自 AI 模型基于整体任务进度和提示说明的推理。 * **基本上下文预加载：** 如果使用 `new_task` 时没有定义 `` 块结构的特定规则，则 Cline 将尝试根据其当前的理解（例如，进度和后续步骤的基本摘要）预加载相关信息，但这可能不如规则驱动的方法全面。 ### **`.clinerules` 的强大功能：启用自定义工作流程** 虽然默认情况下存在核心功能，但当您将 `new_task` 和上下文感知与 `.clinerules` 中定义的自定义工作流相结合时，真正的功能、自动化和自定义就会显现出来。这使您可以精确控制 Cline *管理*上下文和任务连续性的时间和*方式* 。 将 `.clinerules` 与 `new_task` 结合使用的主要好处： * **自动化上下文管理：** 定义规则以在特定上下文百分比（例如，>50%、>70%）或令牌计数时自动触发切换，从而确保最佳性能并防止上下文丢失。 * **特定于模型的优化：** 根据不同 LLMs（例如，对于已知降级超过特定令牌计数的模型，提前触发切换触发器）。 * **智能断点：** 通过规则指示 Cline 在通过上下文阈值*后*查找逻辑停止点（例如，在完成函数或测试后），确保更清晰的切换。 * **结构化任务分解：** 使用计划模式定义子任务，然后使用 `.clinerules` 让 Cline 在完成每个子任务时通过 `new_task` 自动创建新任务，为*下一个*子任务预加载上下文。 * **自定义上下文打包：** 在 `.clinerules` 中强制要求 `` 块的确切结构和内容，以实现高度详细和一致的切换（请参阅下面的示例）。 * **改进的内存持久性：** 使用 `new_task` 上下文块作为跨会话持久保存信息的主要集成方式，从而可能取代或补充基于文件的内存系统。 * **工作流程自动化：** 为特定场景定义规则，例如在启动特定类型的任务时始终预加载某些设置说明或项目样板。 ### **规则驱动型工作流示例：任务移交流程** **由特定 `.clinerules`** 驱动的常见工作流（ **如下例）** 涉及以下步骤： 1. **触发器识别（基于规则）：**Cline 监控规则中定义的切换点（例如，上下文使用情况> 50%、任务完成）。 2. **用户确认：**Cline 使用 `ask_followup_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? ["Yes, create new task", "Modify context first", "No, continue this session"] ``` 3. **用户控制：** 在创建新任务之前，您可以批准、拒绝或要求 Cline 修改上下文。 4. **上下文打包（`new_task` 工具）：** 如果获得批准，Cline 将使用 `new_task`，并根据 `.clinerules` 规定的结构打包上下文。 5. **新任务创建：** 当前任务结束，新会话立即开始，并预加载了指定的上下文。 ### **Handoff 上下文块（规则定义的结构）** 规则驱动的切换的有效性在很大程度上取决于 `.clinerules` 如何定义 `` 块。全面的结构通常包括： * **`已完成的工作`** ：成就的详细列表、修改/创建的文件、关键决策。 * **`当前状态`** ：项目状态、正在运行的进程、关键文件状态。 * **`下一步`** ：清晰、优先的剩余任务列表、实施细节、已知挑战。 * **`参考信息`** ：链接、代码片段、模式、用户首选项。 * **可行的开始：** 立即执行下一步作的明确指示。 ### **可能的用例和工作流程** `new_task` 与 `.clinerules` 相结合的灵活性开辟了许多可能性： * **主动上下文窗口管理：** 以特定百分比（例如 50%、70%）或令牌计数自动触发切换，以保持最佳性能。 * **智能断点：** 指示 Cline 在通过上下文阈值*后*找到逻辑停止点（例如，在完成函数或测试后），确保更清晰的切换。 * **结构化任务分解：** 使用计划模式定义子任务，然后使用 `.clinerules` 让 Cline 在完成每个子任务时通过 `new_task` 自动创建新任务。 * **自动会话摘要：** 将 `` 块配置为始终包含上一会话的关键讨论点的摘要。 * **预加载样板/设置：** 启动与预加载了标准设置说明或文件模板的特定项目相关的新任务。 * **"“内存银行”替代方案：** 使用 `new_task` 上下文块作为跨会话持久保存信息的主要方式，从而可能取代基于文件的内存系统。 我们鼓励尝试使用 `.clinerules` 以发现最适合您需求的工作流程！ ### **示例 `.clinerules`：任务切换策略指南** 下面是一个示例 `.clinerules` 文件，专门用于使用 `new_task` 进行上下文窗口管理。 **请记住，这只是一种特定的策略;核心 `new_task` 工具可以与其他自定义规则以不同的方式使用。** ```` # 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-3.7-sonnet (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 I've completed [specific accomplishment]. Would you like me to create a new task to continue with [remaining work]? ["Yes, create a new task", "No, continue in this session", "Let me think about it"] \`\`\` ### 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 # 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]. \`\`\` ### 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 # 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. \`\`\` ### 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 ` ````