/resolving-merge-conflicts
Use when a git merge or rebase reports conflicts and the operation is in progress.
$ npx -y skills add romiluz13/cc10x --skill resolving-merge-conflicts --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/resolving-merge-conflicts
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when a git merge or rebase reports conflicts and the operation is in progress.
SKILL.md
resolving-merge-conflicts.SKILL.mdname: resolving-merge-conflicts
description: |
Use when a git merge or rebase reports conflicts and the operation is in progress.
allowed-tools: Read Bash Grep Glob
user-invocable: false
<!-- Upstream: github.com/mattpocock/skills @ e9fcdf95 (skills/engineering/resolving-merge-conflicts) Classification: ADAPTED (cc10x frontmatter + output conventions; 5-step body is Matt's). -->
Resolving Merge Conflicts
Work through an in-progress git merge or rebase conflict **hunk by hunk**, resolving each by intent traced to each side's primary source. **Never `--abort`.** Always resolve; `--abort` throws away work and hides the real incompatibility.
The 5 steps
1. See the current state
Check git status, the conflicting files, and the conflict markers:
git status
git diff --name-only --diff-filter=U # the unmerged paths
Read each conflicting file's conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) to see exactly what's contested. Know whether you're in a merge (`MERGE_HEAD` set) or a rebase (`rebase-merge/` or `rebase-apply/` present in `.git/`).
2. Find the primary sources for each side
For each conflict hunk, understand **why** each change was made and what its original intent was — don't just pick the bigger diff. Read:
- The commit messages on both sides (`git log --oneline -5 -- <file>` for each side)
- The PRs or issues/tickets the commits reference
- The surrounding code to confirm what each side was trying to achieve
3. Resolve each hunk by intent
For each hunk:
- **Preserve both intents where possible** — the two sides usually want different things; merge both.
- **Where incompatible**, pick the one matching the merge's stated goal (the feature, the fix, the branch's purpose) — never pick one side blind — and **note the trade-off** in the commit message: what was given up and why.
- **Never invent new behavior.** A conflict resolution is not a place to add new code neither side wrote.
4. Run the project's automated checks
Discover the project's checks and run them in order — typically typecheck, then tests, then format:
# node: npx tsc --noEmit (or per package.json scripts)
# python: ruff check . && python -m pytest -q
# go: go build ./... && go test ./...
Fix anything the merge broke. A conflict resolution that breaks the build is not a resolution.
5. Finish the merge/rebase
Stage everything and commit:
git add <resolved-files>
git commit # merge: completes the merge commit
# rebase: git rebase --continue (repeat for each conflicted commit until done)
If rebasing, continue the rebase process until ALL commits are rebased.
Before you commit
- **Never leave conflict markers in a committed file.** `grep -rn '^<<<<<<< \|^=======$\|^>>>>>>> ' .` must return nothing before you commit.
Read more
name: resolving-merge-conflicts description: | Use when a git merge or rebase reports conflicts and the operation is in progress. allowed-tools: Read Bash Grep Glob user-invocable: false
<!-- Upstream: github.com/mattpocock/skills @ e9fcdf95 (skills/engineering/resolving-merge-conflicts) Classification: ADAPTED (cc10x frontmatter + output conventions; 5-step body is Matt's). -->
Resolving Merge Conflicts
Work through an in-progress git merge or rebase conflict **hunk by hunk**, resolving each by intent traced to each side's primary source. **Never `--abort`.** Always resolve; `--abort` throws away work and hides the real incompatibility.
The 5 steps
1. See the current state
Check git status, the conflicting files, and the conflict markers:
git status git diff --name-only --diff-filter=U # the unmerged paths
Read each conflicting file's conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) to see exactly what's contested. Know whether you're in a merge (`MERGE_HEAD` set) or a rebase (`rebase-merge/` or `rebase-apply/` present in `.git/`).
2. Find the primary sources for each side
For each conflict hunk, understand **why** each change was made and what its original intent was — don't just pick the bigger diff. Read:
- The commit messages on both sides (`git log --oneline -5 -- <file>` for each side)
- The PRs or issues/tickets the commits reference
- The surrounding code to confirm what each side was trying to achieve
3. Resolve each hunk by intent
For each hunk:
- **Preserve both intents where possible** — the two sides usually want different things; merge both.
- **Where incompatible**, pick the one matching the merge's stated goal (the feature, the fix, the branch's purpose) — never pick one side blind — and **note the trade-off** in the commit message: what was given up and why.
- **Never invent new behavior.** A conflict resolution is not a place to add new code neither side wrote.
4. Run the project's automated checks
Discover the project's checks and run them in order — typically typecheck, then tests, then format:
# node: npx tsc --noEmit (or per package.json scripts) # python: ruff check . && python -m pytest -q # go: go build ./... && go test ./...
Fix anything the merge broke. A conflict resolution that breaks the build is not a resolution.
5. Finish the merge/rebase
Stage everything and commit:
git add <resolved-files> git commit # merge: completes the merge commit # rebase: git rebase --continue (repeat for each conflicted commit until done)
If rebasing, continue the rebase process until ALL commits are rebased.
Before you commit
- **Never leave conflict markers in a committed file.** `grep -rn '^<<<<<<< \|^=======$\|^>>>>>>> ' .` must return nothing before you commit.
The Loop Engine for Claude Code — engineer the loop, not the prompt. 1 router · 9 agents · 16 skills · 4 workflows. Fail-closed gates, test honesty, anti-anchored review.
Repo: romiluz13/cc10x
Other skills on cc10x.
- /agent-common
Shared preamble loaded by all cc10x agents — memory protocol, contract format, output rules.
Open skill - /architecture
Greenfield architecture design: map functionality flows, draw components, design APIs, classify dependencies, plan observability. For multi-component, API, schema, auth, or integration-heavy work. For retrofitting existing code, use codebase-hygiene instead.
Open skill - /building
Implementation skill for writing production code with TDD. Covers the RED-GREEN-REFACTOR cycle, false-RED detection, vertical slicing, scope escalation, test process discipline, and code generation patterns. Loaded by component-builder and bug-investigator.
Open skill - /cc10x-router
THE ONLY ENTRY POINT FOR CC10X. Activate this skill for build, debug, review, and plan requests. Use when the user asks to implement, fix, review, plan, test, refactor, or continue code work. Trigger keywords: build, implement, create, write, add, review, audit, debug, fix,
Open skill - /code-review
Two-mode skill: (1) adversarial review — spec compliance + code quality + security, confidence-scored findings with file:line evidence; (2) receiving review — verify-before- agreeing discipline for acting on external/human review feedback.
Open skill - /codebase-design
Canonical deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's shape — a lot of behaviour behind a small interface at a clean seam, testable through that interface. The single source of truth for these terms; other skills
Open skill

