cmd-pr-conflict-resolver

Files (1)

• SKILL.md

SKILL.md (first lines)

# Resolve Merge Conflicts <!-- omit in toc -->

Your job is to resolve merge conflicts in the current branch using a structured, context-aware approach. You resolve what you can confidently, explain your reasoning for non-trivial resolutions, and escalate when the correct behavior is ambiguous.

- [1. Verify State](#1-verify-state)
- [2. Map All Conflicts](#2-map-all-conflicts)
- [3. Build Context Per Conflict](#3-build-context-per-conflict)
  - [3a. Read the full file](#3a-read-the-full-file)
  - [3b. Trace commit history on both sides](#3b-trace-commit-history-on-both-sides)
  - [3c. Examine surrounding code](#3c-examine-surrounding-code)
  - [3d. Check cascading implications](#3d-check-cascading-implications)
  - [3e. Assess business logic impact](#3e-assess-business-logic-impact)
- [4. Classify Each Conflict (3-Tier System)](#4-classify-each-conflict-3-tier-system)
- [5. Resolve by Tier](#5-resolve-by-tier)
  - [Tier 1: Auto-resolve](#tier-1-auto-resolve)
  - [Tier 2: Resolve with type-specific guidance](#tier-2-resolve-with-type-specific-guidance)
  - [Tier 3: Escalate](#tier-3-escalate)
  - [New code escalation](#new-code-escalation)
- [6. Verify and Stage](#6-verify-and-stage)
- [7. Reflection and Handoff](#7-reflection-and-handoff)

## 1. Verify State

Assume I already ran `git merge` and there are unresolved conflicts.

- Run `git status` to confirm conflicts exist
- Identify the merge target via `git rev-parse MERGE_HEAD` (or `REBASE_HEAD` / `CHERRY_PICK_HEAD` as applicable)
- Run a baseline diff between both sides, excluding lock/generated files:

```bash
git diff MERGE_HEAD...HEAD -- ":(exclude)*.lock" ":(exclude)package-lock.json" ":(exclude)pnpm-lock.yaml"
```

This gives you the big picture before touching individual conflicts.

## 2. Map All Conflicts

Inventory every conflict before resolving any of them.

```bash
git diff --name-only --diff-filter=U
```

```bash
rg "<<<<<<< " --line-number
```

- Create a task list with one entry per conflict chunk, grouped by file
- Note patterns across the conflict set:
  - Same subsystem? Paired changes? Generated files?
  - How many conflicts total? Are they concentrated or spread across the codebase?

## 3. Build Context Per Conflict

For **each** conflict, before classifying or resolving:

### 3a. Read the full file

Not just the markers. Understand the function/block's role in the file.

### 3b. Trace commit history on both sides

```bash
git log --oneline MERGE_HEAD -- <file>
git log --oneline HEAD -- <file>
```

Read commit messages and diffs to understand **intent** on each side.

### 3c. Examine surrounding code

Read 20-40 lines around the conflict. Identify invariants:

- Ordering conventions (alphabetical imports, specificity-ordered routes)
- Uniqueness constraints (no duplicate keys, no duplicate enum variants)
- Completeness requirements (exhaustive match arms, full registry lists)
- Check for related test files that may clarify expected behavior

### 3d. Check cascading implications

If the conflict is in a signature, type, constant, or export:

```bash
rg "<symbol_name>" --type-add 'src:*.{ts,py,go,rs,java}' -t src
```

Find all usages to identify downstream impact.

### 3e. Assess business logic impact

Answer three questions for each conflict:

1. **Scope**: Mechanical (formatting/imports/whitespace) or runtime behavior change?
2. **Risk**: If resolved wrong, what breaks? (nothing / tests / production / data integrity)
3. **Novelty**: Both sides added new behavior? Or one cleanly supersedes the other?

## 4. Classify Each Conflict (3-Tier System)

| Tier                                    | When                                                                                                                                                    | Action                                                                                                                                     |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Tier 1 -- Auto-resolve**              | Non-overlapping additions, formatting-only, one side is strict superset, lock/generated files                                                           | Resolve immediately. No developer input needed.                                                                                            |
| **Tier 2 -- Resolve + state rationale** | Intent is inferable from context, combining both is clearly right but requires care, test file conflicts                                                | Resolve, then present rationale (see format below). Don't block on confirmation.                                                           |
| **Tier 3 -- Escalate before resolving** | Can't determine correct behavior from context, critical path code, silent behavior discard, architectural divergence, cascading multi-file implications | **Stop.** Show conflict, explain both sides' intent, state the ambiguity, offer 2-3 options with trade-offs. Wait for developer direction. |

**Tier 2 rationale format:**

> Resolved `file:line`. [How]. Rationale: [why]. Flag if wrong.

**Key balance**: Tier 1 keeps you decisive. Tier 3 keeps you consultative when it matters. Tier 2 handles the middle ground -- resolve but make reasoning visible.

## 5. Resolve by Tier

### Tier 1: Auto-resolve

- Edit the file to the desired final state
- Remove all conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
- Verify the result is syntactically clean

### Tier 2: Resolve with type-specific guidance

From Olshansk/agent-skills, MIT.

More from Olshansk/agent-skills