git-conflict-resolver

Name: git-conflict-resolver
Author: girijashankarj

27stars3forks

How to install git-conflict-resolver?

girijashankarj/cursor-handbook/git-conflict-resolver

$npx -y skills add girijashankarj/cursor-handbook --skill git-conflict-resolver

Installs into the current project.

Summary

Systematic workflow for understanding and resolving git merge conflicts safely. Use when the user has merge conflicts or asks for help resolving conflicts.

Files · 1

View on GitHub

SKILL.md

1	# Skill: Git Conflict Resolver
2
3	Safely resolve git merge conflicts by understanding both sides, choosing the correct resolution, and validating the result.
4
5	## Trigger
6	When the user reports merge conflicts, rebase conflicts, or asks for help resolving git conflicts.
7
8	## Prerequisites
9	- [ ] Active merge or rebase in progress (`git status` shows "Unmerged paths")
10	- [ ] Understanding of the intended behavior of both branches
11
12	## Steps
13
14	### Step 1: Assess the Situation
15	- [ ] Run `git status` to list all conflicted files
16	- [ ] Determine the operation: merge, rebase, or cherry-pick
17	- [ ] Identify source and target branches
18	- [ ] Count total conflicts: `git diff --name-only --diff-filter=U`
19
20	### Step 2: Understand Each Conflict
21	For each conflicted file:
22	- [ ] Read the conflict markers:
23	```
24	<<<<<<< HEAD (current branch — "ours")
25	current branch code
26	=======
27	incoming branch code ("theirs")
28	>>>>>>> branch-name
29	```
30	- [ ] Understand what ours changed and why
31	- [ ] Understand what theirs changed and why
32	- [ ] Check commit messages for context: `git log --oneline -5 -- <file>`
33
34	### Step 3: Classify Conflict Type
35
36	\| Type \| Description \| Resolution Strategy \|
37	\|------\|-------------\|-------------------\|
38	\| Trivial \| Same file, different sections \| Accept both (auto-merge missed it) \|
39	\| Additive \| Both sides added code \| Keep both additions, order logically \|
40	\| Competing \| Both sides changed same line \| Understand intent, pick correct version \|
41	\| Structural \| File renamed/moved vs edited \| Keep the rename, apply edits to new path \|
42	\| Delete vs Edit \| One side deleted, other edited \| Decide if deletion or edit is correct \|
43	\| Semantic \| No textual conflict but logic conflict \| Requires understanding business logic \|
44
45	### Step 4: Resolve Each File
46	- [ ] For trivial/additive: combine both changes
47	- [ ] For competing: choose the version that matches intended behavior, or merge logic from both
48	- [ ] Remove ALL conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
49	- [ ] Verify the file is syntactically valid
50	- [ ] Verify imports are correct (no duplicates, no missing)
51
52	### Step 5: Validate Resolution
53	- [ ] Run type-check: `{{CONFIG.testing.typeCheckCommand}}`
54	- [ ] Run lint on resolved files (use `read_lints` tool)
55	- [ ] Run tests for affected files only (not full suite)
56	- [ ] Verify no conflict markers remain: search for `<<<<<<<` in resolved files
57
58	### Step 6: Complete the Operation
59	For merge:
60	```bash
61	git add <resolved-files>
62	git commit # Uses the pre-populated merge commit message
63	```
64
65	For rebase:
66	```bash
67	git add <resolved-files>
68	git rebase --continue
69	```
70
71	For cherry-pick:
72	```bash
73	git add <resolved-files>
74	git cherry-pick --continue
75	```
76
77	### Step 7: Post-Resolution
78	- [ ] Verify the merge/rebase completed: `git status` shows clean state
79	- [ ] Run a broader validation if many files changed
80	- [ ] Check `git log --graph --oneline -10` to verify history looks correct
81
82	## Abort Strategies
83	If resolution becomes too complex:
84	```bash
85	git merge --abort # Undo a merge
86	git rebase --abort # Undo a rebase
87	git cherry-pick --abort # Undo a cherry-pick
88	```
89
90	## Rules
91	- ALWAYS understand both sides before resolving
92	- ALWAYS validate after resolving (type-check, lint, tests)
93	- NEVER blindly accept "ours" or "theirs" for all files
94	- NEVER leave conflict markers in resolved files
95	- NEVER resolve semantic conflicts without understanding the business logic
96	- When in doubt, ask the user which behavior is correct
97	- Prefer small, file-by-file resolution over bulk operations
98
99	## Completion
100	All conflicts resolved, validated, and merge/rebase completed. Working tree is clean.
101
102	## If a Step Fails
103	- Can't understand intent: Check PR descriptions, commit messages, or ask the user
104	- Type-check fails after resolve: Likely a missed import or incompatible types — fix before continuing
105	- Tests fail after resolve: Logic conflict exists — review both changes more carefully
106	- Too many conflicts (>20 files): Consider aborting and rebasing incrementally, or merging main into the feature branch first

People who liked this also viewed

6 picks

Type

git-conflict-resolver

27stars3forks

View on GitHub

How to install git-conflict-resolver?

girijashankarj/cursor-handbook/git-conflict-resolver

$npx -y skills add girijashankarj/cursor-handbook --skill git-conflict-resolver

Installs into the current project.

Summary

Systematic workflow for understanding and resolving git merge conflicts safely. Use when the user has merge conflicts or asks for help resolving conflicts.

Files · 1

View on GitHub

SKILL.md

1	# Skill: Git Conflict Resolver
2
3	Safely resolve git merge conflicts by understanding both sides, choosing the correct resolution, and validating the result.
4
5	## Trigger
6	When the user reports merge conflicts, rebase conflicts, or asks for help resolving git conflicts.
7
8	## Prerequisites
9	- [ ] Active merge or rebase in progress (`git status` shows "Unmerged paths")
10	- [ ] Understanding of the intended behavior of both branches
11
12	## Steps
13
14	### Step 1: Assess the Situation
15	- [ ] Run `git status` to list all conflicted files
16	- [ ] Determine the operation: merge, rebase, or cherry-pick
17	- [ ] Identify source and target branches
18	- [ ] Count total conflicts: `git diff --name-only --diff-filter=U`
19
20	### Step 2: Understand Each Conflict
21	For each conflicted file:
22	- [ ] Read the conflict markers:
23	```
24	<<<<<<< HEAD (current branch — "ours")
25	current branch code
26	=======
27	incoming branch code ("theirs")
28	>>>>>>> branch-name
29	```
30	- [ ] Understand what ours changed and why
31	- [ ] Understand what theirs changed and why
32	- [ ] Check commit messages for context: `git log --oneline -5 -- <file>`
33
34	### Step 3: Classify Conflict Type
35
36	\| Type \| Description \| Resolution Strategy \|
37	\|------\|-------------\|-------------------\|
38	\| Trivial \| Same file, different sections \| Accept both (auto-merge missed it) \|
39	\| Additive \| Both sides added code \| Keep both additions, order logically \|
40	\| Competing \| Both sides changed same line \| Understand intent, pick correct version \|
41	\| Structural \| File renamed/moved vs edited \| Keep the rename, apply edits to new path \|
42	\| Delete vs Edit \| One side deleted, other edited \| Decide if deletion or edit is correct \|
43	\| Semantic \| No textual conflict but logic conflict \| Requires understanding business logic \|
44
45	### Step 4: Resolve Each File
46	- [ ] For trivial/additive: combine both changes
47	- [ ] For competing: choose the version that matches intended behavior, or merge logic from both
48	- [ ] Remove ALL conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
49	- [ ] Verify the file is syntactically valid
50	- [ ] Verify imports are correct (no duplicates, no missing)
51
52	### Step 5: Validate Resolution
53	- [ ] Run type-check: `{{CONFIG.testing.typeCheckCommand}}`
54	- [ ] Run lint on resolved files (use `read_lints` tool)
55	- [ ] Run tests for affected files only (not full suite)
56	- [ ] Verify no conflict markers remain: search for `<<<<<<<` in resolved files
57
58	### Step 6: Complete the Operation
59	For merge:
60	```bash
61	git add <resolved-files>
62	git commit # Uses the pre-populated merge commit message
63	```
64
65	For rebase:
66	```bash
67	git add <resolved-files>
68	git rebase --continue
69	```
70
71	For cherry-pick:
72	```bash
73	git add <resolved-files>
74	git cherry-pick --continue
75	```
76
77	### Step 7: Post-Resolution
78	- [ ] Verify the merge/rebase completed: `git status` shows clean state
79	- [ ] Run a broader validation if many files changed
80	- [ ] Check `git log --graph --oneline -10` to verify history looks correct
81
82	## Abort Strategies
83	If resolution becomes too complex:
84	```bash
85	git merge --abort # Undo a merge
86	git rebase --abort # Undo a rebase
87	git cherry-pick --abort # Undo a cherry-pick
88	```
89
90	## Rules
91	- ALWAYS understand both sides before resolving
92	- ALWAYS validate after resolving (type-check, lint, tests)
93	- NEVER blindly accept "ours" or "theirs" for all files
94	- NEVER leave conflict markers in resolved files
95	- NEVER resolve semantic conflicts without understanding the business logic
96	- When in doubt, ask the user which behavior is correct
97	- Prefer small, file-by-file resolution over bulk operations
98
99	## Completion
100	All conflicts resolved, validated, and merge/rebase completed. Working tree is clean.
101
102	## If a Step Fails
103	- Can't understand intent: Check PR descriptions, commit messages, or ask the user
104	- Type-check fails after resolve: Likely a missed import or incompatible types — fix before continuing
105	- Tests fail after resolve: Logic conflict exists — review both changes more carefully
106	- Too many conflicts (>20 files): Consider aborting and rebasing incrementally, or merging main into the feature branch first

People who liked this also viewed

6 picks

Type