{# ============================================================================ #}
{# Template: conflict_resolution.txt #}
{# Version: 1.3 #}
{# ============================================================================ #}
{# #}
{# PURPOSE: #}
{# Prompt for resolving merge conflicts during an automated git workflow. #}
{# Agent receives conflicted files and must resolve them by editing files. #}
{# #}
{# WHEN USED: #}
{# When merge conflicts are detected during an automated pipeline phase. #}
{# #}
{# TRIGGER: #}
{# Git operation: merge conflict detection while applying edits. #}
{# #}
{# VARIABLES: #}
{# CONTEXT - Formatted section with PROMPT.md and PLAN.md content #}
{# CONFLICTS - Formatted section showing conflicted files #}
{# #}
{# OUTPUT: #}
{# Primary: Edit files on disk to remove conflict markers #}
{# Optional: JSON object with "resolved_files" mapping paths to content #}
{# #}
{# NOTES: #}
{# - Agent MUST NOT know the precise git operation that triggered the conflict #}
{# - Prompt frames conflicts as "merge conflicts" without tying them to a #}
{# specific operation #}
{# - File edits are validated for conflict marker removal #}
{# - Resolution is verified with syntax checks and git state #}
{# ============================================================================ #}
# MERGE CONFLICT RESOLUTION
{{> shared/_unattended_mode}}
{{> shared/_no_git_commit}}
There are merge conflicts that need to be resolved. Below are the files with conflicts, showing both versions of the conflicting changes.
{{CONTEXT}}
## Conflict Resolution Instructions
PRIMARY GOAL: Resolve ALL merge conflicts by editing the files on disk.
**IMPORTANT**: Your resolution will be validated automatically. Failure to properly resolve conflicts will require additional attempts.
### Understanding the Conflict Markers
In the conflicted files below, you will see conflict markers:
- `<<<<<<<` marks the start of a conflict
- `=======` separates the two versions
- `>>>>>>>` marks the end of a conflict
The sections represent different versions of the same code:
- The section between `<<<<<<<` and `=======` contains your changes (the feature branch)
- The section between `=======` and `>>>>>>>` contains changes from the main branch
### Resolution Strategy
For each conflicted file:
1. **Analyze Both Versions**: Understand what each version is trying to accomplish
- Your changes: The work you were doing for this task
- Main branch changes: Updates that were made to the default branch
2. **Intelligent Merge**: Combine both versions when appropriate:
- If both versions change different parts of the code, include both changes
- If both versions change the same code differently, determine which approach is correct
- Preserve semantic intent from both versions when possible
- Consider the task context and implementation plan above
3. **Handle Special Cases**:
- **Add/Add conflicts**: Both sides added the same file - merge the content
- **Modify/Delete conflicts**: One side modified, the other deleted - decide based on task needs
- **Rename conflicts**: Files were renamed - preserve the rename and merge content
4. **Validate Your Resolution** (CRITICAL):
- Ensure ALL conflict markers are removed (<<<<<<<, =======, >>>>>>>)
- Verify the code is syntactically correct
- Check that imports and dependencies are consistent
- Ensure no duplicate code or leftover merge artifacts
- **Your resolution will be automatically validated**
5. **Edit the File**: Use the Edit tool to modify each conflicted file on disk
**CRITICAL REMINDERS**:
- Remove ALL conflict markers - the file must not contain `<<<<<<<`, `=======`, or `>>>>>>>`
- Preserve the intent of BOTH sides when they serve different purposes
- The goal is a clean, working merge - not just "picking one side"
- **Partial resolutions will be detected and will require retries**
### Conflict Types and Guidance
**Content Conflicts** (same lines modified differently):
- Analyze which version is correct for the current task
- Often the best approach combines both changes
- Consider if main branch changes fix bugs or add features you need
**Add/Add Conflicts** (same file added on both sides):
- Both versions have value - merge them intelligently
- Look for duplicate functionality and consolidate
- Ensure imports and structures are compatible
**Modify/Delete Conflicts** (one side deleted, other modified):
- If the main branch deleted code, consider whether it's still needed
- If you need the modified code, keep it
- Document why you kept/removed code in comments if unclear
## Conflicted Files
{{CONFLICTS}}
## Optional JSON Output Format
If you choose to provide JSON output (optional), use this format to confirm your resolutions:
```json
{
"resolved_files": {
"path/to/file1": "<complete resolved file content>",
"path/to/file2": "<complete resolved file content>"
}
}
```
Each resolved file should contain the COMPLETE file content, not just the changed sections. The content must be free of conflict markers.
**Note**: If you cannot resolve a particular conflict, you may mark it for manual resolution by omitting it from the resolved_files object. However, you should attempt to resolve all conflicts whenever possible.
## Validation Checklist
Your resolution will be validated against the following criteria:
- [ ] No conflict markers remain in any file (`<<<<<<<`, `=======`, `>>>>>>>`)
- [ ] Code is syntactically valid (balanced brackets, valid syntax)
- [ ] Git reports no conflicted files
- [ ] Files were actually modified (not left unchanged)
If validation fails, you will be asked to retry with additional context about what went wrong.