Replace fetch_instructions tool with unified skill tool system

[hannesrudolph]

Problem

The fetch_instructions tool is a separate mechanism for loading just-in-time instructions for tasks like creating MCP servers or custom modes. This creates unnecessary complexity because:

• Instructions loaded via fetch_instructions don't follow the same override pattern as user-defined skills (project > global)
• Users have to manage a separate "Enable MCP Server Creation" toggle setting
• The codebase maintains two different mechanisms for delivering instructions to the agent

Impact

• Users have an extra setting to configure that doesn't integrate with the skills system they may already be using
• Developers maintaining user-defined skills cannot override built-in instructions for creating modes or MCP servers
• Codebase complexity is increased by having parallel instruction delivery systems

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Problem Summary

The fetch_instructions tool is a separate mechanism from the skills system for delivering just-in-time instructions. This creates:

• Parallel instruction delivery systems
• No way for users to override built-in instructions (unlike skills which support project > global override)
• An extra enableMcpServerCreation toggle setting

Current Architecture

fetch_instructions system:

• Tool definition: src/core/prompts/tools/native-tools/fetch_instructions.ts
• Tool handler: src/core/tools/FetchInstructionsTool.ts
• Instructions: src/core/prompts/instructions/instructions.ts (switch on task name)
• Hardcoded tasks: create_mcp_server, create_mode

Skills system:

• SkillsManager: src/services/skills/SkillsManager.ts
• Discovery: .roo/skills/ and .roo/skills-{mode}/ directories
• Override pattern: project > global, mode-specific > generic
• Format: SKILL.md with YAML frontmatter (name, description)

Proposed Solution

Convert fetch_instructions tasks to built-in skills that integrate with the existing skills system:

1. Create Built-in Skills

Create SKILL.md files for the two current tasks:

• .roo/skills/create-mcp-server/SKILL.md
• .roo/skills/create-mode/SKILL.md

These will contain the same content currently in:

• src/core/prompts/instructions/create-mcp-server.ts
• src/core/prompts/instructions/create-mode.ts

2. Handle Dynamic Content

The MCP server instructions contain dynamic paths (e.g., mcpHub.getMcpServersPath()). Options:

• Option A: Use placeholder variables in SKILL.md that get replaced at runtime
• Option B: Keep a minimal TypeScript wrapper that injects dynamic values into the skill content
• Option C: Store the path in environment/context and reference it generically

3. Remove Deprecated Code

• Remove fetch_instructions tool definition and handler
• Remove enableMcpServerCreation setting (skill presence controls availability)
• Remove src/core/prompts/instructions/ directory
• Update modes section to remove fetch_instructions references

4. Update System Prompt

The existing skills section already instructs the agent to check available skills and read SKILL.md files when applicable. No additional system prompt changes needed.

Benefits

• Single unified system for instruction delivery
• Users can override built-in instructions by creating project-level skills with the same name
• Developers can contribute new skills through the established pattern
• Cleaner codebase with one mechanism instead of two
• enableMcpServerCreation toggle becomes unnecessary (controlled by skill presence)

Questions for Clarification

1. Dynamic content handling: The MCP server instructions include runtime values like mcpHub.getMcpServersPath(). Would you prefer:

   • (A) Template variables in SKILL.md (e.g., {{MCP_SERVERS_PATH}}) replaced at runtime
   • (B) A TypeScript wrapper that generates the final skill content
   • (C) Generic paths that work without runtime injection

2. Backward compatibility: Should we maintain the fetch_instructions tool temporarily with a deprecation warning, or remove it completely?

3. enableMcpServerCreation setting: Should removing this setting require a migration, or can it simply be removed (defaulting to enabled)?

Please mention @roomote in a comment with your preferences, and I'll proceed with the implementation.