overture-mcp 0.1.5 → 0.1.6

package/README.md

@@ -110,6 +110,25 @@ Add this to the `mcpServers` object:
 
 Restart VS Code for the changes to take effect.
 
+### GitHub Copilot
+
+Create a `.vscode/mcp.json` file in your project root:
+
+```json
+{
+  "servers": {
+    "overture": {
+      "command": "npx",
+      "args": ["overture-mcp"]
+    }
+  }
+}
+```
+
+After creating the file, reload VS Code (Cmd/Ctrl + Shift + P → "Developer: Reload Window").
+
+**Note:** GitHub Copilot MCP support requires VS Code 1.99+ and uses a different configuration format (`servers` instead of `mcpServers`).
+
 ### Global Installation (Optional)
 
 If you prefer to install Overture globally instead of using npx:
@@ -200,6 +219,24 @@ Add the `env` object to your MCP server configuration:
 }
 ```
 
+**GitHub Copilot** (`.vscode/mcp.json`)
+
+```json
+{
+  "servers": {
+    "overture": {
+      "command": "npx",
+      "args": ["overture-mcp"],
+      "env": {
+        "OVERTURE_HTTP_PORT": "4000",
+        "OVERTURE_WS_PORT": "4001",
+        "OVERTURE_AUTO_OPEN": "false"
+      }
+    }
+  }
+}
+```
+
 **Global Installation (shell)**
 
 If you installed globally, set variables in your shell before running:

package/dist/{chunk-LFRCKLZZ.js → chunk-HCV6SX5I.js}

@@ -1883,6 +1883,51 @@ claude mcp add ${configServerName} --scope user
 claude mcp list
 claude mcp get ${configServerName}
 \`\`\`
+`;
+    case "gh_copilot":
+    case "gh-copilot":
+    case "github-copilot":
+    case "copilot":
+      return `
+### GitHub Copilot MCP Setup Instructions
+
+**Workspace-level Configuration (Recommended)**
+
+Create or edit \`.vscode/mcp.json\` in your project root:
+
+\`\`\`json
+{
+  "servers": {
+    "${configServerName}": {
+      "command": "npx",
+      "args": ["mcp-server-name"]
+    }
+  }
+}
+\`\`\`
+
+**User-level Configuration**
+
+Add to your VS Code \`settings.json\`:
+
+\`\`\`json
+{
+  "github.copilot.chat.mcpServers": {
+    "${configServerName}": {
+      "command": "npx",
+      "args": ["mcp-server-name"]
+    }
+  }
+}
+\`\`\`
+
+**Steps:**
+1. Create/edit the config file at one of the locations above
+2. Add the server configuration
+3. Save the file
+4. Reload VS Code window (Cmd/Ctrl + Shift + P \u2192 "Developer: Reload Window")
+
+**Important:** Read the existing file first - DO NOT overwrite other servers!
 `;
     default:
       return `
@@ -2534,7 +2579,7 @@ function handleCreateNewPlan(projectId) {
   };
 }
 async function handleGetUsageInstructions(agentType) {
-  const availableAgents = ["claude-code", "cline", "cursor", "sixth"];
+  const availableAgents = ["claude-code", "cline", "cursor", "sixth", "gh_copilot"];
   const normalizedType = agentType.toLowerCase().trim();
   const agentMap = {
     "claude-code": "claude-code",
@@ -2543,7 +2588,13 @@ async function handleGetUsageInstructions(agentType) {
     "cline": "cline",
     "cursor": "cursor",
     "sixth": "sixth",
-    "6th": "sixth"
+    "6th": "sixth",
+    "gh_copilot": "gh_copilot",
+    "gh-copilot": "gh_copilot",
+    "github-copilot": "gh_copilot",
+    "github_copilot": "gh_copilot",
+    "copilot": "gh_copilot",
+    "ghcopilot": "gh_copilot"
   };
   const mappedType = agentMap[normalizedType];
   if (!mappedType) {

package/dist/cli.js

@@ -2,7 +2,7 @@
 import {
   startHttpServer,
   wsManager
-} from "./chunk-LFRCKLZZ.js";
+} from "./chunk-HCV6SX5I.js";
 
 // src/cli.ts
 import chalk from "chalk";

package/dist/index.js

@@ -15,7 +15,7 @@ import {
   historyStorage,
   startHttpServer,
   wsManager
-} from "./chunk-LFRCKLZZ.js";
+} from "./chunk-HCV6SX5I.js";
 
 // src/index.ts
 import { Server } from "@modelcontextprotocol/sdk/server/index.js";
@@ -32,12 +32,12 @@ var AUTO_OPEN_BROWSER = process.env.OVERTURE_AUTO_OPEN !== "false";
 var StreamPlanChunkSchema = z.object({
   xml_chunk: z.string().describe("A chunk of the plan XML to process"),
   workspace_path: z.string().optional().describe("Absolute path to the workspace/project directory"),
-  agent_type: z.string().optional().describe("The type of agent (claude-code, cline, cursor, sixth)")
+  agent_type: z.string().optional().describe("The type of agent (claude-code, cline, cursor, sixth, gh_copilot)")
 });
 var SubmitPlanSchema = z.object({
   plan_xml: z.string().describe("The complete plan XML"),
   workspace_path: z.string().optional().describe("Absolute path to the workspace/project directory"),
-  agent_type: z.string().optional().describe("The type of agent (claude-code, cline, cursor, sixth)")
+  agent_type: z.string().optional().describe("The type of agent (claude-code, cline, cursor, sixth, gh_copilot)")
 });
 var GetApprovalSchema = z.object({
   project_id: z.string().optional().describe("Project ID (optional, uses current project if not specified)")
@@ -112,7 +112,7 @@ var CreateNewPlanSchema = z.object({
   project_id: z.string().optional().describe("Project ID (optional, uses current project if not specified)")
 });
 var GetUsageInstructionsSchema = z.object({
-  agent_type: z.string().describe("The type of agent requesting instructions (claude-code, cline, cursor, sixth)")
+  agent_type: z.string().describe("The type of agent requesting instructions (claude-code, cline, cursor, sixth, gh_copilot)")
 });
 var TOOLS = [
   {
@@ -131,7 +131,7 @@ var TOOLS = [
         },
         agent_type: {
           type: "string",
-          description: "The type of agent (claude-code, cline, cursor, sixth)"
+          description: "The type of agent (claude-code, cline, cursor, sixth, gh_copilot)"
         }
       },
       required: ["xml_chunk"]
@@ -153,7 +153,7 @@ var TOOLS = [
         },
         agent_type: {
           type: "string",
-          description: "The type of agent (claude-code, cline, cursor, sixth)"
+          description: "The type of agent (claude-code, cline, cursor, sixth, gh_copilot)"
         }
       },
       required: ["plan_xml"]
@@ -398,7 +398,7 @@ var TOOLS = [
       properties: {
         agent_type: {
           type: "string",
-          description: 'The type of agent requesting instructions. Supported: "claude-code", "cline", "cursor", "sixth"'
+          description: 'The type of agent requesting instructions. Supported: "claude-code", "cline", "cursor", "sixth", "gh_copilot"'
         }
       },
       required: ["agent_type"]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "overture-mcp",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "MCP Server for Claude Code, Cursor, Cline, Copilot, Windsurf - Visual AI Agent Plan Execution, Approval Workflow, Plan Visualization, Agent Orchestration. See what your AI is thinking before it writes code. Works with Claude, GPT, Gemini, DeepSeek, Qwen. Alternative to blind AI coding.",
   "type": "module",
   "main": "dist/index.js",

package/prompts/claude-code.md

@@ -19,7 +19,7 @@ Every AI coding agent shares the same fundamental problem: the developer types a
 - Complex implementations with multiple valid approaches
 - Tasks where getting alignment upfront saves significant rework
 
-**DO NOT USE** Overture for:
+**DO NOT USE (Except if the user explicitity asks you to)** Overture for:
 - Simple questions or explanations
 - Single-file, small edits
 - Quick bug fixes with obvious solutions
@@ -33,6 +33,10 @@ Every AI coding agent shares the same fundamental problem: the developer types a
 
 Unlike simple 5-10 step outlines, Overture expects you to generate **fully decomposed plans** where every task is broken into its smallest meaningful units. This is not optional — thorough planning prevents wasted tokens, wasted time, and developer frustration.
 
+### The Golden Rule: ONE COMPONENT = ONE NODE
+
+**NEVER combine multiple components or features into a single node.** Each UI component, each API endpoint, each configuration step gets its own dedicated node.
+
 ### Planning Requirements
 
 For every task you receive, your plan must include:
@@ -43,7 +47,59 @@ For every task you receive, your plan must include:
 4. **Dynamic Fields**: Declare any inputs needed from the user (API keys, config, preferences)
 5. **Logical Dependencies**: Edges should reflect true execution order
 
-### Example: Proper Decomposition
+### Example: Good vs. Bad Planning
+
+**BAD PLAN (lazy, combined steps - DO NOT DO THIS):**
+```
+1. Set up project
+2. Build the frontend
+3. Add backend API
+4. Deploy
+```
+
+**GOOD PLAN (atomic decomposition - THIS IS WHAT WE WANT):**
+```
+1. Initialize Next.js project with TypeScript
+2. Configure Tailwind CSS with custom theme colors
+3. Create Header component
+   - Logo placement and styling
+   - Navigation menu items
+   - Mobile hamburger menu
+   - Dark mode toggle button
+4. Create Hero section
+   - Main headline with gradient text
+   - Subheadline copy
+   - Primary CTA button with hover states
+   - Background image/pattern
+5. Create Features section
+   - Section heading
+   - 3-column grid layout
+   - Individual FeatureCard component
+   - Icons for each feature
+6. Create Testimonials section
+   - Testimonial card component
+   - Avatar, name, role, quote
+   - Carousel/grid layout
+7. Create Pricing section
+   - Monthly/Annual toggle
+   - PricingCard component for each tier
+   - Feature comparison list
+8. Create Footer component
+   - Logo and tagline
+   - Link columns (Product, Company, Resources)
+   - Newsletter signup form
+   - Social media icons
+9. Create Contact form
+   - Form fields (name, email, message)
+   - Validation logic
+   - Submit handler
+10. Add SEO meta tags and Open Graph
+11. Configure Vercel deployment
+```
+
+**Notice:** Each component (Header, Hero, Features, Footer, etc.) is its **own separate node**. Do NOT combine "Header, Hero, and Footer" into one "Build UI components" node.
+
+### Example: Full-Stack App Decomposition
 
 If a user asks for "a full-stack e-commerce app with Stripe integration," your plan should include nodes like:
 
@@ -345,6 +401,67 @@ If the user asks for something completely unrelated to the current plan (e.g., "
 
 ---
 
+## Branching Rules (CRITICAL FOR UI RENDERING)
+
+When you create decision nodes with branches, you **MUST** follow these rules for the UI to render correctly:
+
+### Rule 1: Every branch needs follow-up tasks
+For EACH branch option in a decision node, create at least one task node that is linked to that specific branch.
+
+### Rule 2: Use branch_parent and branch_id attributes
+Tasks that belong to a specific branch MUST have both attributes:
+```xml
+<node id="n3" type="task" branch_parent="n2" branch_id="b1">
+```
+- `branch_parent`: The ID of the decision node (e.g., "n2")
+- `branch_id`: The ID of the specific branch this task belongs to (e.g., "b1")
+
+### Rule 3: Create parallel branch paths
+If a decision has 3 branches (b1, b2, b3), you need tasks for each:
+```xml
+<!-- Decision node -->
+<node id="n2" type="decision">
+  <branch id="b1" label="Option A">...</branch>
+  <branch id="b2" label="Option B">...</branch>
+  <branch id="b3" label="Option C">...</branch>
+</node>
+
+<!-- Tasks for branch b1 (Option A) -->
+<node id="n3" type="task" branch_parent="n2" branch_id="b1">
+  <title>Implement Option A</title>
+</node>
+
+<!-- Tasks for branch b2 (Option B) -->
+<node id="n4" type="task" branch_parent="n2" branch_id="b2">
+  <title>Implement Option B</title>
+</node>
+
+<!-- Tasks for branch b3 (Option C) -->
+<node id="n5" type="task" branch_parent="n2" branch_id="b3">
+  <title>Implement Option C</title>
+</node>
+
+<!-- Edges connect decision to ALL branch tasks -->
+<edge from="n2" to="n3" />
+<edge from="n2" to="n4" />
+<edge from="n2" to="n5" />
+```
+
+### Rule 4: Branches can converge
+After branch-specific tasks, you can have a common task that all branches lead to:
+```xml
+<!-- Common task after all branches -->
+<node id="n6" type="task">
+  <title>Continue with shared step</title>
+</node>
+
+<edge from="n3" to="n6" />
+<edge from="n4" to="n6" />
+<edge from="n5" to="n6" />
+```
+
+---
+
 ## Dynamic Field Types
 
 | Type | Use Case | Required Attributes |

package/prompts/cline.md

@@ -8,6 +8,22 @@ Every AI coding agent shares the same fundamental problem: the developer types a
 
 **Overture solves this by making your plan visible, editable, and approvable before execution begins.**
 
+## When to Use Overture
+
+**USE** Overture for any task involving:
+- Multiple steps or files to create/modify
+- Architectural decisions the user should weigh in on
+- User configuration (API keys, preferences, settings)
+- Complex implementations with multiple valid approaches
+- Tasks where getting alignment upfront saves significant rework
+
+**DO NOT USE (Except if the user explicitity asks you to)** Overture for:
+- Simple questions or explanations
+- Single-file, small edits
+- Quick bug fixes with obvious solutions
+- Research or exploration tasks
+
+
 ---
 
 ## Critical: Extended Planning Mode
@@ -26,16 +42,21 @@ For every task you receive, your plan must include:
 4. **Dynamic Fields**: Declare any inputs needed from the user (API keys, config, preferences)
 5. **Logical Dependencies**: Edges should reflect true execution order
 
+### The Golden Rule: ONE COMPONENT = ONE NODE
+
+**NEVER combine multiple components or features into a single node.** Each UI component, each API endpoint, each configuration step gets its own dedicated node.
+
 ### Example: Good vs. Bad Planning
 
-**Bad Plan** (too vague):
+**BAD PLAN (lazy, combined steps - DO NOT DO THIS):**
 ```
 1. Set up project
-2. Build landing page
-3. Deploy
+2. Build the frontend
+3. Add backend API
+4. Deploy
 ```
 
-**Good Plan** (properly decomposed):
+**GOOD PLAN (atomic decomposition - THIS IS WHAT WE WANT):**
 ```
 1. Initialize Vite + React project with TypeScript
 2. Configure Tailwind CSS with custom theme
@@ -52,16 +73,29 @@ For every task you receive, your plan must include:
    - Grid layout (3 columns on desktop, 1 on mobile)
    - Feature card component
    - Icon selection for each feature
-6. Create Footer component
+6. Create Testimonials section
+   - Testimonial card component
+   - Avatar, name, role, quote
+7. Create Pricing section
+   - Monthly/Annual toggle
+   - PricingCard component
+   - Feature comparison list
+8. Create Footer component
    - Link groups
    - Newsletter signup form
    - Social media icons
-7. Add SEO meta tags and Open Graph
-8. Configure deployment (Vercel/Netlify)
-   - Environment variables
-   - Build configuration
+9. Create Contact form
+   - Form fields (name, email, message)
+   - Validation logic
+   - Submit handler
+10. Add SEO meta tags and Open Graph
+11. Configure deployment (Vercel/Netlify)
+    - Environment variables
+    - Build configuration
 ```
 
+**Notice:** Each component (Header, Hero, Features, Footer, etc.) is its **own separate node**. Do NOT combine "Header, Hero, and Footer" into one "Build UI components" node.
+
 Each of these becomes a node on the visual canvas.
 
 ---
@@ -227,6 +261,67 @@ If the user asks for something completely unrelated to the current plan (e.g., "
 
 ---
 
+## Branching Rules (CRITICAL FOR UI RENDERING)
+
+When you create decision nodes with branches, you **MUST** follow these rules for the UI to render correctly:
+
+### Rule 1: Every branch needs follow-up tasks
+For EACH branch option in a decision node, create at least one task node that is linked to that specific branch.
+
+### Rule 2: Use branch_parent and branch_id attributes
+Tasks that belong to a specific branch MUST have both attributes:
+```xml
+<node id="n3" type="task" branch_parent="n2" branch_id="b1">
+```
+- `branch_parent`: The ID of the decision node (e.g., "n2")
+- `branch_id`: The ID of the specific branch this task belongs to (e.g., "b1")
+
+### Rule 3: Create parallel branch paths
+If a decision has 3 branches (b1, b2, b3), you need tasks for each:
+```xml
+<!-- Decision node -->
+<node id="n2" type="decision">
+  <branch id="b1" label="Option A">...</branch>
+  <branch id="b2" label="Option B">...</branch>
+  <branch id="b3" label="Option C">...</branch>
+</node>
+
+<!-- Tasks for branch b1 (Option A) -->
+<node id="n3" type="task" branch_parent="n2" branch_id="b1">
+  <title>Implement Option A</title>
+</node>
+
+<!-- Tasks for branch b2 (Option B) -->
+<node id="n4" type="task" branch_parent="n2" branch_id="b2">
+  <title>Implement Option B</title>
+</node>
+
+<!-- Tasks for branch b3 (Option C) -->
+<node id="n5" type="task" branch_parent="n2" branch_id="b3">
+  <title>Implement Option C</title>
+</node>
+
+<!-- Edges connect decision to ALL branch tasks -->
+<edge from="n2" to="n3" />
+<edge from="n2" to="n4" />
+<edge from="n2" to="n5" />
+```
+
+### Rule 4: Branches can converge
+After branch-specific tasks, you can have a common task that all branches lead to:
+```xml
+<!-- Common task after all branches -->
+<node id="n6" type="task">
+  <title>Continue with shared step</title>
+</node>
+
+<edge from="n3" to="n6" />
+<edge from="n4" to="n6" />
+<edge from="n5" to="n6" />
+```
+
+---
+
 ## Dynamic Field Types
 
 | Type | Use Case | Example |

package/prompts/cursor.md

@@ -8,6 +8,22 @@ Every AI coding agent shares the same fundamental problem: the developer types a
 
 **Overture solves this by making your plan visible, editable, and approvable before execution begins.**
 
+## When to Use Overture
+
+**USE** Overture for any task involving:
+- Multiple steps or files to create/modify
+- Architectural decisions the user should weigh in on
+- User configuration (API keys, preferences, settings)
+- Complex implementations with multiple valid approaches
+- Tasks where getting alignment upfront saves significant rework
+
+**DO NOT USE (Except if the user explicitity asks you to)** Overture for:
+- Simple questions or explanations
+- Single-file, small edits
+- Quick bug fixes with obvious solutions
+- Research or exploration tasks
+
+
 ---
 
 ## Critical: Extended Planning Mode
@@ -26,20 +42,62 @@ For every task you receive, your plan must include:
 4. **Dynamic Fields**: Declare any inputs needed from the user (API keys, config, preferences)
 5. **Logical Dependencies**: Edges should reflect true execution order
 
-### Example: Proper Decomposition
+### The Golden Rule: ONE COMPONENT = ONE NODE
+
+**NEVER combine multiple components or features into a single node.** Each UI component, each API endpoint, each configuration step gets its own dedicated node.
+
+### Example: Good vs. Bad Planning
+
+**BAD PLAN (lazy, combined steps - DO NOT DO THIS):**
+```
+1. Set up project
+2. Build the frontend
+3. Add backend API
+4. Deploy
+```
+
+**GOOD PLAN (atomic decomposition - THIS IS WHAT WE WANT):**
 
 If a user asks for "a landing page," your plan should NOT just say "build a landing page." It should include:
 
-- Project initialization (framework selection, folder structure, dependency installation)
-- Header component (logo placement, navigation items, mobile responsiveness, dark mode toggle)
-- Hero section (headline copy, subheadline, CTA button, background image/gradient, animations)
-- Features section (grid layout, icon selection, copy for each feature card)
-- Social proof / testimonials section
-- Pricing section (tier structure, toggle for monthly/annual)
-- Footer (links, newsletter signup, social icons)
-- SEO setup (meta tags, Open Graph, sitemap)
-- Performance optimization (image compression, lazy loading)
-- Deployment configuration (CI/CD, environment variables, domain setup)
+```
+1. Initialize Next.js project with TypeScript
+2. Configure Tailwind CSS with custom theme
+3. Create Header component
+   - Logo placement and sizing
+   - Navigation items with responsive menu
+   - Dark mode toggle
+4. Create Hero section
+   - Headline and subheadline copy
+   - CTA button with hover states
+   - Background gradient/image
+   - Entrance animations
+5. Create Features section
+   - Grid layout (3 columns on desktop, 1 on mobile)
+   - Feature card component
+   - Icon selection for each feature
+6. Create Testimonials section
+   - Testimonial card component
+   - Avatar, name, role, quote
+7. Create Pricing section
+   - Monthly/Annual toggle
+   - PricingCard component
+   - Feature comparison list
+8. Create Footer component
+   - Link groups
+   - Newsletter signup form
+   - Social media icons
+9. Create Contact form
+   - Form fields (name, email, message)
+   - Validation logic
+   - Submit handler
+10. Add SEO meta tags and Open Graph
+11. Configure deployment (Vercel/Netlify)
+    - Environment variables
+    - Build configuration
+```
+
+**Notice:** Each component (Header, Hero, Features, Footer, etc.) is its **own separate node**. Do NOT combine "Header, Hero, and Footer" into one "Build UI components" node.
 
 Each of these becomes a node on the visual canvas with full details.
 
@@ -230,6 +288,67 @@ If the user asks for something completely unrelated to the current plan (e.g., "
 
 ---
 
+## Branching Rules (CRITICAL FOR UI RENDERING)
+
+When you create decision nodes with branches, you **MUST** follow these rules for the UI to render correctly:
+
+### Rule 1: Every branch needs follow-up tasks
+For EACH branch option in a decision node, create at least one task node that is linked to that specific branch.
+
+### Rule 2: Use branch_parent and branch_id attributes
+Tasks that belong to a specific branch MUST have both attributes:
+```xml
+<node id="n3" type="task" branch_parent="n2" branch_id="b1">
+```
+- `branch_parent`: The ID of the decision node (e.g., "n2")
+- `branch_id`: The ID of the specific branch this task belongs to (e.g., "b1")
+
+### Rule 3: Create parallel branch paths
+If a decision has 3 branches (b1, b2, b3), you need tasks for each:
+```xml
+<!-- Decision node -->
+<node id="n2" type="decision">
+  <branch id="b1" label="Option A">...</branch>
+  <branch id="b2" label="Option B">...</branch>
+  <branch id="b3" label="Option C">...</branch>
+</node>
+
+<!-- Tasks for branch b1 (Option A) -->
+<node id="n3" type="task" branch_parent="n2" branch_id="b1">
+  <title>Implement Option A</title>
+</node>
+
+<!-- Tasks for branch b2 (Option B) -->
+<node id="n4" type="task" branch_parent="n2" branch_id="b2">
+  <title>Implement Option B</title>
+</node>
+
+<!-- Tasks for branch b3 (Option C) -->
+<node id="n5" type="task" branch_parent="n2" branch_id="b3">
+  <title>Implement Option C</title>
+</node>
+
+<!-- Edges connect decision to ALL branch tasks -->
+<edge from="n2" to="n3" />
+<edge from="n2" to="n4" />
+<edge from="n2" to="n5" />
+```
+
+### Rule 4: Branches can converge
+After branch-specific tasks, you can have a common task that all branches lead to:
+```xml
+<!-- Common task after all branches -->
+<node id="n6" type="task">
+  <title>Continue with shared step</title>
+</node>
+
+<edge from="n3" to="n6" />
+<edge from="n4" to="n6" />
+<edge from="n5" to="n6" />
+```
+
+---
+
 ## Dynamic Field Types
 
 | Type | Use Case | Example |