@riotprompt/riotplan 1.0.4 → 1.0.5

package/MCP-ELICITATION-NOTES.md

@@ -0,0 +1,211 @@
+# MCP Elicitation Notes
+
+## Understanding MCP Elicitation
+
+### What It Is
+
+MCP elicitation (introduced in the 2025-06-18 specification) is a protocol feature that allows **servers** to request structured data from users dynamically during interactions. It uses JSON schemas to validate responses and enables interactive workflows.
+
+### How It Works
+
+Servers send `elicitation/create` requests to clients:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 1,
+  "method": "elicitation/create",
+  "params": {
+    "message": "Please provide your GitHub username",
+    "requestedSchema": {
+      "type": "object",
+      "properties": {
+        "name": { "type": "string" }
+      },
+      "required": ["name"]
+    }
+  }
+}
+```
+
+Clients respond with:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 1,
+  "result": {
+    "action": "accept",
+    "content": { "name": "octocat" }
+  }
+}
+```
+
+### Key Limitation for Prompts
+
+**Prompts cannot directly trigger elicitation requests.** Prompts are static text templates that return messages to inject into the conversation. They don't have the ability to make protocol-level requests.
+
+Only **tools** and **resources** can trigger elicitation by making `elicitation/create` requests during their execution.
+
+## Our Approach: Prompt Arguments + Model Instructions
+
+Since prompts can't trigger elicitation directly, we use a hybrid approach:
+
+### 1. Define Prompt Arguments
+
+```typescript
+{
+    name: 'create_plan',
+    description: 'Create a new plan with AI-generated steps for a complex task',
+    arguments: [
+        {
+            name: 'code',
+            description: 'Plan code/identifier',
+            required: false,
+        },
+        {
+            name: 'description',
+            description: 'Detailed description of what to accomplish',
+            required: false,
+        },
+        {
+            name: 'directory',
+            description: 'Parent directory where the plan should be created',
+            required: false,
+        },
+    ],
+}
+```
+
+### 2. Template Variable Substitution
+
+The prompt template uses `${code}`, `${description}`, etc.:
+
+```markdown
+## Step 1: Review Provided Information
+
+Check what information has already been provided:
+- **code**: ${code}
+- **description**: ${description}
+- **directory**: ${directory}
+```
+
+When arguments are missing, we substitute with markers like `[code]`, `[description]`:
+
+```typescript
+if (!filledArgs.code) filledArgs.code = '[code]';
+if (!filledArgs.description) filledArgs.description = '[description]';
+```
+
+### 3. Model Instructions
+
+The prompt explicitly tells the model to check for these markers:
+
+```markdown
+## Step 2: Gather Missing Information
+
+For any information marked as "[code]", "[description]", "[directory]", 
+ask the user to provide it:
+
+1. **Plan Code** (if missing) - Ask for a short identifier
+2. **Plan Description** (if missing) - Ask for a detailed description
+3. **Target Directory** (if missing) - Ask where to create the plan
+```
+
+## Benefits of This Approach
+
+### Client-Side Elicitation (Future)
+
+MCP clients could potentially:
+1. See that `create_plan` has arguments
+2. Elicit those arguments from the user BEFORE invoking the prompt
+3. Pass the collected values when calling the prompt
+
+This would provide a form-based UI for gathering information upfront.
+
+### Model-Side Fallback (Current)
+
+If the client doesn't elicit arguments:
+1. The prompt is invoked with missing arguments
+2. Template substitution marks them as `[code]`, `[description]`, etc.
+3. The model sees these markers and knows to ask the user
+4. The model uses natural language to gather information
+
+### Progressive Enhancement
+
+- Works today with explicit model instructions
+- Can be enhanced in the future if clients add argument elicitation
+- Provides clear structure for what information is needed
+
+## Alternative: Tool-Based Elicitation
+
+Another approach would be to create a tool that triggers elicitation:
+
+```typescript
+{
+    name: 'riotplan_elicit_plan_info',
+    description: 'Gather plan information from user',
+    inputSchema: {
+        type: 'object',
+        properties: {}
+    }
+}
+
+async function executeElicitPlanInfo(args, context) {
+    // Make elicitation/create request
+    const result = await context.elicit({
+        message: "Please provide plan information",
+        requestedSchema: {
+            type: "object",
+            properties: {
+                code: { type: "string", description: "Plan code" },
+                description: { type: "string", description: "What to accomplish" },
+                directory: { type: "string", description: "Where to create plan" }
+            },
+            required: ["code", "description"]
+        }
+    });
+    
+    return result;
+}
+```
+
+However, this has drawbacks:
+- Requires the model to know to call this tool
+- Adds an extra step (call tool, then call create)
+- Less integrated with the prompt workflow
+
+## Recommendation
+
+The **prompt arguments + model instructions** approach is the best solution because:
+
+1. **Works today** - Model instructions ensure it works immediately
+2. **Future-proof** - Can be enhanced if clients add argument elicitation
+3. **Clear structure** - Arguments document what's needed
+4. **Flexible** - Users can provide info upfront OR be prompted
+5. **Natural** - Model asks in conversational way, not just forms
+
+## Implementation Status
+
+✅ Added prompt arguments to `create_plan`
+✅ Added template variable substitution
+✅ Added explicit model instructions
+✅ Rebuilt MCP server with changes
+⏳ Waiting for client support for argument elicitation (future enhancement)
+
+## Testing
+
+To test the current implementation:
+
+1. Invoke `create_plan` prompt without arguments
+2. Model should see `[code]`, `[description]`, `[directory]` markers
+3. Model should ask user for missing information
+4. Model should use `riotplan_create` tool with collected info
+
+To test future client elicitation (when supported):
+
+1. Client sees `create_plan` has arguments
+2. Client shows form to collect: code, description, directory
+3. Client invokes prompt with collected values
+4. Model sees actual values, not markers
+5. Model proceeds directly to creating the plan

package/MCP-FIXES.md

@@ -0,0 +1,50 @@
+# MCP Implementation Fixes Needed
+
+## TypeScript Errors to Fix
+
+### 1. Plan.path -> Plan.metadata.path
+- Plan type doesn't have `path` property
+- Use `plan.metadata.path` instead
+
+### 2. PlanStep.file -> PlanStep.filename
+- PlanStep has `filename` not `file`
+
+### 3. PlanState property names
+- `lastCompleted` -> `lastCompletedStep`
+- `lastUpdated` -> `lastUpdatedAt`
+
+### 4. PlanMetadata property names
+- `created` -> `createdAt`
+
+### 5. Blocker[] and Issue[] types
+- StatusResource expects `string[]` but Plan has `Blocker[]` and `Issue[]`
+- Need to convert to strings or update types
+
+### 6. ValidateOptions
+- `fix` property doesn't exist
+- Need to check actual API
+
+### 7. CreatePlanResult
+- Doesn't have `steps` property
+- Check actual return type
+
+### 8. GenerationContext
+- Missing `planName` property
+- Need to provide it
+
+### 9. MCP Build Externals
+- Need to add execution provider packages to externals in build-mcp.js
+
+## Files to Update
+
+1. `src/mcp/resources/plan.ts` - Fix property names
+2. `src/mcp/resources/status.ts` - Fix property names and types
+3. `src/mcp/resources/step.ts` - Fix property names
+4. `src/mcp/resources/steps.ts` - Fix property names
+5. `src/mcp/tools/status.ts` - Fix property names
+6. `src/mcp/tools/step.ts` - Fix property names
+7. `src/mcp/tools/create.ts` - Fix return type handling
+8. `src/mcp/tools/generate.ts` - Fix GenerationContext
+9. `src/mcp/tools/validate.ts` - Fix options
+10. `src/mcp/types.ts` - Update StatusResource type
+11. `scripts/build-mcp.js` - Add externals

package/MCP-PROMPT-FIXES.md

@@ -0,0 +1,207 @@
+# MCP Prompt Fixes
+
+## Problem Summary
+
+The MCP prompts in riotplan were written as user documentation rather than as instructions to the AI model. This caused the model to:
+
+1. **Shell out to CLI commands** instead of using MCP tools
+2. **Not ask about directory placement** for plans
+3. **Treat prompts as documentation** rather than workflow instructions
+
+## Root Cause
+
+The prompt markdown files (`create_plan.md`, `execute_step.md`, `track_progress.md`) were structured as:
+- User-facing documentation explaining how to use the tools
+- Examples showing CLI commands and tool calls
+- Tips and best practices for users
+
+When these prompts were invoked by the model, it interpreted them as documentation to reference rather than instructions to follow.
+
+## Solution
+
+Rewrote all three prompt files to be **instructions TO the model** rather than documentation FOR users:
+
+### Key Changes
+
+1. **Direct Instructions**: Changed from "Users should..." to "You should..."
+2. **Explicit Tool Usage**: Added clear instructions to use MCP tools, not shell commands
+3. **Step-by-Step Workflows**: Provided explicit steps the model should follow
+4. **Directory Guidance**: Added explicit step to ask user about directory placement
+5. **Clear Examples**: Showed the model exactly what tool calls to make
+
+### Files Modified
+
+#### `src/mcp/prompts/create_plan.md`
+
+**Before:**
+```markdown
+## Workflow Steps
+
+1. **Define Plan Details**
+   - Choose a plan code (short identifier, e.g., "auth-system")
+   - Write a clear, detailed description of what you want to accomplish
+```
+
+**After:**
+```markdown
+## Step 1: Gather Information
+
+First, ask the user for the following information if not already provided:
+
+1. **Plan Code** - A short identifier (e.g., "auth-system", "dark-mode", "refactor-db")
+2. **Plan Description** - A clear, detailed description of what they want to accomplish
+3. **Target Directory** - Where to create the plan. Suggest using a `plans/` directory if one exists, or ask if they want to create one. Default to current directory if they don't specify.
+```
+
+Key additions:
+- Explicit instruction to ask about directory
+- Clear guidance on what to suggest
+- Direct instructions to use `riotplan_create` MCP tool
+
+#### `src/mcp/prompts/execute_step.md`
+
+**Before:**
+```markdown
+## Workflow Steps
+
+1. **Check Plan Status**
+   - Run `riotplan_status` to see current state
+   - Verify prerequisites are met
+```
+
+**After:**
+```markdown
+## Step 1: Check Plan Status
+
+Use the `riotplan_status` tool to check the current plan state:
+
+```
+{
+  "path": "${path}",
+  "verbose": false
+}
+```
+
+This will show you:
+- Current step number
+- Progress percentage
+```
+
+Key changes:
+- Direct instructions on which tool to call
+- Exact parameter format
+- Clear explanation of what the tool returns
+
+#### `src/mcp/prompts/track_progress.md`
+
+Similar transformation from documentation to instructions.
+
+## Important Guidelines Added
+
+All prompts now include:
+
+```markdown
+## Important Guidelines
+
+- **Always use MCP tools** - Never shell out to CLI commands
+- **Ask about directory** - Don't assume where the plan should be created
+- **Be specific** - Encourage detailed descriptions for better plan generation
+```
+
+## Testing
+
+After rebuilding with `npm run build`, the updated prompts are now available in:
+- `dist/mcp/prompts/create_plan.md`
+- `dist/mcp/prompts/execute_step.md`
+- `dist/mcp/prompts/track_progress.md`
+
+The MCP server loads these files at runtime and sends them to the model when a prompt is invoked.
+
+## Expected Behavior
+
+When a user invokes the `create_plan` prompt, the model should now:
+
+1. Ask the user for plan details including directory placement
+2. Suggest using a `plans/` directory
+3. Use the `riotplan_create` MCP tool (not shell commands)
+4. Follow up with `riotplan_status` and `riotplan_validate` tools
+5. Inform the user the plan is ready for execution
+
+## Elicitation Support (Added)
+
+After the initial fixes, I added support for MCP prompt arguments to enable better parameter gathering:
+
+### What is MCP Elicitation?
+
+MCP elicitation is a protocol feature that allows servers to request structured data from users dynamically. However, **prompts themselves cannot directly trigger elicitation** - they're static text templates.
+
+### Our Approach
+
+Instead of trying to make prompts trigger elicitation (which isn't possible), we:
+
+1. **Added prompt arguments** to `create_plan`:
+   - `code` - Plan identifier
+   - `description` - What to accomplish
+   - `directory` - Where to create the plan
+   - `steps` - Number of steps (optional)
+
+2. **Template variable substitution**: The prompt template uses `${code}`, `${description}`, etc., which get replaced with either:
+   - The provided argument value, OR
+   - `[code]`, `[description]`, etc. if missing
+
+3. **Explicit instructions**: The prompt tells the model to check for `[code]`, `[description]`, etc. markers and ask the user for missing information.
+
+### Benefits
+
+- **Client-side elicitation**: MCP clients (like Cursor) can see the prompt arguments and potentially elicit them before invoking the prompt
+- **Model-side fallback**: If arguments aren't provided, the model sees `[code]` markers and knows to ask the user
+- **Better UX**: Users can provide information upfront OR be prompted for it
+
+### Code Changes
+
+#### `src/mcp/prompts/index.ts`
+
+Added arguments to the `create_plan` prompt definition:
+
+```typescript
+{
+    name: 'create_plan',
+    description: 'Create a new plan with AI-generated steps for a complex task',
+    arguments: [
+        {
+            name: 'code',
+            description: 'Plan code/identifier (e.g., "auth-system", "dark-mode")',
+            required: false,
+        },
+        // ... more arguments
+    ],
+}
+```
+
+Updated `getPrompt()` to mark missing arguments with `[code]`, `[description]`, etc.
+
+#### `src/mcp/prompts/create_plan.md`
+
+Added Step 1 to review provided information:
+
+```markdown
+## Step 1: Review Provided Information
+
+Check what information has already been provided as prompt arguments:
+- **code**: ${code}
+- **description**: ${description}
+- **directory**: ${directory}
+- **steps**: ${steps}
+
+## Step 2: Gather Missing Information
+
+For any information marked as "[code]", "[description]", "[directory]", or "[steps]", ask the user to provide it:
+```
+
+## Next Steps
+
+1. Test the updated prompts with Cursor
+2. Verify the model now asks about directory placement
+3. Verify the model uses MCP tools instead of shell commands
+4. Test if Cursor's MCP client elicits prompt arguments before invoking the prompt
+5. Consider adding similar explicit instructions to other MCP servers (riotdoc, riotprompt)

package/README.md

@@ -2,6 +2,8 @@
 
 Framework for long-lived, stateful AI workflows (plans).
 
+**Now available as an MCP server!** Integrate with Cursor and other AI assistants - see [MCP Integration](#mcp-integration) below.
+
 ## What is a Plan?
 
 A **plan** is a structured way to manage multi-step AI-assisted tasks that:
@@ -356,6 +358,74 @@ _No issues encountered._
 - `@riotprompt/execution` - LLM provider interfaces
 - `@riotprompt/riotplan-commands-*` - Command packages (plan, status, step, feedback)
 
+## MCP Integration
+
+RiotPlan is available as an MCP (Model Context Protocol) server, allowing AI assistants like Cursor to manage plans directly.
+
+### Setup
+
+Add to your Cursor MCP settings (`~/.cursor/mcp.json`):
+
+```json
+{
+  "mcpServers": {
+    "riotplan": {
+      "command": "npx",
+      "args": ["-y", "@riotprompt/riotplan", "riotplan-mcp"]
+    }
+  }
+}
+```
+
+### MCP Tools
+
+- **`riotplan_create`** - Create new plans with AI-generated steps
+- **`riotplan_status`** - Show plan status and progress
+- **`riotplan_step_list`** - List all steps
+- **`riotplan_step_start`** - Mark step as started
+- **`riotplan_step_complete`** - Mark step as completed
+- **`riotplan_step_add`** - Add new steps dynamically
+- **`riotplan_validate`** - Validate plan structure
+- **`riotplan_generate`** - Generate plan content with AI
+
+### MCP Resources
+
+Read-only access to plan data:
+
+- `riotplan://plan/{path}` - Plan metadata and structure
+- `riotplan://status/{path}` - Current status and progress
+- `riotplan://steps/{path}` - List of all steps
+- `riotplan://step/{path}?number={n}` - Specific step content
+
+### MCP Prompts
+
+Workflow templates for common tasks:
+
+- **`create_plan`** - Guided plan creation workflow
+- **`execute_step`** - Step execution workflow with status tracking
+- **`track_progress`** - Progress monitoring and status updates
+
+### Example MCP Usage
+
+```typescript
+// AI assistant creates a plan
+riotplan_create({
+  code: "user-auth",
+  description: "Implement JWT-based authentication",
+  steps: 6
+})
+
+// Check status
+riotplan_status({ path: "./user-auth" })
+
+// Start and complete steps
+riotplan_step_start({ path: "./user-auth", step: 1 })
+// ... do the work ...
+riotplan_step_complete({ path: "./user-auth", step: 1 })
+```
+
+See [guide/mcp.md](./guide/mcp.md) for detailed MCP documentation.
+
 ## Philosophy
 
 Plans bridge the gap between:
@@ -374,5 +444,3 @@ A plan provides structure for complex, iterative AI-assisted work where:
 Apache-2.0
 
 <!-- v1.0.0 -->
-
-TEST