cmd-pr-conflict-resolver

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Resolve Merge Conflicts

解决合并冲突

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
2. Map All Conflicts
3. Build Context Per Conflict
4. Classify Each Conflict (3-Tier System)
5. Resolve by Tier
6. Verify and Stage
7. Reflection and Handoff

你的任务是使用结构化的、上下文感知的方法解决当前分支的合并冲突。你可以解决你有十足把握的冲突，针对非简单解决的冲突要解释你的推理逻辑，当正确行为不明确时要升级问题。

1. 验证状态
2. 梳理所有冲突
3. 为每个冲突构建上下文
4. 为每个冲突分类（三层体系）
5. 按层级解决
6. 验证和暂存
7. 复盘和移交

1. Verify State

1. 验证状态

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.

假设我已经运行了

git merge

，现在存在未解决的冲突。

运行
```
git status
```
确认冲突存在
通过
```
git rev-parse MERGE_HEAD
```
识别合并目标（根据场景也可以是
```
REBASE_HEAD
```
/
```
CHERRY_PICK_HEAD
```
）
运行两边的基准diff，排除锁文件/生成文件：

bash

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

这会在你处理单个冲突之前给你全局的概览。

2. Map All Conflicts

2. 梳理所有冲突

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?

在解决任何冲突之前先清点所有冲突。

bash

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

bash

rg "<<<<<<< " --line-number

创建任务列表，每个冲突块对应一个条目，按文件分组
记录冲突集合中的规律：
- 属于同一个子系统？成对的改动？生成文件？
- 总共有多少个冲突？是集中分布还是分散在整个代码库？

3. Build Context Per Conflict

3. 为每个冲突构建上下文

For each conflict, before classifying or resolving:

针对每个冲突，在分类或解决之前：

3a. Read the full file

3a. 读取完整文件

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

不要只看冲突标记，理解文件中该函数/代码块的作用。

3b. Trace commit history on both sides

3b. 追溯两边的提交历史

bash

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

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

bash

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

读取提交信息和diff，理解两边改动的意图。

3c. Examine surrounding code

3c. 检查周边代码

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

读取冲突周边20-40行的代码，识别不变规则：

排序约定（导入按字母排序、路由按特异性排序）
唯一性约束（无重复key、无重复枚举值）
完整性要求（穷尽的匹配分支、完整的注册列表）
检查相关的测试文件，可能会澄清预期行为

3d. Check cascading implications

3d. 检查级联影响

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.

如果冲突出现在签名、类型、常量或导出中：

bash

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

找到所有使用位置，识别下游影响。

3e. Assess business logic impact

3e. 评估业务逻辑影响

Answer three questions for each conflict:

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

为每个冲突回答三个问题：

范围：是机械性改动（格式/导入/空格）还是运行时行为变更？
风险：如果解决错误，会破坏什么？（无影响/测试/生产/数据完整性）
新颖度：两边都添加了新行为？还是其中一方的改动明显覆盖另一方？

4. Classify Each Conflict (3-Tier System)

4. 为每个冲突分类（三层体系）

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.

层级	适用场景	操作
层级1 -- 自动解决	非重叠的新增内容、仅格式改动、一方改动是严格超集、锁/生成文件	立即解决，无需开发者输入。
层级2 -- 解决 + 说明理由	可以从上下文推断出意图，合并两边的改动显然是正确的但需要谨慎处理、测试文件冲突	解决，然后展示理由（见下方格式），不需要等待确认。
层级3 -- 解决前升级	无法从上下文判断正确行为、核心路径代码、会静默丢弃行为、架构分歧、多文件级联影响	停止操作。展示冲突，解释两边的意图，说明模糊点，提供2-3个带权衡的选项，等待开发者指示。

层级2理由格式：

已解决
file:line
。[解决方式]。理由：[为什么这么解决]。如有错误请标记。

关键平衡：层级1让你保持决策效率，层级3让你在关键问题上保持协商性，层级2处理中间地带——解决问题但公开推理逻辑。

5. Resolve by Tier

5. 按层级解决

Tier 1: Auto-resolve

层级1：自动解决

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

层级2：按类型特定指引解决

Apply the right merge strategy based on the construct type:

Lists/registries (imports, exports, routes, enum variants):

Union both sides, deduplicate
Maintain the file's existing ordering convention (alphabetical, grouped, etc.)

Function bodies (both added branches/conditions):

Include all additions
Respect ordering by specificity (more specific before more general)

Config/struct (both added keys):

Merge all keys
If the same key has different values, escalate to Tier 3

Parallel new code (both added new functions/classes):

Include both
Order consistently with the file's existing conventions

After combining: Re-read the result as a human would. Check for:

Duplicated side effects
Broken invariants (ordering, uniqueness, completeness)
Mismatched types or signatures

根据构造类型应用正确的合并策略：

列表/注册表（导入、导出、路由、枚举值）：

合并两边的内容，去重
保持文件现有的排序约定（字母序、分组等）

函数体（两边都添加了分支/条件）：

包含所有新增内容
遵循特异性排序规则（更具体的在前，更通用的在后）

配置/结构体（两边都添加了key）：

合并所有key
如果同一个key有不同的值，升级到层级3

并行新代码（两边都添加了新函数/类）：

两边的内容都保留
按照文件现有约定保持一致的排序

合并之后：以人工视角重读结果，检查：

重复的副作用
破坏了不变规则（排序、唯一性、完整性）
不匹配的类型或签名

Tier 3: Escalate

层级3：升级问题

Show me the conflicting chunks with surrounding context
Explain what each side intended (based on commit history from step 3b)
State the specific ambiguity ("Both sides modify the retry logic but with different strategies")
Offer 2-3 resolution options with trade-offs
Wait for my direction before editing

After receiving direction:

Restate your plan in one sentence before editing
Re-evaluate remaining Tier 2 conflicts if new context was revealed

向我展示冲突块及周边上下文
解释两边的意图（基于步骤3b获取的提交历史）
说明具体的模糊点（“两边都修改了重试逻辑但采用了不同的策略”）
提供2-3个带权衡的解决选项
编辑前等待我的指示

收到指示后：

编辑前用一句话重述你的计划
如果出现了新的上下文，重新评估剩余的层级2冲突

New code escalation

新代码升级

When neither side's code is complete and the right answer is a third implementation (not just combining both):

Flag it explicitly with a 3-5 bullet plan describing the proposed implementation
Wait for approval before writing

当两边的代码都不完整，正确的答案是第三种实现（而非简单合并两边）时：

用3-5条要点明确标记，描述提议的实现计划
编写前等待审批

6. Verify and Stage

6. 验证和暂存

After all conflicts are resolved:

bash

rg "<<<<<<< "

Confirm zero remaining conflict markers.

Run lint/type-check if fast (skip slow integration tests)
Stage resolved files individually:
```
git add <specific_files>
```
-- not
```
git add .
```
Do not commit -- leave that to me

所有冲突解决后：

bash

rg "<<<<<<< "

确认没有剩余的冲突标记。

如果速度够快就运行lint/类型检查（跳过慢的集成测试）
逐个暂存已解决的文件：
```
git add <specific_files>
```
-- 不要用
```
git add .
```
不要提交 -- 留给我来操作

7. Reflection and Handoff

7. 复盘和移交

Provide a summary table:

File	Line(s)	Tier	Resolution
...	...	1/2/3	Brief description

Flag any of the following:

Tier 2 resolutions where your confidence was lower than usual
Cascading implications found during step 3d
Architectural divergence detected between the two sides
Files that weren't in the conflict set but may be affected by the merge

Closing question: Are there areas of the codebase this merge could affect that aren't in the conflict markers?

提供总结表格：

文件	行号	层级	解决方式
...	...	1/2/3	简短描述

标记以下任何情况：

你信心低于常规水平的层级2解决结果
步骤3d中发现的级联影响
两边检测到的架构分歧
不在冲突集合中但可能受合并影响的文件

收尾问题：本次合并可能影响代码库中哪些不在冲突标记中的区域？