How do I install the Resolving Conflicts skill?

Run npx skillmds@latest add dotnet/resolving-conflicts in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Resolving Conflicts skill do?

Use when merging or cherry-picking changes cause git conflicts. It is listed under Coding & Dev Tools on SkillMD.

Is Resolving Conflicts safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Resolving Conflicts?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Resolving Conflicts free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Resolving Conflicts?

.NET (Microsoft) (@dotnet) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Resolving Conflicts by dotnet — Agent Skill

Name: Resolving Conflicts
Rating: 4.666666666666667 (3 reviews)
Author: .NET (Microsoft)

File contents

Resolving branch conflicts

Name the source and target branches. Read the branch guide before choosing either side.
Remember that ours and theirs depend on the Git operation. Inspect the stages with git ls-files -u; never resolve a file based only on those labels.
Resolve authored inputs first, then regenerate derived files.

Conflict	Resolution
`manifest.versions.json`	Start with the target's branch and product versions. Apply only the source component/version keys required by the port. "Newest" is not a rule: nightly daily builds and release servicing builds have different intent.
`manifest.json`	Combine structural image changes, but preserve the target's image set, repositories, `latest` ownership, floating tags, and preview suffixes.
`eng/dockerfile-templates/**`	Keep shared build logic from both changes. Retain a difference only when the target builds a different product or OS matrix.
`src/**/Dockerfile`	Do not hand-merge generated Dockerfiles. Resolve manifests and templates, then regenerate them.
README and portal docs	Resolve README templates and manifests, then regenerate. Preserve target-specific official or nightly links and tag listings.
Tests and baselines	Port shared behavior tests. Preserve the target product matrix and regenerate baselines after resolving source.
Pipelines and workflows	Combine shared logic; preserve target-specific triggers, branch names, feeds, service connections, staging, and publishing behavior.
Modify/delete conflicts	Decide whether the image or feature belongs on the target branch. Do not restore or delete it merely to clear the conflict.
Other authored files	Merge the behavior semantically. A clean conflict marker resolution is not proof that the result is correct.

Always regenerate Dockerfiles and READMEs when templates change.

Review git diff --check, generated-file consistency, tags, versions, image sets, and branch references. Run targeted pre-build tests. If the intended target behavior is unclear, stop and record the unresolved decision instead of guessing.

---name: resolving-conflictsdescription: Use when merging or cherry-picking changes cause git conflicts.---# Resolving branch conflicts1. Name the source and target branches. Read the [branch guide](../../../eng/developer-docs/branches.md) before choosing either side.2. Remember that `ours` and `theirs` depend on the Git operation. Inspect the stages with `git ls-files -u`; never resolve a file based only on those labels.3. Resolve authored inputs first, then regenerate derived files.| Conflict | Resolution || --- | --- || `manifest.versions.json` | Start with the target's branch and product versions. Apply only the source component/version keys required by the port. "Newest" is not a rule: nightly daily builds and release servicing builds have different intent. || `manifest.json` | Combine structural image changes, but preserve the target's image set, repositories, `latest` ownership, floating tags, and preview suffixes. || `eng/dockerfile-templates/**` | Keep shared build logic from both changes. Retain a difference only when the target builds a different product or OS matrix. || `src/**/Dockerfile` | Do not hand-merge generated Dockerfiles. Resolve manifests and templates, then regenerate them. || README and portal docs | Resolve README templates and manifests, then regenerate. Preserve target-specific official or nightly links and tag listings. || Tests and baselines | Port shared behavior tests. Preserve the target product matrix and regenerate baselines after resolving source. || Pipelines and workflows | Combine shared logic; preserve target-specific triggers, branch names, feeds, service connections, staging, and publishing behavior. || Modify/delete conflicts | Decide whether the image or feature belongs on the target branch. Do not restore or delete it merely to clear the conflict. || Other authored files | Merge the behavior semantically. A clean conflict marker resolution is not proof that the result is correct. |Always regenerate Dockerfiles and READMEs when templates change.Review `git diff --check`, generated-file consistency, tags, versions, image sets, and branch references. Run targeted pre-build tests. If the intended target behavior is unclear, stop and record the unresolved decision instead of guessing.

Frequently asked questions

Resolving Conflicts