Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Aug 26, 2025

Summary

This PR addresses Issue #7424 by refactoring the system prompt sections from markdown format to XML format, providing clearer semantic boundaries and better programmatic parsing capabilities.

Changes

Section Format Updates

  • Replaced markdown separators (====) with XML <section name="SECTION_NAME"> tags
  • Updated all section files to use the new XML format:
    • tool-use.ts: Now uses <section name="TOOL USE">
    • modes.ts: Now uses <section name="MODES">
    • capabilities.ts: Now uses <section name="CAPABILITIES">
    • rules.ts: Now uses <section name="RULES">
    • system-info.ts: Now uses <section name="SYSTEM INFORMATION">
    • objective.ts: Now uses <section name="OBJECTIVE">
    • markdown-formatting.ts: Now uses <section name="MARKDOWN RULES">
    • mcp-servers.ts: Now uses <section name="MCP SERVERS">

Tool Description Format Updates

  • Converted all tool descriptions from markdown headers (## toolname) to XML format (<tool name="toolname">)
  • Updated 20+ tool description files including:
    • Core tools: read_file, write_to_file, execute_command, etc.
    • Search tools: search_files, codebase_search, list_files
    • Interaction tools: ask_followup_question, attempt_completion, switch_mode
    • MCP tools: use_mcp_tool, access_mcp_resource
    • And many more...

Test Updates

  • Updated test expectations to match the new XML format
  • Updated all test snapshots to reflect the new structure
  • All tests are passing

Benefits

  1. Better Semantic Structure: XML tags provide clear semantic boundaries between different types of content
  2. Easier Parsing: XML structure is easier to programmatically parse and manipulate than markdown separators
  3. Improved Validation: XML format allows for better structure validation
  4. Consistency: All sections and tools now follow a consistent XML-based format
  5. Future-proof: Easier to extend with additional attributes or nested structures if needed

Testing

  • ✅ All unit tests pass
  • ✅ Linting passes
  • ✅ Type checking passes
  • ✅ Backward compatibility maintained (functionality unchanged, only format updated)

Important Note

As mentioned in the issue, the tool call functionality (which uses XML tags like <tool_name>) was NOT touched - only the system prompt structure was refactored.

Fixes #7424


Important

Refactor system prompt sections and tool descriptions from markdown to XML format for improved semantic clarity and parsing, updating test snapshots accordingly.

  • Behavior:
    • Refactor system prompt sections from markdown to XML format for better semantic clarity and parsing.
    • Update test snapshots in system-prompt.spec.ts to reflect XML structure.
  • Tool Descriptions:
    • Convert tool descriptions from markdown headers to XML format in over 20 files, including read_file, write_to_file, execute_command, etc.
  • Testing:
    • Update test expectations and snapshots to match XML format.
    • All tests pass, ensuring backward compatibility.

This description was created by Ellipsis for 8d869dc. You can customize this summary. It will automatically update as commits are pushed.

- Replace markdown separators (====) with XML <section> tags
- Update all section files to use <section name='SECTION_NAME'> format
- Convert tool descriptions from ## toolname to <tool name='toolname'> format
- Maintain backward compatibility with existing functionality
- Improve semantic structure for better parsing and validation

This change provides clearer semantic boundaries between different types of content
and makes the prompt structure easier to programmatically parse and manipulate.
- Update test expectations from markdown format (## toolname) to XML format (<tool name='toolname'>)
- Update snapshots to reflect new XML-based section and tool structures
Copy link
Contributor Author

@roomote roomote bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing my own code is like debugging in a mirror - everything looks backward but the bugs are still mine.

IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
return `<tool name="attempt_completion">
<description>After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.</description>
<important>This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.</important>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intentional? I notice this tool uses an <important> tag for critical notes while other tools embed important information directly in the <description> tag. Could we consider standardizing this approach across all tools for consistency?

For example, other tools include warnings like "IMPORTANT: You can read a maximum of 5 files..." directly in the description, but here we have a separate <important> tag.

Description: Request to interact with a Puppeteer-controlled browser. Every action, except \`close\`, will be responded to with a screenshot of the browser's current state, along with any new console logs. You may only perform one browser action per message, and wait for the user's response including a screenshot and logs to determine the next action.
return `<tool name="browser_action">
<description>Request to interact with a Puppeteer-controlled browser. Every action, except \`close\`, will be responded to with a screenshot of the browser's current state, along with any new console logs. You may only perform one browser action per message, and wait for the user's response including a screenshot and logs to determine the next action.</description>
<important>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to my comment on attempt-completion.ts - this tool uses both <description> and <important> tags, creating a mixed content structure. While this provides good separation of concerns, it differs from the pattern used in most other tools.

Could we consider either:

  1. Moving all tools to use the <important> tag pattern for consistency, or
  2. Embedding the important notes in the description like other tools do?

@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Aug 26, 2025
@daniel-lxs daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Aug 27, 2025
@hannesrudolph hannesrudolph added PR - Needs Preliminary Review and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Aug 27, 2025
@daniel-lxs daniel-lxs marked this pull request as draft August 30, 2025 19:52
@daniel-lxs daniel-lxs moved this from PR [Needs Prelim Review] to PR [Draft / In Progress] in Roo Code Roadmap Aug 30, 2025
@github-project-automation github-project-automation bot moved this from PR [Draft / In Progress] to Done in Roo Code Roadmap Sep 22, 2025
@github-project-automation github-project-automation bot moved this from New to Done in Roo Code Roadmap Sep 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request PR - Draft / In Progress size:L This PR changes 100-499 lines, ignoring generated files.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

[ENHANCEMENT] Wrap system prompt sections and tool docs in dedicated XML tags for reliable parsing

3 participants