overture-mcp 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +154 -0
- package/dist/chunk-LFRCKLZZ.js +2688 -0
- package/dist/cli.d.ts +1 -0
- package/dist/cli.js +56 -0
- package/dist/index.d.ts +2 -0
- package/dist/index.js +608 -0
- package/package.json +71 -0
- package/prompts/claude-code.md +832 -0
- package/prompts/cline.md +648 -0
- package/prompts/cursor.md +656 -0
- package/prompts/overture-instructions.md +376 -0
- package/prompts/sixth.md +640 -0
- package/ui-dist/assets/index-BLZ2dlmA.css +1 -0
- package/ui-dist/assets/index-DwGNwSSY.js +408 -0
- package/ui-dist/assets/index-DwGNwSSY.js.map +1 -0
- package/ui-dist/favicon.svg +8 -0
- package/ui-dist/index.html +18 -0
|
@@ -0,0 +1,376 @@
|
|
|
1
|
+
# Overture - Agent Plan Visualizer
|
|
2
|
+
|
|
3
|
+
You have access to Overture, a visual plan execution tool that displays your execution plan as an interactive flowchart. Before writing any code, you should generate a detailed plan and submit it to Overture for user review and approval.
|
|
4
|
+
|
|
5
|
+
## How Overture Works
|
|
6
|
+
|
|
7
|
+
1. **Generate Plan**: When given a task, create a comprehensive XML plan following the schema below
|
|
8
|
+
2. **Submit to Overture**: Use the `submit_plan` or `stream_plan_chunk` MCP tool to send the plan
|
|
9
|
+
3. **Wait for Approval**: Use the `get_approval` tool - this blocks until the user approves the plan in the visual UI
|
|
10
|
+
4. **Execute with Updates**: As you execute each step, use `update_node_status` to update the visual progress
|
|
11
|
+
5. **Complete**: When done, call `plan_completed` or `plan_failed`
|
|
12
|
+
|
|
13
|
+
## XML Plan Schema
|
|
14
|
+
|
|
15
|
+
```xml
|
|
16
|
+
<plan id="unique_id" title="Plan Title" agent="your-agent-name">
|
|
17
|
+
<nodes>
|
|
18
|
+
<!-- Task Node: A step to execute -->
|
|
19
|
+
<node id="n1" type="task" status="pending">
|
|
20
|
+
<title>Short task title</title>
|
|
21
|
+
<description>Detailed description of what this step does</description>
|
|
22
|
+
<complexity>low|medium|high</complexity>
|
|
23
|
+
<expected_output>What files/results this step produces</expected_output>
|
|
24
|
+
<risks>Potential issues or edge cases</risks>
|
|
25
|
+
|
|
26
|
+
<!-- Dynamic fields for user input -->
|
|
27
|
+
<dynamic_field
|
|
28
|
+
id="f1"
|
|
29
|
+
name="field_name"
|
|
30
|
+
type="string|secret|select|boolean|number"
|
|
31
|
+
required="true|false"
|
|
32
|
+
title="Human-readable label"
|
|
33
|
+
description="Help text for the field"
|
|
34
|
+
value="default value"
|
|
35
|
+
options="option1,option2,option3"
|
|
36
|
+
setup_instructions="How to get this value"
|
|
37
|
+
/>
|
|
38
|
+
</node>
|
|
39
|
+
|
|
40
|
+
<!-- Decision Node: A branching point with options -->
|
|
41
|
+
<node id="n2" type="decision" status="pending">
|
|
42
|
+
<title>Choose implementation approach</title>
|
|
43
|
+
<description>Description of the decision</description>
|
|
44
|
+
|
|
45
|
+
<branch id="b1" label="Option A">
|
|
46
|
+
<description>Details about this approach</description>
|
|
47
|
+
<pros>Advantages of this option</pros>
|
|
48
|
+
<cons>Disadvantages of this option</cons>
|
|
49
|
+
</branch>
|
|
50
|
+
|
|
51
|
+
<branch id="b2" label="Option B">
|
|
52
|
+
<description>Details about this approach</description>
|
|
53
|
+
<pros>Advantages of this option</pros>
|
|
54
|
+
<cons>Disadvantages of this option</cons>
|
|
55
|
+
</branch>
|
|
56
|
+
</node>
|
|
57
|
+
|
|
58
|
+
<!-- Task that belongs to a branch -->
|
|
59
|
+
<node id="n3" type="task" status="pending" branch_parent="n2" branch_id="b1">
|
|
60
|
+
<title>Task specific to Option A</title>
|
|
61
|
+
<description>This task only runs if user selects Option A</description>
|
|
62
|
+
</node>
|
|
63
|
+
</nodes>
|
|
64
|
+
|
|
65
|
+
<edges>
|
|
66
|
+
<edge id="e1" from="n1" to="n2" />
|
|
67
|
+
<!-- Branch edges are implicit based on branch_parent/branch_id -->
|
|
68
|
+
</edges>
|
|
69
|
+
</plan>
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Available MCP Tools
|
|
73
|
+
|
|
74
|
+
### `submit_plan`
|
|
75
|
+
Submit a complete plan XML at once.
|
|
76
|
+
```json
|
|
77
|
+
{ "plan_xml": "<plan>...</plan>" }
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
### `stream_plan_chunk`
|
|
81
|
+
Stream plan XML incrementally (for real-time node appearance).
|
|
82
|
+
```json
|
|
83
|
+
{ "xml_chunk": "<node id=\"n1\">..." }
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
### `get_approval`
|
|
87
|
+
Wait for user approval. Returns field values and selected branches.
|
|
88
|
+
```json
|
|
89
|
+
{}
|
|
90
|
+
```
|
|
91
|
+
Returns:
|
|
92
|
+
```json
|
|
93
|
+
{
|
|
94
|
+
"approved": true,
|
|
95
|
+
"fieldValues": { "n1.api_key": "sk-xxx" },
|
|
96
|
+
"selectedBranches": { "n2": "b1" }
|
|
97
|
+
}
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
### `update_node_status`
|
|
101
|
+
Update a node's execution status.
|
|
102
|
+
```json
|
|
103
|
+
{
|
|
104
|
+
"node_id": "n1",
|
|
105
|
+
"status": "active|completed|failed|skipped",
|
|
106
|
+
"output": "Optional execution output"
|
|
107
|
+
}
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
### `plan_completed`
|
|
111
|
+
Mark the entire plan as complete.
|
|
112
|
+
```json
|
|
113
|
+
{}
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
### `plan_failed`
|
|
117
|
+
Mark the plan as failed with an error.
|
|
118
|
+
```json
|
|
119
|
+
{ "error": "Error description" }
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Planning Guidelines
|
|
123
|
+
|
|
124
|
+
1. **Be Exhaustive**: Break down tasks to atomic steps. Don't say "build landing page" - list every component, every section.
|
|
125
|
+
|
|
126
|
+
2. **Use Decision Nodes**: When there are valid alternative approaches, create a decision node so the user can choose.
|
|
127
|
+
|
|
128
|
+
3. **Add Dynamic Fields**: For any configuration, API keys, or choices needed during execution, add dynamic fields so the user can provide them before approving.
|
|
129
|
+
|
|
130
|
+
4. **Estimate Complexity**: Mark each node as low/medium/high complexity to set expectations.
|
|
131
|
+
|
|
132
|
+
5. **Document Risks**: Note potential issues so the user knows what to watch for.
|
|
133
|
+
|
|
134
|
+
6. **Order Matters**: Structure edges so dependencies are clear. Parallel tasks should not have edges between them.
|
|
135
|
+
|
|
136
|
+
## Example: Simple Web App
|
|
137
|
+
|
|
138
|
+
```xml
|
|
139
|
+
<plan id="plan_webapp" title="Create React Todo App" agent="claude-code">
|
|
140
|
+
<nodes>
|
|
141
|
+
<node id="n1" type="task" status="pending">
|
|
142
|
+
<title>Initialize Vite + React project</title>
|
|
143
|
+
<description>Create a new Vite project with React and TypeScript template</description>
|
|
144
|
+
<complexity>low</complexity>
|
|
145
|
+
<expected_output>New project in ./todo-app directory</expected_output>
|
|
146
|
+
<dynamic_field id="f1" name="project_name" type="string" required="true"
|
|
147
|
+
title="Project Name" description="Name for the project directory" value="todo-app"/>
|
|
148
|
+
</node>
|
|
149
|
+
|
|
150
|
+
<node id="n2" type="task" status="pending">
|
|
151
|
+
<title>Install dependencies</title>
|
|
152
|
+
<description>Install required npm packages: zustand for state, lucide for icons</description>
|
|
153
|
+
<complexity>low</complexity>
|
|
154
|
+
</node>
|
|
155
|
+
|
|
156
|
+
<node id="n3" type="decision" status="pending">
|
|
157
|
+
<title>Choose styling approach</title>
|
|
158
|
+
<description>Select how to style the application</description>
|
|
159
|
+
<branch id="b1" label="Tailwind CSS">
|
|
160
|
+
<description>Utility-first CSS framework</description>
|
|
161
|
+
<pros>Fast development, consistent design, small bundle</pros>
|
|
162
|
+
<cons>HTML can get verbose</cons>
|
|
163
|
+
</branch>
|
|
164
|
+
<branch id="b2" label="CSS Modules">
|
|
165
|
+
<description>Scoped CSS with traditional approach</description>
|
|
166
|
+
<pros>Clean HTML, full CSS control</pros>
|
|
167
|
+
<cons>More files, slower iteration</cons>
|
|
168
|
+
</branch>
|
|
169
|
+
</node>
|
|
170
|
+
|
|
171
|
+
<node id="n4" type="task" status="pending" branch_parent="n3" branch_id="b1">
|
|
172
|
+
<title>Set up Tailwind CSS</title>
|
|
173
|
+
<description>Install and configure Tailwind CSS with Vite</description>
|
|
174
|
+
<complexity>low</complexity>
|
|
175
|
+
</node>
|
|
176
|
+
|
|
177
|
+
<node id="n5" type="task" status="pending">
|
|
178
|
+
<title>Create TodoItem component</title>
|
|
179
|
+
<description>Build the individual todo item component with checkbox and delete button</description>
|
|
180
|
+
<complexity>medium</complexity>
|
|
181
|
+
</node>
|
|
182
|
+
|
|
183
|
+
<node id="n6" type="task" status="pending">
|
|
184
|
+
<title>Create TodoList component</title>
|
|
185
|
+
<description>Build the list container that renders all todos</description>
|
|
186
|
+
<complexity>low</complexity>
|
|
187
|
+
</node>
|
|
188
|
+
|
|
189
|
+
<node id="n7" type="task" status="pending">
|
|
190
|
+
<title>Create AddTodo component</title>
|
|
191
|
+
<description>Build the input form for adding new todos</description>
|
|
192
|
+
<complexity>low</complexity>
|
|
193
|
+
</node>
|
|
194
|
+
|
|
195
|
+
<node id="n8" type="task" status="pending">
|
|
196
|
+
<title>Implement Zustand store</title>
|
|
197
|
+
<description>Create the state management store for todos with add, toggle, delete actions</description>
|
|
198
|
+
<complexity>medium</complexity>
|
|
199
|
+
</node>
|
|
200
|
+
|
|
201
|
+
<node id="n9" type="task" status="pending">
|
|
202
|
+
<title>Wire up components</title>
|
|
203
|
+
<description>Connect all components to the store and assemble in App.tsx</description>
|
|
204
|
+
<complexity>low</complexity>
|
|
205
|
+
</node>
|
|
206
|
+
|
|
207
|
+
<node id="n10" type="task" status="pending">
|
|
208
|
+
<title>Add local storage persistence</title>
|
|
209
|
+
<description>Persist todos to localStorage so they survive page refresh</description>
|
|
210
|
+
<complexity>low</complexity>
|
|
211
|
+
</node>
|
|
212
|
+
</nodes>
|
|
213
|
+
|
|
214
|
+
<edges>
|
|
215
|
+
<edge id="e1" from="n1" to="n2" />
|
|
216
|
+
<edge id="e2" from="n2" to="n3" />
|
|
217
|
+
<edge id="e3" from="n3" to="n5" />
|
|
218
|
+
<edge id="e4" from="n5" to="n6" />
|
|
219
|
+
<edge id="e5" from="n6" to="n7" />
|
|
220
|
+
<edge id="e6" from="n7" to="n8" />
|
|
221
|
+
<edge id="e7" from="n8" to="n9" />
|
|
222
|
+
<edge id="e8" from="n9" to="n10" />
|
|
223
|
+
</edges>
|
|
224
|
+
</plan>
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
## Execution Flow
|
|
228
|
+
|
|
229
|
+
After approval, execute like this:
|
|
230
|
+
|
|
231
|
+
```
|
|
232
|
+
1. update_node_status(n1, "active")
|
|
233
|
+
2. [Do the work for n1]
|
|
234
|
+
3. update_node_status(n1, "completed", "Created project in ./todo-app")
|
|
235
|
+
4. update_node_status(n2, "active")
|
|
236
|
+
5. [Do the work for n2]
|
|
237
|
+
6. update_node_status(n2, "completed")
|
|
238
|
+
... continue for each node ...
|
|
239
|
+
N. plan_completed()
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
If a node fails:
|
|
243
|
+
```
|
|
244
|
+
update_node_status(n5, "failed", "Error: could not install dependencies")
|
|
245
|
+
plan_failed("Installation failed due to network error")
|
|
246
|
+
```
|
|
247
|
+
|
|
248
|
+
---
|
|
249
|
+
|
|
250
|
+
## CRITICAL: Node-by-Node Execution (DO NOT OVER-IMPLEMENT)
|
|
251
|
+
|
|
252
|
+
⚠️ **MANDATORY EXECUTION RULES** ⚠️
|
|
253
|
+
|
|
254
|
+
When executing an Overture plan, you MUST follow these rules EXACTLY:
|
|
255
|
+
|
|
256
|
+
### Rule 1: ONE NODE AT A TIME
|
|
257
|
+
- Execute ONLY the current node returned by `get_approval` or `update_node_status`
|
|
258
|
+
- Do NOT look ahead to future nodes
|
|
259
|
+
- Do NOT implement multiple nodes at once
|
|
260
|
+
- Do NOT "optimize" by combining nodes
|
|
261
|
+
|
|
262
|
+
### Rule 2: COMPLETE NODE CONSUMPTION
|
|
263
|
+
For each node, you MUST implement/consume ALL of the following:
|
|
264
|
+
- ✅ `title` - The task title
|
|
265
|
+
- ✅ `description` - Full task description
|
|
266
|
+
- ✅ `instructions` - Detailed implementation instructions
|
|
267
|
+
- ✅ `fieldValues` - All dynamic field values provided by user
|
|
268
|
+
- ✅ `mcpServers` - **CRITICAL**: If present, MUST be installed and used
|
|
269
|
+
- ✅ `attachments` - All attached files/resources
|
|
270
|
+
- ✅ `expected_output` - What the node should produce
|
|
271
|
+
- ✅ `metadata` - Any additional metadata
|
|
272
|
+
|
|
273
|
+
### Rule 3: MCP Server Integration
|
|
274
|
+
If a node has an `mcpServers` attached:
|
|
275
|
+
1. **CHECK** if the MCP server is already installed
|
|
276
|
+
2. **INSTALL** the MCP server if not available (see setup instructions below)
|
|
277
|
+
3. **USE** the MCP server tools as specified in the node
|
|
278
|
+
4. **DO NOT** skip the node or proceed without the MCP server
|
|
279
|
+
|
|
280
|
+
### Rule 4: No Over-Implementation
|
|
281
|
+
❌ **NEVER DO THESE:**
|
|
282
|
+
- Skip to future nodes
|
|
283
|
+
- Implement features not in the current node
|
|
284
|
+
- "Anticipate" what future nodes might need
|
|
285
|
+
- Add "improvements" beyond the node scope
|
|
286
|
+
- Ignore MCP server requirements
|
|
287
|
+
|
|
288
|
+
✅ **ALWAYS DO THESE:**
|
|
289
|
+
- Focus only on current node content
|
|
290
|
+
- Implement exactly what the node specifies
|
|
291
|
+
- Use all provided field values
|
|
292
|
+
- Install and use required MCP servers
|
|
293
|
+
- Update node status after completion
|
|
294
|
+
|
|
295
|
+
---
|
|
296
|
+
|
|
297
|
+
## MCP Server Setup Instructions (Sixth AI)
|
|
298
|
+
|
|
299
|
+
When a node requires an MCP server that is not installed, follow these steps:
|
|
300
|
+
|
|
301
|
+
### Configuration File Location
|
|
302
|
+
**Sixth AI uses this MCP configuration file:**
|
|
303
|
+
- **macOS**: `~/Library/Application Support/Code/User/globalStorage/sixth.sixth-ai/settings/sixth-mcp-settings.json`
|
|
304
|
+
- **Windows**: `%APPDATA%\Code\User\globalStorage\sixth.sixth-ai\settings\sixth-mcp-settings.json`
|
|
305
|
+
- **Linux**: `~/.config/Code/User/globalStorage/sixth.sixth-ai/settings/sixth-mcp-settings.json`
|
|
306
|
+
|
|
307
|
+
### Setup Steps
|
|
308
|
+
|
|
309
|
+
1. **Read the current MCP settings file** (create if it doesn't exist)
|
|
310
|
+
2. **Add the new server configuration** to the `mcpServers` object
|
|
311
|
+
3. **Save the file**
|
|
312
|
+
4. **Restart or refresh** the MCP connection
|
|
313
|
+
|
|
314
|
+
### Configuration Format
|
|
315
|
+
|
|
316
|
+
```json
|
|
317
|
+
{
|
|
318
|
+
"mcpServers": {
|
|
319
|
+
"server-name": {
|
|
320
|
+
"command": "npx",
|
|
321
|
+
"args": ["-y", "@package/mcp-server"],
|
|
322
|
+
"env": {
|
|
323
|
+
"API_KEY": "your-api-key"
|
|
324
|
+
},
|
|
325
|
+
"disabled": false,
|
|
326
|
+
"autoApprove": []
|
|
327
|
+
}
|
|
328
|
+
}
|
|
329
|
+
}
|
|
330
|
+
```
|
|
331
|
+
|
|
332
|
+
### Example: Adding a New MCP Server
|
|
333
|
+
|
|
334
|
+
If the node specifies an MCP server like:
|
|
335
|
+
```json
|
|
336
|
+
{
|
|
337
|
+
"name": "github",
|
|
338
|
+
"command": "npx",
|
|
339
|
+
"args": ["-y", "@modelcontextprotocol/server-github"],
|
|
340
|
+
"env": {
|
|
341
|
+
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
|
|
342
|
+
}
|
|
343
|
+
}
|
|
344
|
+
```
|
|
345
|
+
|
|
346
|
+
Add it to the configuration file:
|
|
347
|
+
```json
|
|
348
|
+
{
|
|
349
|
+
"mcpServers": {
|
|
350
|
+
"github": {
|
|
351
|
+
"command": "npx",
|
|
352
|
+
"args": ["-y", "@modelcontextprotocol/server-github"],
|
|
353
|
+
"env": {
|
|
354
|
+
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
|
|
355
|
+
},
|
|
356
|
+
"disabled": false,
|
|
357
|
+
"autoApprove": []
|
|
358
|
+
}
|
|
359
|
+
}
|
|
360
|
+
}
|
|
361
|
+
```
|
|
362
|
+
|
|
363
|
+
### Handling "No connection found" Error
|
|
364
|
+
|
|
365
|
+
⚠️ **IMPORTANT**: If you receive a "No connection found for MCP server" error:
|
|
366
|
+
|
|
367
|
+
1. **DO NOT** skip the node
|
|
368
|
+
2. **DO NOT** proceed without the MCP server
|
|
369
|
+
3. **DO** follow the setup instructions above
|
|
370
|
+
4. **DO** install the MCP server
|
|
371
|
+
5. **DO** retry the connection after installation
|
|
372
|
+
6. **DO** complete the node requirements using the MCP tools
|
|
373
|
+
|
|
374
|
+
---
|
|
375
|
+
|
|
376
|
+
**Remember**: The visual plan is the user's way of understanding and controlling your work. Make it comprehensive, clear, and easy to follow. The more detail you provide upfront, the more confidence the user has in approving the plan.
|