Cursor Team Kit 合并冲突解决实战从冲突检测到可构建状态的标准化非交互式流程【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins导读在多人协作的 Git 仓库中合并冲突merge conflict是无法回避的日常场景而冲突解决质量直接决定后续 CI、代码评审与发布流程能否顺利推进。Cursor Team Kit 插件的fix-merge-conflicts技能定义了一套非交互式、以最小改动 正确性优先 可构建状态为核心目标的标准化解冲突流程从冲突检测、逐文件裁决到 lockfile 重新生成、编译/测试验证再到暂存与决策总结全程不需要人工反复打开编辑器手工拉扯冲突标记。读完本文你将掌握该技能在 cursor-team-kit/skills/fix-merge-conflicts/SKILL.md 中定义的完整工作流并能将其与同插件中的check-compiler-errors、fix-ci、run-smoke-tests、verify-this等技能串联成一条冲突修复 → 本地验证 → CI 转绿的可靠链路。一、技能定位什么时候该触发 fix-merge-conflicts按照 Cursor 插件规范每个技能通过一个带 YAML frontmatter 的SKILL.md文件声明其中name是技能标识description说明其适用场景。fix-merge-conflicts的声明如下--- name: fix-merge-conflicts description: Resolve merge conflicts non-interactively, validate build and tests, and finalize conflict resolution ---description中两个关键词定义了该技能的适用范围non-interactively非交互式面向 Agent 自动执行不依赖人工反复在编辑器中点选接受当前/接受传入/双方合并validate build and tests验证构建与测试冲突解决不以没有冲突标记为终点而以项目能编译、测试能通过为完成标准。其显式触发条件Trigger为Branch has unresolved merge conflicts and needs a reliable path to a buildable state. 分支存在未解决的合并冲突且需要一条通往可构建状态的可靠路径。也就是说当git status中出现both modified等冲突状态、代码中出现//冲突标记而团队又希望快速、可靠地恢复到可编译状态时就该启用该技能而不是放任冲突堆积或靠赌一把式的手工拼接。二、核心工作流六步走完冲突修复技能定义的工作流共六步每一步都对应明确的落地动作。下面结合 Git 通用实践与 Cursor Team Kit 配套技能逐条展开。步骤 1从 git status 与冲突标记中检测所有冲突文件冲突解决的第一步不是猜而是穷举。需要同时使用两类信号git status/git diff --name-only --diff-filterU列出处于 unmerged 状态的文件清单在检出文件后通过正则搜索冲突标记例如grep -rn ^ --include*.ts --include*.tsx .确认哪些文件仍残留、、。之所以要双通道检测是因为存在两种典型漏网场景其一某些合并策略如git merge -X theirs会自动裁决但仍可能留下逻辑层面的不一致其二冲突标记可能残留在被 git 判定为已合并但实际上内容拼接错误的文件中。只有同时核对 status 与标记才能保证所有冲突文件都被纳入处理范围。步骤 2对每个冲突执行最小化、正确性优先的编辑技能对编辑动作给出两条硬性约束minimal最小化只改冲突区域本身不顺手重构、不格式化无关代码、不调整相邻函数correctness-first正确性优先裁决的标准是这段代码合起来是否语义正确而不是哪边改动多就保留哪边。这与 Cursor Team Kit 中 make-pr-easy-to-review/SKILL.md 的立场一脉相承——绝不把有意义的行为变更隐藏在清理之中。冲突解决阶段如果夹带无关改动评审者将无法判断哪些差异是合并裁决引入的哪些是顺手为之评审噪音与回归风险都会成倍放大。步骤 3默认保留双方否则选择能编译且公共行为稳定的一方这是整个技能中最核心的裁决原则原文为Prefer preserving both sides when safe. Otherwise, choose the variant that compiles and keeps public behavior stable.解读为三层决策树安全时保留双方当两个分支修改的是不同位置、不同职责的代码例如一个改了 A 函数的实现另一个新增了 B 函数并调用 A合并二者通常安全。典型做法是把两个 hunk 都保留并按语义拼接必要时补上调用衔接必须二选一时以能编译为底线选择当前分支与传入分支中语法完整、类型可推导、依赖引用成立的一方公共行为稳定是最终标尺对于导出函数、公开 API、配置结构、数据库迁移这类对外契约优先选择与既有调用方兼容的一方避免合并引入隐性破坏。这正是插件中 rules/typescript-exhaustive-switch.mdc 等团队规则在合并场景的自然延伸——公共类型处理不完整编译期就会暴露问题。步骤 4用包管理器工具重新生成 lockfile而非手工编辑当冲突发生在package-lock.json、pnpm-lock.yaml、yarn.lock、Cargo.lock、go.sum等依赖锁定文件时技能给出了一条不可妥协的铁律Regenerate lockfiles with package manager tools instead of hand-editing.原因在于 lockfile 的内部结构包含依赖树哈希、解析路径与版本指纹手工拼接冲突 hunk 极易产生文件格式合法但解析结果错误的伪成功状态后续任何一次npm ci都会失败。正确做法是在package.json或其等价清单完成裁决后直接调用对应工具重新生成锁定文件例如# npm 项目按 package.json 重新解析并更新锁定文件 npm install # pnpm / yarn pnpm install yarn install # Rust 项目Cargo.lock cargo update # Go 项目go.sum 通常随 go mod tidy 重新生成 go mod tidy这条原则与 run-smoke-tests/SKILL.md 中构建前置条件就绪后再运行测试的次序要求相互呼应lockfile 不干净后续所有编译与测试命令都会建立在不稳定的依赖图上。步骤 5运行编译、lint 与相关测试冲突裁决完成后必须进入验证环节技能明确要求同时覆盖三类检查compile编译、lint静态检查、relevant tests相关测试。编译/类型检查可复用同插件的 check-compiler-errors/SKILL.md 定义的工作流——运行仓库的编译与类型检查命令、按文件与错误类型归类、先修置信度最高的问题、反复运行直到干净或明确受阻lint保证合并后的代码风格与插件内 rules/no-inline-imports.mdc 这类团队约定保持一致相关测试优先运行与被冲突文件存在调用关系的测试集。若项目存在 Playwright 冒烟测试可参考 run-smoke-tests/SKILL.md 中的示例命令执行# 运行完整冒烟测试套件 npm run smoketest # 针对单个测试文件快速迭代 npm run smoketest -- path/to/test.spec.ts步骤 6暂存已解决文件并总结关键决策验证通过后用git add暂存所有已解决的冲突文件然后必须输出一份人类与评审系统都能读懂的决策摘要。这一步常被忽视但它决定了后续评审对应 review-and-ship/SKILL.md 的intent fit检查与问题回溯对应 verify-this/SKILL.md 的证据链要求能否高效进行。三、Guardrails冲突解决期间的四条红线技能定义了四条护栏违反任何一条都会让可靠路径重新变得不可靠改动保持最小且可读Keep changes minimal and readable与步骤 2 一致冲突期间任何重构都是噪音任何文件不得残留冲突标记Do not leave conflict markers in any file这是可构建状态的硬前提也是提交前必须用正则复查的兜底检查解决冲突期间避免大规模重构Avoid broad refactors while resolving conflicts重构应回到独立分支、独立 PR 中进行可参照 new-branch-and-pr/SKILL.md 的分支范围聚焦单一变更集原则冲突解决过程中不 push、不打 tagDo not push or tag during conflict resolution把推送到远端延后到本地验证完全通过之后避免把半成品状态广播给协作方。这四条护栏与同插件 fix-ci/SKILL.md 的护栏互为镜像fix-ci要求一次只修一个可操作的失败、优先最小低风险改动fix-merge-conflicts则把同样的纪律前置到合并裁决环节。四、输出规范一次冲突解决必须交付的三样东西技能规定的输出Output固定为三部分这也是任务完成的验收清单输出项内容要求Files resolved已解决的文件清单便于评审对照 diff 逐一核对Notable resolution choices关键裁决决策哪些冲突保留了双方、哪些选择了单侧、依据是什么Build/test outcome构建与测试的最终结果编译是否通过、lint 是否干净、相关测试是否全绿第三项Build/test outcome尤其重要——它把冲突解决的终点从没有冲突标记提升到可构建、可测试的事实层面为后续 review-and-ship/SKILL.md 中的行为是否按预期工作验证提供了可直接引用的证据也为 verify-this/SKILL.md 的VERIFIED / NOT VERIFIED式结论提供了 artifact 基础。五、在 Cursor Team Kit 中的闭环用法fix-merge-conflicts不是孤立技能它在插件生态中的典型协作链路如下git merge/pull 出现冲突 │ ▼ fix-merge-conflicts 检测 → 裁决 → 重生成 lockfile → 编译/lint/测试 → 暂存 摘要 │ ├──► check-compiler-errors 编译/类型错误逐文件归类与修复 ├──► run-smoke-tests 端到端冒烟验证 │ ▼ 本地验证通过 │ ▼ review-and-ship 评审、提交、打开/更新 PR │ ▼ fix-ci / loop-on-ci CI 失败时的快速迭代转绿路径安装该插件后即可直接使用这套流程Cursor Team Kit 的设计目标正是开箱即用、无需第三方服务集成安装命令参考 cursor-team-kit/README.md/add-plugin cursor-team-kit六、常见冲突类型与裁决速查结合步骤 2、3 的裁决原则可以沉淀出四类高频冲突的处理速查冲突类型典型表现推荐裁决同一行/同一函数的直接竞争两个分支都改了同一函数的同一行逐行比对语义优先编译通过 公共行为稳定的一方或手工合并两处意图新增文件与删除/重命名一方删除文件、另一方修改该文件确认删除是否是有意的破坏性变更通常保留删除并检查调用方依赖声明冲突package.json与 lockfile 同时冲突先裁决package.json再用包管理器重新生成 lockfile步骤 4 铁律配置/契约文件冲突环境变量、CI 配置、schema 同时被改优先合并双方新增项语义冲突时以不破坏既有契约为标尺无论哪种类型都必须牢记每一条裁决都要可回溯。这正是Notable resolution choices输出项存在的意义——它让冲突解决从一次性行为变成可审计记录。七、验证清单如何确认一次冲突解决真正完成在收尾前用以下清单做最终自检全部满足才视为完成git status中已无 unmerged 状态文件全仓库正则搜索无//冲突标记残留lockfile 由包管理器工具重新生成未手工拼接编译/类型检查通过或已明确记录受阻项lint 通过未引入与团队规则如 no-inline-imports.mdc、typescript-exhaustive-switch.mdc冲突的写法相关测试运行并通过结果已记录已暂存所有解决文件并输出 Files resolved / Notable resolution choices / Build/test outcome 三件套未 push、未打 tag等待本地验证结论稳定后再进入下一环节。这套清单把 cursor-team-kit/skills/fix-merge-conflicts/SKILL.md 中约三十行的精炼定义落成了一条任何人或任何 Agent都可以照章执行的工程化流程。冲突解决从此不再是碰运气的手工活而是有检测、有裁决、有验证、有记录的可重复过程——这正是 Cursor Team Kit 将日常工程纪律沉淀为插件技能的核心价值所在。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cursor Team Kit 合并冲突解决实战：从冲突检测到可构建状态的标准化非交互式流程
Cursor Team Kit 合并冲突解决实战从冲突检测到可构建状态的标准化非交互式流程【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins导读在多人协作的 Git 仓库中合并冲突merge conflict是无法回避的日常场景而冲突解决质量直接决定后续 CI、代码评审与发布流程能否顺利推进。Cursor Team Kit 插件的fix-merge-conflicts技能定义了一套非交互式、以最小改动 正确性优先 可构建状态为核心目标的标准化解冲突流程从冲突检测、逐文件裁决到 lockfile 重新生成、编译/测试验证再到暂存与决策总结全程不需要人工反复打开编辑器手工拉扯冲突标记。读完本文你将掌握该技能在 cursor-team-kit/skills/fix-merge-conflicts/SKILL.md 中定义的完整工作流并能将其与同插件中的check-compiler-errors、fix-ci、run-smoke-tests、verify-this等技能串联成一条冲突修复 → 本地验证 → CI 转绿的可靠链路。一、技能定位什么时候该触发 fix-merge-conflicts按照 Cursor 插件规范每个技能通过一个带 YAML frontmatter 的SKILL.md文件声明其中name是技能标识description说明其适用场景。fix-merge-conflicts的声明如下--- name: fix-merge-conflicts description: Resolve merge conflicts non-interactively, validate build and tests, and finalize conflict resolution ---description中两个关键词定义了该技能的适用范围non-interactively非交互式面向 Agent 自动执行不依赖人工反复在编辑器中点选接受当前/接受传入/双方合并validate build and tests验证构建与测试冲突解决不以没有冲突标记为终点而以项目能编译、测试能通过为完成标准。其显式触发条件Trigger为Branch has unresolved merge conflicts and needs a reliable path to a buildable state. 分支存在未解决的合并冲突且需要一条通往可构建状态的可靠路径。也就是说当git status中出现both modified等冲突状态、代码中出现//冲突标记而团队又希望快速、可靠地恢复到可编译状态时就该启用该技能而不是放任冲突堆积或靠赌一把式的手工拼接。二、核心工作流六步走完冲突修复技能定义的工作流共六步每一步都对应明确的落地动作。下面结合 Git 通用实践与 Cursor Team Kit 配套技能逐条展开。步骤 1从 git status 与冲突标记中检测所有冲突文件冲突解决的第一步不是猜而是穷举。需要同时使用两类信号git status/git diff --name-only --diff-filterU列出处于 unmerged 状态的文件清单在检出文件后通过正则搜索冲突标记例如grep -rn ^ --include*.ts --include*.tsx .确认哪些文件仍残留、、。之所以要双通道检测是因为存在两种典型漏网场景其一某些合并策略如git merge -X theirs会自动裁决但仍可能留下逻辑层面的不一致其二冲突标记可能残留在被 git 判定为已合并但实际上内容拼接错误的文件中。只有同时核对 status 与标记才能保证所有冲突文件都被纳入处理范围。步骤 2对每个冲突执行最小化、正确性优先的编辑技能对编辑动作给出两条硬性约束minimal最小化只改冲突区域本身不顺手重构、不格式化无关代码、不调整相邻函数correctness-first正确性优先裁决的标准是这段代码合起来是否语义正确而不是哪边改动多就保留哪边。这与 Cursor Team Kit 中 make-pr-easy-to-review/SKILL.md 的立场一脉相承——绝不把有意义的行为变更隐藏在清理之中。冲突解决阶段如果夹带无关改动评审者将无法判断哪些差异是合并裁决引入的哪些是顺手为之评审噪音与回归风险都会成倍放大。步骤 3默认保留双方否则选择能编译且公共行为稳定的一方这是整个技能中最核心的裁决原则原文为Prefer preserving both sides when safe. Otherwise, choose the variant that compiles and keeps public behavior stable.解读为三层决策树安全时保留双方当两个分支修改的是不同位置、不同职责的代码例如一个改了 A 函数的实现另一个新增了 B 函数并调用 A合并二者通常安全。典型做法是把两个 hunk 都保留并按语义拼接必要时补上调用衔接必须二选一时以能编译为底线选择当前分支与传入分支中语法完整、类型可推导、依赖引用成立的一方公共行为稳定是最终标尺对于导出函数、公开 API、配置结构、数据库迁移这类对外契约优先选择与既有调用方兼容的一方避免合并引入隐性破坏。这正是插件中 rules/typescript-exhaustive-switch.mdc 等团队规则在合并场景的自然延伸——公共类型处理不完整编译期就会暴露问题。步骤 4用包管理器工具重新生成 lockfile而非手工编辑当冲突发生在package-lock.json、pnpm-lock.yaml、yarn.lock、Cargo.lock、go.sum等依赖锁定文件时技能给出了一条不可妥协的铁律Regenerate lockfiles with package manager tools instead of hand-editing.原因在于 lockfile 的内部结构包含依赖树哈希、解析路径与版本指纹手工拼接冲突 hunk 极易产生文件格式合法但解析结果错误的伪成功状态后续任何一次npm ci都会失败。正确做法是在package.json或其等价清单完成裁决后直接调用对应工具重新生成锁定文件例如# npm 项目按 package.json 重新解析并更新锁定文件 npm install # pnpm / yarn pnpm install yarn install # Rust 项目Cargo.lock cargo update # Go 项目go.sum 通常随 go mod tidy 重新生成 go mod tidy这条原则与 run-smoke-tests/SKILL.md 中构建前置条件就绪后再运行测试的次序要求相互呼应lockfile 不干净后续所有编译与测试命令都会建立在不稳定的依赖图上。步骤 5运行编译、lint 与相关测试冲突裁决完成后必须进入验证环节技能明确要求同时覆盖三类检查compile编译、lint静态检查、relevant tests相关测试。编译/类型检查可复用同插件的 check-compiler-errors/SKILL.md 定义的工作流——运行仓库的编译与类型检查命令、按文件与错误类型归类、先修置信度最高的问题、反复运行直到干净或明确受阻lint保证合并后的代码风格与插件内 rules/no-inline-imports.mdc 这类团队约定保持一致相关测试优先运行与被冲突文件存在调用关系的测试集。若项目存在 Playwright 冒烟测试可参考 run-smoke-tests/SKILL.md 中的示例命令执行# 运行完整冒烟测试套件 npm run smoketest # 针对单个测试文件快速迭代 npm run smoketest -- path/to/test.spec.ts步骤 6暂存已解决文件并总结关键决策验证通过后用git add暂存所有已解决的冲突文件然后必须输出一份人类与评审系统都能读懂的决策摘要。这一步常被忽视但它决定了后续评审对应 review-and-ship/SKILL.md 的intent fit检查与问题回溯对应 verify-this/SKILL.md 的证据链要求能否高效进行。三、Guardrails冲突解决期间的四条红线技能定义了四条护栏违反任何一条都会让可靠路径重新变得不可靠改动保持最小且可读Keep changes minimal and readable与步骤 2 一致冲突期间任何重构都是噪音任何文件不得残留冲突标记Do not leave conflict markers in any file这是可构建状态的硬前提也是提交前必须用正则复查的兜底检查解决冲突期间避免大规模重构Avoid broad refactors while resolving conflicts重构应回到独立分支、独立 PR 中进行可参照 new-branch-and-pr/SKILL.md 的分支范围聚焦单一变更集原则冲突解决过程中不 push、不打 tagDo not push or tag during conflict resolution把推送到远端延后到本地验证完全通过之后避免把半成品状态广播给协作方。这四条护栏与同插件 fix-ci/SKILL.md 的护栏互为镜像fix-ci要求一次只修一个可操作的失败、优先最小低风险改动fix-merge-conflicts则把同样的纪律前置到合并裁决环节。四、输出规范一次冲突解决必须交付的三样东西技能规定的输出Output固定为三部分这也是任务完成的验收清单输出项内容要求Files resolved已解决的文件清单便于评审对照 diff 逐一核对Notable resolution choices关键裁决决策哪些冲突保留了双方、哪些选择了单侧、依据是什么Build/test outcome构建与测试的最终结果编译是否通过、lint 是否干净、相关测试是否全绿第三项Build/test outcome尤其重要——它把冲突解决的终点从没有冲突标记提升到可构建、可测试的事实层面为后续 review-and-ship/SKILL.md 中的行为是否按预期工作验证提供了可直接引用的证据也为 verify-this/SKILL.md 的VERIFIED / NOT VERIFIED式结论提供了 artifact 基础。五、在 Cursor Team Kit 中的闭环用法fix-merge-conflicts不是孤立技能它在插件生态中的典型协作链路如下git merge/pull 出现冲突 │ ▼ fix-merge-conflicts 检测 → 裁决 → 重生成 lockfile → 编译/lint/测试 → 暂存 摘要 │ ├──► check-compiler-errors 编译/类型错误逐文件归类与修复 ├──► run-smoke-tests 端到端冒烟验证 │ ▼ 本地验证通过 │ ▼ review-and-ship 评审、提交、打开/更新 PR │ ▼ fix-ci / loop-on-ci CI 失败时的快速迭代转绿路径安装该插件后即可直接使用这套流程Cursor Team Kit 的设计目标正是开箱即用、无需第三方服务集成安装命令参考 cursor-team-kit/README.md/add-plugin cursor-team-kit六、常见冲突类型与裁决速查结合步骤 2、3 的裁决原则可以沉淀出四类高频冲突的处理速查冲突类型典型表现推荐裁决同一行/同一函数的直接竞争两个分支都改了同一函数的同一行逐行比对语义优先编译通过 公共行为稳定的一方或手工合并两处意图新增文件与删除/重命名一方删除文件、另一方修改该文件确认删除是否是有意的破坏性变更通常保留删除并检查调用方依赖声明冲突package.json与 lockfile 同时冲突先裁决package.json再用包管理器重新生成 lockfile步骤 4 铁律配置/契约文件冲突环境变量、CI 配置、schema 同时被改优先合并双方新增项语义冲突时以不破坏既有契约为标尺无论哪种类型都必须牢记每一条裁决都要可回溯。这正是Notable resolution choices输出项存在的意义——它让冲突解决从一次性行为变成可审计记录。七、验证清单如何确认一次冲突解决真正完成在收尾前用以下清单做最终自检全部满足才视为完成git status中已无 unmerged 状态文件全仓库正则搜索无//冲突标记残留lockfile 由包管理器工具重新生成未手工拼接编译/类型检查通过或已明确记录受阻项lint 通过未引入与团队规则如 no-inline-imports.mdc、typescript-exhaustive-switch.mdc冲突的写法相关测试运行并通过结果已记录已暂存所有解决文件并输出 Files resolved / Notable resolution choices / Build/test outcome 三件套未 push、未打 tag等待本地验证结论稳定后再进入下一环节。这套清单把 cursor-team-kit/skills/fix-merge-conflicts/SKILL.md 中约三十行的精炼定义落成了一条任何人或任何 Agent都可以照章执行的工程化流程。冲突解决从此不再是碰运气的手工活而是有检测、有裁决、有验证、有记录的可重复过程——这正是 Cursor Team Kit 将日常工程纪律沉淀为插件技能的核心价值所在。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考