Agent-Skills.md

Agent Skills: /git:resolve-conflicts

|

UncategorizedID: laurigates/claude-plugins/git-resolve-conflicts

Repository

laurigates/claude-plugins
laurigatesLicense: MIT
234

Install this agent skill to your local

pnpm dlx add-skill https://github.com/laurigates/claude-plugins/tree/HEAD/git-plugin/skills/git-resolve-conflicts

Skill Files

Browse the full folder contents for git-resolve-conflicts.

Download Skill

Loading file tree…

git-plugin/skills/git-resolve-conflicts/SKILL.md

Skill Metadata

Name
git-resolve-conflicts
Description
|

/git:resolve-conflicts

Resolve merge conflicts in pull requests automatically.

When to Use This Skill

| Use this skill when... | Use git-ops agent instead when... | |------------------------|-----------------------------------| | PR has merge conflicts with base branch | Complex multi-branch rebase workflows | | Automated merge failed due to conflicts | Cherry-pick conflicts across many commits | | Config files (JSON, YAML) diverged | Conflicts require deep business logic understanding | | Base branch updates caused conflicts | Interactive rebase with squash/fixup needed |

Context

  • Current branch: !git branch --show-current
  • Git status: !git status --porcelain=v2 --branch
  • Conflicted files: !git diff --name-only --diff-filter=U
  • Recent commits on current branch: !git log --format='%h %s' --max-count=5

Parameters

Parse these from $ARGUMENTS:

  • $1: PR number (if not provided, detect from current branch)
  • --push: Push resolved conflicts after committing

Execution

Execute this conflict resolution workflow:

Step 1: Identify the PR and conflicts

  1. If PR number provided, fetch PR details: gh pr view <number> --json headRefName,baseRefName,mergeable
  2. If no PR number, detect from current branch: gh pr list --head $(git branch --show-current) --json number,baseRefName,mergeable
  3. Check if conflicts exist (mergeable == "CONFLICTING")

Step 2: Set up the merge

  1. Fetch latest base branch: git fetch origin <base-branch>
  2. If not already in a conflicted merge state, start the merge: git merge origin/<base-branch> --no-ff
  3. If merge succeeds cleanly, report "No conflicts to resolve" and exit

Step 3: Resolve each conflicted file

For each file listed by git diff --name-only --diff-filter=U:

  1. Read the file to see conflict markers (<<<<<<<, =======, >>>>>>>)
  2. Understand both sides:
    • HEAD: Changes from the PR branch (the feature work)
    • Incoming: Changes from the base branch (landed since PR opened)
  3. Apply resolution strategy based on file type:

| File Type | Strategy | |-----------|----------| | JSON config (package.json, plugin.json, marketplace.json) | Merge objects/arrays, take higher versions | | YAML config | Merge keys from both sides | | Markdown (CHANGELOG, README) | Include content from both sides | | Source code | Integrate both changes preserving logic | | Lock files | Regenerate after resolving other conflicts |

  1. Edit the file to remove ALL conflict markers and combine changes
  2. Stage: git add <file>

Step 4: Verify and commit

  1. Check no conflict markers remain: search resolved files for <<<<<<<
  2. Check git status is clean (no remaining unmerged paths)
  3. Commit: git commit --no-edit
  4. If --push flag provided: git push origin <branch>

Step 5: Report results

Comment on the PR with resolution summary:

gh pr comment <number> --body "Merge conflicts with <base-branch> resolved automatically.

Resolved files:
- file1.json (merged entries from both sides)
- file2.md (combined changelog entries)
"

Conflict Resolution Patterns

JSON Files (marketplace.json, plugin.json, release-please configs)

  • Merge array entries from both sides, deduplicate
  • For version fields, take the higher version
  • For object properties, include properties from both sides

Markdown Files (CHANGELOG, README)

  • Include content from both sides
  • For changelogs, maintain chronological order
  • For tables, include rows from both sides

Source Code

  • Read surrounding context to understand intent of both changes
  • Integrate both modifications, preserving the logic of each
  • If changes are to the same line with incompatible intent, prefer the PR branch change and note in the commit

When to Abort

Abort with git merge --abort if:

  • Conflicts require understanding business requirements to resolve
  • Both sides made fundamentally incompatible architectural changes
  • Lock files are the only conflicts (suggest --push after regenerating)

Agentic Optimizations

| Context | Command | |---------|---------| | List conflicts | git diff --name-only --diff-filter=U | | Conflict details | git diff --diff-filter=U | | PR mergeable state | gh pr view N --json mergeable | | Check markers remain | grep -rn '<<<<<<<' <files> | | Porcelain status | git status --porcelain=v2 |