Reference · Model-invoked · Standalone（git 收尾）

resolving-merge-conflicts 速查

按意图解冲突、把 merge / rebase 干到完成的口袋版。完整教学见 Lesson 0018； 原文见 SKILL.md（全部规范仅 14 行）、 docs 叙事版。

一句话

git 因冲突停在半途时进场：逐个 hunk（冲突块）按意图而非文本解—— 两侧追回到 primary source（commit message / PR / 原始 Issue），能兼顾就兼顾， 互斥就选符合合并既定目标的一边并说出取舍；跑完项目检查，把这次操作解到完成、提交落好。

何时伸手

何时别伸手

三条红线（SKILL.md 第 3 步）

  1. Preserve both intents where possible——「选一边」是最后手段，不是默认动作
  2. Do not invent new behaviour——结果里不许出现两条分支都不存在的逻辑（折中新实现＝违规）
  3. Always resolve; never --abort——永远解到底，永不中止

五步流程卡

步做什么要点
1看清现场merge 还是 rebase？卡在哪些文件、哪几个 hunk？只看不动手
2找一手来源每个冲突两侧追回 commit message、PR、原始 Issue；能一句话说出「这边想要什么」
3逐个 hunk 解先问能否兼顾；互斥则对准入合并目标选边、说出 trade-off；不发明、不中止
4跑项目检查典型顺序 typecheck → tests → format；合并碰坏的修到绿
5收尾stage 全部并 commit；rebase 则 continue 到所有 commit 过完，中途再撞冲突就回第 1 步

漏斗纪律：第 1–2 步只读不写，第 3 步才动文件，第 4–5 步验证并封存。 走样先问「是不是跳步了」——最常见是跳过第 2 步、省略第 4 步。

按意图解 · 两个典型

副作用（会改什么）

对象怎么动
冲突文件内容改写：去标记，写入解好的内容（第 3 步）
冲突外的源码可能改写：检查跑红时修到绿（第 4 步）
git 暂存区 / 历史stage + 落 commit；rebase 整串过完（第 5 步）——它的交付物
commit message / PR / Issue tracker只读，作为一手来源
CONTEXT.md / ADR / docs / 报告绝不碰，无文档类交付物

It's working if（docs 验收四条）

  1. 每个解好的 hunk 保住了两边的行为，或在保不住时说清了取舍
  2. 没有出现两条分支上都不存在的新行为
  3. 项目自己的检查（typecheck、tests、format）被找到并跑绿，然后才提交
  4. merge / rebase 被一路带到完成的 commit，从未中止

下一步

微调入口（症状 → 改哪里）

症状改
闭眼选边、语义解坏SKILL.md 第 2、3 步（先读一手来源、按意图兼顾）
解出两边都没有的新逻辑SKILL.md 第 3 步 “Do not invent new behaviour.”
冲突一多就 abortSKILL.md 第 3 步末 “Always resolve; never --abort.”
不跑检查就提交SKILL.md 第 4 步（检查顺序 + fix anything the merge broke）
rebase 留个半完成状态SKILL.md 第 5 步（continue until all commits are rebased）
模型从不自动加载frontmatter 的 description（“Use when…” 那句）
Codex 显示名不对agents/openai.yaml 的 interface 块
想进 ask-matt 地图ask-matt/SKILL.md Standalone 一节（目前未收录，AGENTS.md 要求同步）