# Hk Merge Resolve

> >

- **Type:** Skill
- **Install:** `agentstack add skill-deepklarity-harness-kit-hk-merge-resolve`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [deepklarity](https://agentstack.voostack.com/s/deepklarity)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [deepklarity](https://github.com/deepklarity)
- **Source:** https://github.com/deepklarity/harness-kit/tree/main/.claude/skills/hk-merge-resolve

## Install

```sh
agentstack add skill-deepklarity-harness-kit-hk-merge-resolve
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Resolve Merge Conflicts

Your job is to resolve all merge conflicts in the current branch of the current repo.

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.

## Step 0: Diagnose the Situation

Before changing anything, understand what state git is in and what caused the conflicts.

1. **Snapshot the state** — Run these to understand what's happening:
   ```bash
   git status
   git rev-parse HEAD
   ```
   Print the HEAD sha to the user: "Safety checkpoint: HEAD is at ``."

2. **Identify the conflict source** — Check which operation is in progress:
   - `git rev-parse MERGE_HEAD 2>/dev/null` → merge in progress
   - `test -d .git/rebase-merge || test -d .git/rebase-apply` → rebase in progress
   - `git stash list` + check `git status` for "Unmerged paths" without MERGE_HEAD → stash pop conflict

   This matters because the abort/recovery command differs:
   | Source | Abort command |
   |--------|--------------|
   | merge | `git merge --abort` |
   | rebase | `git rebase --abort` |
   | cherry-pick | `git cherry-pick --abort` |
   | stash pop | `git checkout -- .` (stash stays in list, nothing lost) |

   Print the appropriate abort command to the user so they have an escape hatch.

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**.

   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.

## Step 1: Build Context

Understand what both sides of the conflict were trying to do:

1. **Identify the two sides** — Based on the conflict source:
   - **Merge**: "ours" = current branch, "theirs" = the branch being merged in
   - **Stash pop**: "ours" = current working tree (post-pull), "theirs" = the stashed changes (the user's local work)
   - **Rebase**: "ours" = the branch being rebased onto, "theirs" = the commits being replayed

   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.

2. **Find all conflicts** — Use Grep to search for `>>>>>>`)
3. Stage the resolved file with `git add `

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?

## Step 3: Verify — Close the Loop

After all conflicts are resolved, verification is **mandatory**, not optional. A merge that compiles is not a merge that works.

### 3a. Confirm clean state

```bash
git diff --check          # No conflict markers remain
grep -rn '/dev/null || \
  git diff --name-only HEAD~1 HEAD  # fallback for rebase/cherry-pick
```

Map changed files to projects:

| Path prefix | Project | Check commands |
|-------------|---------|---------------|
| `taskit/taskit-frontend/` | Frontend | `npm run build` (TypeScript + Vite), `npm run lint` |
| `taskit/taskit-backend/` | Backend | `cd taskit/taskit-backend && python manage.py check --deploy 2>/dev/null || python manage.py check` |
| `odin/` | Odin | `cd odin && python -m pytest tests/unit/ -v` |
| `harness_usage_status/` | Harness Usage | `cd harness_usage_status && python -m pytest tests/ -v 2>/dev/null` |

### 3c. Run check commands for affected projects

Run **only** the checks for projects that had conflicted files or files changed by the merge. Do not run checks for unaffected projects — that wastes time and may surface pre-existing issues unrelated to the merge.

**Execution order:**
1. **Type checks / build** first — catches structural problems (missing imports, type errors, broken references). These are the most likely merge casualties.
2. **Lint** second — catches style issues introduced by conflict resolution.
3. **Fast tests** last — unit tests for the affected project. Skip integration/e2e tests (too slow for merge verification; those belong in CI).

For each check:
- Run the command
- If it **passes**: note it and move on
- If it **fails**: analyze the failure. If it's clearly caused by the merge resolution (missing import, type mismatch, duplicated declaration), fix it immediately and re-run. If it's a pre-existing failure unrelated to the merge, note it for the user but don't block on it.

**Frontend-specific** (most common merge casualty in this repo):
```bash
cd taskit/taskit-frontend && npm run build
```
This runs TypeScript type-checking AND Vite bundling — it catches duplicate imports, missing exports, type mismatches, and broken references. This single command is the highest-value check for frontend merges.

**Backend-specific:**
```bash
cd taskit/taskit-backend && python manage.py check
```
Catches model inconsistencies, migration conflicts, and configuration problems.

**Odin-specific:**
```bash
cd odin && python -m pytest tests/unit/ -v --tb=short
```
Fast unit tests only. Mock and integration tests are too slow for merge verification.

### 3d. Report results

After all checks complete, print a summary:

```
Merge verification:
  ✓ No conflict markers remaining
  ✓ Frontend build passed (TypeScript + Vite)
  ✓ Frontend lint passed
  ✗ Backend check failed — missing migration (see output above)
  — Odin tests skipped (no odin/ files in merge)
```

If any check failed due to the merge, fix it before completing the merge operation (`git merge --continue`, `git rebase --continue`, etc.). Do NOT finalize a merge with known check failures — that defeats the purpose of conflict resolution.

### 3e. Complete the merge operation

Only after all checks pass (or pre-existing failures are identified and noted):

- **Merge**: `git commit` (git usually has the merge commit staged already)
- **Rebase**: `git rebase --continue`
- **Cherry-pick**: `git cherry-pick --continue`
- **Stash pop**: No git command needed — files are already in working tree

Ask the user before running the finalization command.

## When You're Not Sure

If a conflict involves complex logic where both sides made substantial changes to the same code, and you're not confident about the correct resolution — **stop and ask**.

Show the user:
1. The conflicting chunks (both sides)
2. Your understanding of what each side intended
3. Your proposed resolution (or the options you see)

Then wait for confirmation before editing. A wrong merge is worse than a slow merge.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [deepklarity](https://github.com/deepklarity)
- **Source:** [deepklarity/harness-kit](https://github.com/deepklarity/harness-kit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-deepklarity-harness-kit-hk-merge-resolve
- Seller: https://agentstack.voostack.com/s/deepklarity
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.