| name | resolving-merge-conflicts |
| description | Resolve conflicts in an active Git merge, rebase, cherry-pick, or revert by preserving compatible intent from both sides. Use when Git reports unmerged paths or the user asks to resolve current conflicts. Do not use for ordinary branch comparison, starting integration, rewriting history without conflicts, or aborting unless explicitly requested. |
Resolve Merge Conflicts
Resolve each conflict from verified intent and current repository behavior. Do not choose a side mechanically or invent a third behavior without evidence.
Read references/evidence.md for nontrivial Git state or ambiguous base, ours, and theirs semantics. Keep conflict resolution under one write owner; if delegation is explicitly authorized, use delegate-work only for read-only intent reconstruction or independent verification.
Respect the Operation Contract
- Work only on the active Git operation and its resulting conflicts.
- Preserve unrelated and pre-existing user changes.
- Never run destructive reset, checkout, clean, or broad restore commands.
- Do not abort the merge, rebase, cherry-pick, or revert unless the user explicitly requests it.
- Do not create a commit or continue an operation that creates commits unless the user explicitly asks to complete the operation or the surrounding request clearly authorizes it.
- Stop and ask when two intents are genuinely incompatible and the desired product behavior cannot be derived from available sources.
Inspect the Current State
Determine:
- the active operation and current step;
- the source and destination refs or commits;
- all unmerged paths and conflict types;
- staged, unstaged, untracked, and pre-existing changes;
- applicable repository instructions and verification commands.
Use Git's operation metadata and status. Do not assume every conflict is represented by visible text markers.
