diff --git a/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml b/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml new file mode 100644 index 0000000000..8ba9dbed66 --- /dev/null +++ b/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml @@ -0,0 +1,240 @@ + + + XML tags help LLMs parse prompts more accurately, leading to higher-quality outputs. + This guide covers best practices for structuring mode instructions using XML. + + + + + Clearly separate different parts of your instructions and ensure well-structured content + + + Reduce errors caused by the model misinterpreting parts of your instructions + + + Easily find, add, remove, or modify parts of instructions without rewriting everything + + + Having the model use XML tags in its output makes it easier to extract specific parts of responses + + + + + + Use the same tag names throughout your instructions + + Always use for workflow steps, not sometimes or + + + + + Tag names should clearly describe their content + + detailed_steps + error_handling + validation_rules + + + stuff + misc + data1 + + + + + Nest tags to show relationships and structure + + + + Gather requirements + Validate inputs + + + Process data + Generate output + + + + + + + + + For step-by-step processes + + + + + For providing code examples and demonstrations + + + + + For rules and best practices + + + + + For documenting decision criteria and guardrails + + + + + + + Use consistent indentation (2 or 4 spaces) for nested elements + + + Add line breaks between major sections for readability + + + Use XML comments to explain complex sections + + + Use CDATA for code blocks or content with special characters: + your code here + + + Use attributes for metadata, elements for content: + + + The actual step content + + + + + Keep narrative outputs concise; reserve detailed exposition for code, diffs, and structured outputs. Prefer readable, maintainable code with clear names; avoid one-liners unless explicitly requested. + + + + + + Avoid completely flat structures without hierarchy + + + +Do this + +Then this + +Finally this + + + + + + + Do this + Then this + Finally this + + + + + + + Don't mix naming conventions + + Mixing camelCase, snake_case, and kebab-case in tag names + + + Pick one convention (preferably snake_case for XML) and stick to it + + + + + Avoid tags that don't convey meaning + data, info, stuff, thing, item + user_input, validation_result, error_message, configuration + + + Avoid asking the user to confirm obvious next steps on straightforward tasks + Asking multiple clarifying questions before acting when the task is simple + Proceed when next steps are clear; ask only when critical ambiguity remains; document assumptions + + + + Avoid repetitive or redundant searches when the relevant target is already identified + Running multiple identical searches instead of acting + Stop once the change is clearly identified; then implement + + + + Avoid duplicating runtime behavior that is already defined elsewhere + Documenting execution constraints, operation ordering, or invocation details + Focus on intent, artifacts, decision criteria, and validation expectations + + + + + + Reference XML content in instructions: + "Using the workflow defined in <workflow> tags..." + + + Combine XML structure with other techniques like multishot prompting + + + Use XML tags in expected outputs to make parsing easier + + + Create reusable XML templates for common patterns + + +