Agent Skills › penpot/penpot › resolve-git-conflicts

resolve-git-conflicts

GitHub

用于分析本地 Git 仓库中的合并、变基或拣选冲突，制定详细的解决计划并等待用户批准，随后执行文件修改、暂存和验证，但不自动继续操作。

.agents/skills/resolve-git-conflicts/SKILL.md penpot/penpot

Trigger Scenarios

用户请求解决冲突检测到未解决的 Git 冲突状态

Install

npx skills add penpot/penpot --skill resolve-git-conflicts -g -y

More Options

Non-standard path

npx skills add https://github.com/penpot/penpot/tree/develop/.agents/skills/resolve-git-conflicts -g -y

Use without installing

npx skills use penpot/penpot@resolve-git-conflicts

指定 Agent (Claude Code)

npx skills add penpot/penpot --skill resolve-git-conflicts -a claude-code -g -y

安装 repo 全部 skill

npx skills add penpot/penpot --all -g -y

预览 repo 内 skill

npx skills add penpot/penpot --list

SKILL.md

Frontmatter

{
    "name": "resolve-git-conflicts",
    "description": "Conflict resolution flow — understand the local git conflicts, present a resolution plan, and resolve them after the user approves it. Never continues the rebase. Use it when the repo has unresolved conflicts (rebase, merge, cherry-pick) or the user asks to resolve them."
}

Resolve Git Conflicts

Resolve conflicts in the local repository. The user handles finishing the rebase themselves — you must never run git rebase --continue, git rebase --skip, git merge --continue, or anything similar.

When to use

The repository has unresolved conflicts — during a rebase, merge, or cherry-pick — whether the user asks about them or not.
The user asks to resolve conflicts, in any phrasing: "fix the merge conflicts", "resolve these", "what's conflicting here?".

Phase 1 — Understand the problem (read-only)

Run git status to detect the conflict state (rebase, merge, cherry-pick, etc.) and list conflicted files.
For each conflicted (unmerged) file, understand the situation without modifying anything:
- Read the file and identify the conflict markers (<<<<<<<, =======, >>>>>>>).
- Inspect both sides — git show <ours>:<file> and git show <theirs>:<file> — plus git log/git show on the commits involved to understand intent.
- Identify what each side changed and why, and how they should be combined.

Phase 2 — Present the resolution plan

Present a clear plan to the user before touching any file. For each conflicted file, state:
- What each side changed and why.
- Your proposed resolution and the reasoning behind it.
- How the two sides are combined (both additive → merge; both modify the same code → keep the semantically correct version, merging intent from both sides when clear from code and context).
Ask the user only when genuinely unclear. Do not ask about anything you can determine yourself from the code, commit messages, or context. Only decisions that are not determinable and change the outcome (e.g. conflicting product decisions, which side to discard) warrant a question. Collect all such questions together in an "Open Questions" section at the end of the plan, so the user has full context to answer them properly.
Wait for the user to accept the plan (and answer any open questions) before editing, staging, or otherwise modifying anything.

Phase 3 — Execute

Resolve each conflicted file by editing the file to the agreed merged content and removing all conflict markers.

Phase 4 — Stage and verify

Stage every resolved file with git add <file>. Do not stage unrelated untracked files unless clearly part of the resolution.
Verify no conflict markers remain (search for <<<<<<< / >>>>>>> in resolved files) and that git status shows no unmerged paths.

Phase 5 — Report

Briefly report the conflict state, how each conflicted file was resolved (and any answers received to open questions), and stop — do not run git rebase --continue or any other continuation command.