Skip to content

Commit 2d0a5e7

Browse files
committed
Add documentation for the new_task tool and its functionality
1 parent 330a11f commit 2d0a5e7

File tree

1 file changed

+103
-0
lines changed

1 file changed

+103
-0
lines changed

docs/features/tools/new-task.md

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
# new_task
2+
3+
The `new_task` tool creates subtasks with specialized modes while maintaining a parent-child relationship. It breaks down complex projects into manageable pieces, each operating in the mode best suited for specific work.
4+
5+
## Parameters
6+
7+
The tool accepts these parameters:
8+
9+
- `mode` (required): The slug of the mode to start the new task in (e.g., "code", "ask", "architect")
10+
- `message` (required): The initial user message or instructions for this new task
11+
12+
## What It Does
13+
14+
This tool creates a new task instance with a specified starting mode and initial message. It allows complex workflows to be divided into subtasks with their own conversation history. Parent tasks are paused during subtask execution and resumed when the subtask completes, with results transferred back to the parent.
15+
16+
## When is it used?
17+
18+
- When breaking down complex projects into separate, focused subtasks
19+
- When different aspects of a task require different specialized modes
20+
- When different phases of work benefit from context separation
21+
- When organizing multi-phase development workflows
22+
23+
## Key Features
24+
25+
- Creates subtasks with their own conversation history and specialized mode
26+
- Pauses parent tasks for later resumption
27+
- Maintains hierarchical task relationships for navigation
28+
- Transfers results back to parent tasks upon completion
29+
- Supports workflow segregation for complex projects
30+
- Allows different parts of a project to use modes optimized for specific work
31+
- Requires explicit user approval for task creation
32+
- Provides clear task transition in the UI
33+
34+
## Limitations
35+
36+
- Cannot create tasks with modes that don't exist
37+
- Requires user approval before creating each new task
38+
- Task interface may become complex with deeply nested subtasks
39+
- Subtasks inherit certain workspace and extension configurations from parents
40+
- May require re-establishing context when switching between deeply nested tasks
41+
- Task completion needs explicit signaling to properly return to parent tasks
42+
43+
## How It Works
44+
45+
When the `new_task` tool is invoked, it follows this process:
46+
47+
1. **Parameter Validation**:
48+
- Validates the required `mode` and `message` parameters
49+
- Verifies that the requested mode exists in the system
50+
51+
2. **Task Stack Management**:
52+
- Maintains a task stack that tracks all active and paused tasks
53+
- Preserves the current mode for later resumption
54+
- Sets the parent task to paused state
55+
56+
3. **Task Context Management**:
57+
- Creates a new task context with the provided message
58+
- Assigns unique taskId and instanceId identifiers for state management
59+
- Captures telemetry data on tool usage and task lifecycles
60+
61+
4. **Mode Switching and Integration**:
62+
- Switches to the specified mode with appropriate role and capabilities
63+
- Initializes the new task with the provided message
64+
- Integrates with VS Code's command palette and code actions
65+
66+
5. **Task Completion and Result Transfer**:
67+
- When subtask completes, result is passed back to parent task via `finishSubTask()`
68+
- Parent task resumes in its original mode
69+
- Task history and token usage metrics are updated
70+
- The `taskCompleted` event is emitted with performance data
71+
72+
## Examples When Used
73+
74+
- When a front-end developer needs to architect a new feature, implement the code, and document it, they can create separate tasks for each phase with results flowing from one phase to the next.
75+
- When debugging an issue before implementing a fix, the debugging task can document findings that are passed to the implementation task.
76+
- When developing a full-stack application, database schema designs from an architect-mode task inform implementation details in a subsequent code-mode task.
77+
- When documenting a system after implementation, the documentation task can reference the completed implementation while using documentation-specific features.
78+
79+
## Usage Examples
80+
81+
Creating a new task in code mode:
82+
```
83+
<new_task>
84+
<mode>code</mode>
85+
<message>Implement a user authentication service with login, registration, and password reset functionality.</message>
86+
</new_task>
87+
```
88+
89+
Creating a documentation task after completing implementation:
90+
```
91+
<new_task>
92+
<mode>docs</mode>
93+
<message>Create comprehensive API documentation for the authentication service we just built.</message>
94+
</new_task>
95+
```
96+
97+
Breaking down a complex feature into architectural planning and implementation:
98+
```
99+
<new_task>
100+
<mode>architect</mode>
101+
<message>Design the database schema and system architecture for our new e-commerce platform.</message>
102+
</new_task>
103+
```

0 commit comments

Comments
 (0)