hk-merge-resolve

Name: hk-merge-resolve
Author: deepklarity

84stars12forks

How to install hk-merge-resolve?

deepklarity/harness-kit/hk-merge-resolve

$npx -y skills add deepklarity/harness-kit --skill hk-merge-resolve

Installs into the current project.

Summary

Resolve merge conflicts in the current branch. Only invoke when the user explicitly runs /hk-merge-resolve. Do NOT auto-trigger on mentions of merge conflicts, conflict markers, or similar keywords.

Files · 1

View on GitHub

SKILL.md

1	# Resolve Merge Conflicts
2
3	Your job is to resolve all merge conflicts in the current branch of the current repo.
4
5	Conflicts can come from many sources — `git merge`, `git rebase`, `git stash pop`, `git cherry-pick`, or any operation that combines divergent changes. This skill handles all of them.
6
7	## Step 0: Diagnose the Situation
8
9	Before changing anything, understand what state git is in and what caused the conflicts.
10
11	1. Snapshot the state — Run these to understand what's happening:
12	```bash
13	git status
14	git rev-parse HEAD
15	```
16	Print the HEAD sha to the user: "Safety checkpoint: HEAD is at `<sha>`."
17
18	2. Identify the conflict source — Check which operation is in progress:
19	- `git rev-parse MERGE_HEAD 2>/dev/null` → merge in progress
20	- `test -d .git/rebase-merge \|\| test -d .git/rebase-apply` → rebase in progress
21	- `git stash list` + check `git status` for "Unmerged paths" without MERGE_HEAD → stash pop conflict
22
23	This matters because the abort/recovery command differs:
24	\| Source \| Abort command \|
25	\|--------\|--------------\|
26	\| merge \| `git merge --abort` \|
27	\| rebase \| `git rebase --abort` \|
28	\| cherry-pick \| `git cherry-pick --abort` \|
29	\| stash pop \| `git checkout -- .` (stash stays in list, nothing lost) \|
30
31	Print the appropriate abort command to the user so they have an escape hatch.
32
33	3. Protect unstashed work — If there are uncommitted changes beyond the conflicted files (tracked modified files that aren't part of the conflict), warn the user. These are at risk during resolution. Suggest committing or stashing them separately before proceeding, and wait for confirmation.
34
35	Do NOT blindly `git stash` when conflicts are already present — git won't allow it, and if the conflicts came from a `stash pop`, the user's changes are already in the working tree as the conflicted content. Stashing again would lose them.
36
37	## Step 1: Build Context
38
39	Understand what both sides of the conflict were trying to do:
40
41	1. Identify the two sides — Based on the conflict source:
42	- Merge: "ours" = current branch, "theirs" = the branch being merged in
43	- Stash pop: "ours" = current working tree (post-pull), "theirs" = the stashed changes (the user's local work)
44	- Rebase: "ours" = the branch being rebased onto, "theirs" = the commits being replayed
45
46	Understanding which side is which is critical — especially for stash pop conflicts where "theirs" is the user's own work and should generally be preserved.
47
48	2. Find all conflicts — Use Grep to search for `<<<<<<<` across the repo. This gives you the full list of files and locations.
49
50	3. Triage — Group conflicts before diving in:
51	- Trivial: Lock files, auto-generated files, whitespace-only — resolve mechanically.
52	- Straightforward: Both sides changed different things in the same region — combine them.
53	- Requires judgment: Both sides changed the same logic — need to understand intent.
54
55	## Step 2: Resolve Each Conflict
56
57	For each conflicted file, read the file (or at minimum the conflicted region with surrounding context), then decide:
58
59	1. Keep ours — when the incoming changes are superseded
60	2. Keep theirs — when the incoming side has the better version
61	3. Combine both — the most common case; merge both sides' intent into correct code
62
63	For stash pop conflicts: The user's stashed changes are their in-progress work. Default to preserving the user's intent — their local changes are the "important" side. The pulled/merged content is the "environment" that the user's work needs to be adapted to.
64
65	Correctness matters more than cleverness. When combining:
66	- Understand what each side was trying to do
67	- Write the result that achieves both goals
68	- Make sure imports, variable names, and types are consistent across the merged result
69
70	For each conflict:
71	1. Read the file to see the full conflict region with context
72	2. Edit the file to the desired final state — remove ALL conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
73	3. Stage the resolved file with `git add <file>`
74
75	After resolving all conflicts in a file, do a quick sanity check: does the file still make sense? Are imports consistent? Are there dangling references?
76
77	## Step 3: Verify — Close the Loop
78
79	After all conflicts are resolved, verification is mandatory, not optional. A merge that compiles is not a merge that works.
80
81	### 3a. Confirm clean state
82
83	```bash
84	git diff --check # No conflict markers remain
85	grep -rn '<<<<<<<' . # Belt-and-suspenders: grep for stray markers
86	```
87
88	If either finds markers, go back and fix them before proceeding.
89
90	### 3b. Determine affected projects
91
92	Check which parts of the

People who liked this also viewed

6 picks

Type

hk-merge-resolve

84stars12forks

View on GitHub

How to install hk-merge-resolve?

deepklarity/harness-kit/hk-merge-resolve

$npx -y skills add deepklarity/harness-kit --skill hk-merge-resolve

Installs into the current project.

Summary

Resolve merge conflicts in the current branch. Only invoke when the user explicitly runs /hk-merge-resolve. Do NOT auto-trigger on mentions of merge conflicts, conflict markers, or similar keywords.

Files · 1

View on GitHub

SKILL.md

1	# Resolve Merge Conflicts
2
3	Your job is to resolve all merge conflicts in the current branch of the current repo.
4
5	Conflicts can come from many sources — `git merge`, `git rebase`, `git stash pop`, `git cherry-pick`, or any operation that combines divergent changes. This skill handles all of them.
6
7	## Step 0: Diagnose the Situation
8
9	Before changing anything, understand what state git is in and what caused the conflicts.
10
11	1. Snapshot the state — Run these to understand what's happening:
12	```bash
13	git status
14	git rev-parse HEAD
15	```
16	Print the HEAD sha to the user: "Safety checkpoint: HEAD is at `<sha>`."
17
18	2. Identify the conflict source — Check which operation is in progress:
19	- `git rev-parse MERGE_HEAD 2>/dev/null` → merge in progress
20	- `test -d .git/rebase-merge \|\| test -d .git/rebase-apply` → rebase in progress
21	- `git stash list` + check `git status` for "Unmerged paths" without MERGE_HEAD → stash pop conflict
22
23	This matters because the abort/recovery command differs:
24	\| Source \| Abort command \|
25	\|--------\|--------------\|
26	\| merge \| `git merge --abort` \|
27	\| rebase \| `git rebase --abort` \|
28	\| cherry-pick \| `git cherry-pick --abort` \|
29	\| stash pop \| `git checkout -- .` (stash stays in list, nothing lost) \|
30
31	Print the appropriate abort command to the user so they have an escape hatch.
32
33	3. Protect unstashed work — If there are uncommitted changes beyond the conflicted files (tracked modified files that aren't part of the conflict), warn the user. These are at risk during resolution. Suggest committing or stashing them separately before proceeding, and wait for confirmation.
34
35	Do NOT blindly `git stash` when conflicts are already present — git won't allow it, and if the conflicts came from a `stash pop`, the user's changes are already in the working tree as the conflicted content. Stashing again would lose them.
36
37	## Step 1: Build Context
38
39	Understand what both sides of the conflict were trying to do:
40
41	1. Identify the two sides — Based on the conflict source:
42	- Merge: "ours" = current branch, "theirs" = the branch being merged in
43	- Stash pop: "ours" = current working tree (post-pull), "theirs" = the stashed changes (the user's local work)
44	- Rebase: "ours" = the branch being rebased onto, "theirs" = the commits being replayed
45
46	Understanding which side is which is critical — especially for stash pop conflicts where "theirs" is the user's own work and should generally be preserved.
47
48	2. Find all conflicts — Use Grep to search for `<<<<<<<` across the repo. This gives you the full list of files and locations.
49
50	3. Triage — Group conflicts before diving in:
51	- Trivial: Lock files, auto-generated files, whitespace-only — resolve mechanically.
52	- Straightforward: Both sides changed different things in the same region — combine them.
53	- Requires judgment: Both sides changed the same logic — need to understand intent.
54
55	## Step 2: Resolve Each Conflict
56
57	For each conflicted file, read the file (or at minimum the conflicted region with surrounding context), then decide:
58
59	1. Keep ours — when the incoming changes are superseded
60	2. Keep theirs — when the incoming side has the better version
61	3. Combine both — the most common case; merge both sides' intent into correct code
62
63	For stash pop conflicts: The user's stashed changes are their in-progress work. Default to preserving the user's intent — their local changes are the "important" side. The pulled/merged content is the "environment" that the user's work needs to be adapted to.
64
65	Correctness matters more than cleverness. When combining:
66	- Understand what each side was trying to do
67	- Write the result that achieves both goals
68	- Make sure imports, variable names, and types are consistent across the merged result
69
70	For each conflict:
71	1. Read the file to see the full conflict region with context
72	2. Edit the file to the desired final state — remove ALL conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
73	3. Stage the resolved file with `git add <file>`
74
75	After resolving all conflicts in a file, do a quick sanity check: does the file still make sense? Are imports consistent? Are there dangling references?
76
77	## Step 3: Verify — Close the Loop
78
79	After all conflicts are resolved, verification is mandatory, not optional. A merge that compiles is not a merge that works.
80
81	### 3a. Confirm clean state
82
83	```bash
84	git diff --check # No conflict markers remain
85	grep -rn '<<<<<<<' . # Belt-and-suspenders: grep for stray markers
86	```
87
88	If either finds markers, go back and fix them before proceeding.
89
90	### 3b. Determine affected projects
91
92	Check which parts of the

People who liked this also viewed

6 picks

Type