一键导入
resolve-conflicts
Resolve git conflicts with AI-powered analysis, including mergiraf structural merging, lock file handling, and stacked PR duplicate detection.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Resolve git conflicts with AI-powered analysis, including mergiraf structural merging, lock file handling, and stacked PR duplicate detection.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Monitor CI checks after pushing, detect flaky vs legit failures, and auto-fix
End-of-day counterpart to wake-me-up. Reads today's morning briefing at ~/dev/ai/notes/wake-me-up/{date}.md, asks the user what they shipped or resolved, drafts a Slack wrap-up post in the user's voice, shows the draft for explicit confirmation, then posts it on the user's behalf via the Slack MCP. Appends the posted summary back to the briefing file so the file is a full day record. Use when the user says "/closing-time", "wrap the day", "end of day post", or wants help summarizing what they did.
Commit staged/unstaged changes with a well-crafted commit message.
Create or update a GitHub PR with automatic template detection and filling
Plan, implement, and iteratively review a task end-to-end using Claude + Copilot reviewers in a linear flow.
Investigate what it would take to upgrade a library from its currently pinned version to a target version (or "latest"). Produces a migration assessment — version delta, breaking changes that apply to us, impacted files, estimated blast radius, suggested rollout — and STOPS there. Does not perform the upgrade unless the user explicitly asks. Use when the user says "investigate updating <pkg> from X to Y", "investigate updating <pkg> to latest", "we are behind on <pkg>", or "let's update <pkg> to version N".
| name | resolve-conflicts |
| description | Resolve git conflicts with AI-powered analysis, including mergiraf structural merging, lock file handling, and stacked PR duplicate detection. |
| argument-hint | ["--abort|--continue"] |
Resolve conflicts from any git operation (rebase, merge, cherry-pick, revert) with intelligent handling of lock files, migrations, mergiraf-supported languages, and stacked PR duplicates.
--abort: abort the current operation--continue: skip resolution, just run the appropriate continue commandExample invocations:
/resolve-conflicts -- detect context, resolve conflicts, continue/resolve-conflicts --abort -- abort current rebase/merge/cherry-pick/revert/resolve-conflicts --continue -- continue without resolving (e.g., after manual edits)Run the status script:
~/.claude/skills/resolve-conflicts/scripts/conflict-status.sh
This outputs tab-separated: context\tprogress\tbranch
Parse the fields:
context: one of rebase, merge, cherry-pick, revert, noneprogress: current/total for rebase (e.g., 3/12), empty for other contextsbranch: the branch being worked onCheck for unmerged files:
git diff --name-only --diff-filter=U
Route based on context, unmerged files, and arguments:
| Context | Unmerged files? | Argument | Action |
|---|---|---|---|
| none | n/a | --abort | Report "No operation in progress" and stop |
| none | n/a | none/--continue | Report "No conflicts to resolve" and stop |
| active | n/a | --abort | Run git <context> --abort, report "Aborted <context>. Back on <branch>.", and stop |
| active | no | none/--continue | Run git <context> --continue (use git commit --no-edit for merge) |
| active | yes | --continue | Run git <context> --continue (use git commit --no-edit for merge) |
| active | yes | none | Go to Step 2 (Resolve Conflicts) |
Run:
~/.claude/skills/resolve-conflicts/scripts/categorize-conflicts.sh
This outputs tab-separated lines: category\tfile_path
Report the categorization to the user, e.g.:
Conflicts (rebase step 3/12):
- 1 lockfile:
package-lock.json- 2 mergiraf:
src/app.ts,src/utils.ts- 1 migration:
migrations/0042_add_column.py
For non-rebase contexts, omit the step count:
Conflicts (merge):
Process conflicts in this order:
1. Lock files (lockfile)
Accept theirs to clear the conflict markers. The content doesn't matter since Step 3 regenerates lock files from the resolved dependency manifest, but always choosing theirs keeps the behavior deterministic:
git checkout --theirs <file> && git add <file>
Track which lock files need regeneration (handled in Step 3).
2. Migrations (migration)
Do not auto-resolve. Ask the user how to proceed for each migration file. Common options:
git checkout --theirs <file>) — during merge/cherry-pick/revert this is the incoming branch; during rebase this is the commit being replayed (i.e., your branch)git checkout --ours <file>) — during merge/cherry-pick/revert this is the current branch; during rebase this is the upstream branch you're rebasing onto3. Mergiraf-supported files (mergiraf)
Run mergiraf as a second pass (it may have already run as a merge driver during the git operation itself, but sometimes conflicts remain). It is installed and configured as a git merge driver:
mergiraf solve -- <file> --compact
After running mergiraf, read the file and check for remaining conflict markers (<<<<<<<). If conflict markers remain, proceed with AI analysis (see Step 2c).
If mergiraf fully resolves the file (no markers remain), stage it:
git add <file>
4. Other files (other)
Read the file contents and resolve using AI analysis (see Step 2c).
For conflicts that remain after mergiraf (or for other category files), read the file and analyze each conflict hunk. Conflict markers may appear in diff3 style (with a base section) or standard style (without). Handle both:
diff3 style (preferred, enabled via merge.conflictStyle = diff3):
<<<<<<< HEAD
[head_code]
||||||| base
[base_code]
=======
[incoming_code]
>>>>>>> commit message
Standard style (no base section):
<<<<<<< HEAD
[head_code]
=======
[incoming_code]
>>>>>>> commit message
Stacked PR duplicate detection:
When the base section is empty or contains substantially less code than both sides, this often indicates a stacked PR scenario where a sub-PR was merged, duplicating code that also exists in the feature branch.
| Base | HEAD vs Incoming | Action |
|---|---|---|
| Empty or missing code | >95% similar (after normalizing whitespace) | Auto-resolve: keep HEAD version, report to user |
| Empty or missing code | 70-95% similar | Ask user: show both versions side-by-side, explain likely stacked PR context |
| Empty or missing code | <70% similar | Ask user: true divergence, present both options |
| Present | Both modified | Ask user: standard conflict, present analysis |
For auto-resolutions, always report clearly what was resolved and why:
Auto-resolved
src/feature.tshunk at line 42: stacked PR duplicate (HEAD and incoming are 98% similar with empty base). Kept HEAD version.
For all other cases, present the conflict to the user with your analysis and recommendation, then apply their choice.
After resolving all hunks in a file, stage it: git add <file>
After all conflicts are resolved and staged:
If lock files were resolved, regenerate them now:
package-lock.json -- npm installpnpm-lock.yaml -- pnpm installyarn.lock -- yarn installbun.lockb or bun.lock -- bun installCargo.lock -- cargo generate-lockfilepoetry.lock -- poetry lock --no-updateGemfile.lock -- bundle installcomposer.lock -- composer installgit add <lockfile>Run the appropriate continue command:
| Context | Continue command |
|---|---|
| rebase | git rebase --continue |
| merge | git commit --no-edit |
| cherry-pick | git cherry-pick --continue |
| revert | git revert --continue |
If more conflicts arise (rebase), loop back to Step 2
When complete, report a summary: conflicts resolved (auto-resolved vs user-resolved), lock files regenerated, and rerere resolutions if any were applied (rerere is enabled globally and records/replays resolutions automatically)