Templates and examples for creating XML instruction files that provide
detailed guidance for each mode's behavior and workflows.
Requirements:
- Do not reference runtime implementation details (function names, command names, UI entry points, or execution syntax).
- Do not duplicate operational policies that are already defined by the runtime/system prompt.
- Focus on workflow intent, required artifacts, decision criteria, and validation expectations.
Number files to indicate execution order
Use descriptive names that indicate content
Keep related instructions together
1_workflow.xml - Main workflow and processes
2_best_practices.xml - Guidelines and conventions
3_common_patterns.xml - Reusable code patterns
4_decision_guidance.xml - Decision criteria and guardrails
5_examples.xml - Complete workflow examples
6_error_handling.xml - Error scenarios and recovery
7_communication.xml - User interaction guidelines
Template for main workflow files (1_workflow.xml)
Brief description of what this mode does and its primary purpose
Understand the user's request
Parse the user's input to identify:
- Primary objective
- Specific requirements
- Constraints or limitations
Gather necessary context
Review the minimal set of repository materials needed to act safely.
Prefer extending existing guidance over introducing duplicated rules.
Analyze the current state and requirements
Identify affected components
Assess impact of changes
Plan implementation approach
Execute the planned changes
Create/modify necessary files
Ensure consistency across codebase
Add appropriate documentation
Verify the implementation
Check for errors or inconsistencies
Validate against requirements
Ensure no regressions
All requirements have been addressed
Code follows project conventions
Changes are properly documented
No breaking changes introduced
Template for best practices files (2_best_practices.xml)
Principle Name
Detailed explanation of the principle
Why this principle is important
When this applies
Correct approach
What to avoid
Specific naming convention
goodExampleName
bad_example-name
How to structure code/files
// Example structure
Common mistake to avoid
Explanation of issues it causes
How to do it properly
- Understand requirements fully
- Check existing implementations
- Follow established patterns
- Write clear documentation
- Review all changes
- Verify requirements met
Template for decision criteria and guardrails (4_decision_guidance.xml)
Do not include runtime implementation details (no function names, command names, UI entry points, or execution syntax)
Prefer the smallest change that satisfies the request
Prefer a single source of truth; avoid duplicated rules across files
Ask a clarifying question only when critical ambiguity remains
Define clear responsibilities and explicit handoff points to other modes
After changes, scan for contradictions and update examples to match
Template for example files (5_examples.xml)
Detailed description of the use case this example covers
The initial request from the user
First step description
Identify the relevant existing files/sections that need to change.
Outcome: a shortlist of candidate paths or sections.
What we learn from this step
Second step description
Review the top candidates and confirm the exact area to modify.
Outcome: precise target sections and constraints.
How we interpret the results
Implementation step
Apply the planned changes (localized edits when possible; full rewrites only when intentional).
Outcome: required changes applied to the repository.
Provide a concise summary of what was accomplished and how it addresses the user's request.
Important lesson from this example
Pattern that can be reused
Template for communication guidelines (7_communication.xml)
Be direct and technical, not conversational
Focus on actions taken and results achieved
Great! I'll help you with that...
Certainly! Let me...
Sure thing!
I'll analyze the codebase to...
Implementing the requested changes...
The analysis shows...
Keep narrative brief; prefer concise status updates
Provide high detail only inside code/diffs and structured outputs
Favor clarity over cleverness; avoid code-golf and cryptic names
Missing critical information
Multiple valid approaches exist
Potential breaking changes
Be specific about what you need
Provide actionable options
Explain implications of choices
During long-running operations
Analyzing [X] files for [purpose]...
Implementing [feature] in [location]...
Validating changes against [criteria]...
What was accomplished
Key changes made
Any important notes or warnings
Questions at the end
Offers for further assistance
Conversational closings