fix-merge-conflicts
Skill883 starsChanged 3 months agoMITView on GitHub
Resolve Git merge, rebase, or cherry-pick conflicts by preserving intent from both sides. Use when unmerged paths or conflict markers are present, especially when you must inspect the PR title and description tied to conflicting commits before choosing a resolution.
We split this skill into the rules it gives an agent
26 rules. 0 are common, 23 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
23
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Run preflight conflict detection.
- Distinctive: line 13
Read PR title and description to extract intent.
- Very specific: line 21
If there are no active unmerged paths, proactively merge latest origin/main to surface conflicts:
- Very specific: line 30
If git diff --name-only --diff-filter=U returns files, skip auto-merge and continue to conflict analysis.
- Distinctive: line 31
If it returns nothing, run:
- Distinctive: line 44
If conflicts now exist, continue with the rest of this workflow.
- Distinctive: line 45
If still no conflicts, report that no merge conflicts were detected and stop.
- Distinctive: line 57
Use git log --left-right --merge as the starting set of commits that influenced the conflicted hunks.
- Distinctive: line 61
Prefer GitHub metadata when available.
- Distinctive: line 72
If no associated PR is found, fall back to git show --stat COMMIT_SHA and commit message context.
- Distinctive: line 82
Write a short intent summary per side before editing code.
- Distinctive: line 86
Before finalizing any hunk where intents conflict, notify the user and ask for direction.
- Distinctive: line 88
Treat these as divergence signals:
- Distinctive: line 94
When divergence is detected:
- Distinctive: line 98
Ask one explicit resolution question.
- Distinctive: line 99
Wait for user response before applying the final hunk resolution.
- Distinctive: line 110
If the user chooses one side, preserve that side and salvage any non-conflicting behavior from the other side.
- Distinctive: line 111
If the user requests a hybrid, restate the hybrid rule before applying edits.
- Distinctive: line 118
Keep both behaviors if they are compatible.
- Distinctive: line 119
If incompatible, keep repository invariants and adapt the losing side's goal into a safe equivalent.
- Distinctive: line 120
Never silently drop behavior that was explicitly called out in a PR description.
- Distinctive: line 122
Avoid resolving by "take ours/theirs" unless the PR intent proves one side is obsolete.
- Distinctive: line 126
Run focused checks that cover touched behavior.
- Distinctive: line 133
Run broader checks when conflict scope is wide.
- Distinctive: line 142
Follow-up risk or test gap, if any
- Distinctive: line 144
If intent is ambiguous after reading PR metadata, ask one specific question before finalizing.
“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Resolve conflicts by intent, not by line order.
Workflow
- Run preflight conflict detection. If no local merge/rebase/cherry-pick conflicts are present, automatically fetch and merge
origin/main. - Identify conflicted files and candidate commits.
- Map each conflicting commit to its PR.
- Read PR title and description to extract intent.
- Detect intent divergence and request user intervention.
- Resolve conflicts to preserve both intents when compatible.
- Validate behavior with targeted checks.
- Summarize decisions and any tradeoffs.
0) Preflight: Ensure a Conflict Exists
If there are no active unmerged paths, proactively merge latest origin/main to surface conflicts:
git status --porcelain
git diff --name-only --diff-filter=UDecision rule:
- If
git diff --name-only --diff-filter=Ureturns files, skip auto-merge and continue to conflict analysis. - If it returns nothing, run:
git fetch origin
git merge origin/mainThen re-check:
git diff --name-only --diff-filter=U- If conflicts now exist, continue with the rest of this workflow.
- If still no conflicts, report that no merge conflicts were detected and stop.
1) Identify Conflict Scope
Run:
git status --porcelain
git diff --name-only --diff-filter=U
git log --left-right --merge --onelineUse git log --left-right --merge as the starting set of commits that influenced the conflicted hunks.
2) Map Commits to PRs
Prefer GitHub metadata when available.
- Parse owner/repo from
origin. - For each conflicting commit SHA, query associated PRs.
gh api graphql \
-f query='query($owner:String!,$repo:String!,$sha:GitObjectID!){repository(owner:$owner,name:$repo){object(oid:$sha){... on Commit{associatedPullRequests(first:5){nodes{number title body url mergedAt baseRefName headRefName}}}}}}' \
-F owner=OWNER -F repo=REPO -F sha=COMMIT_SHAIf no associated PR is found, fall back to git show --stat COMMIT_SHA and commit message context.
3) Extract Intent
For each relevant PR, capture:
- Goal stated in title
- Constraints, caveats, or behavioral expectations from description
- Any explicitly non-goals
Write a short intent summary per side before editing code.
4) Divergence Checkpoint (User Intervention Required)
Before finalizing any hunk where intents conflict, notify the user and ask for direction.
Treat these as divergence signals:
- Both sides change the same behavior with incompatible outcomes
- One side explicitly rejects behavior the other side introduces
- Either PR description states a constraint that the other side would violate
When divergence is detected:
- Pause editing for that hunk.
- Provide a short comparison of intent A vs intent B.
- Ask one explicit resolution question.
- Wait for user response before applying the final hunk resolution.
Question format:
Intent divergence detected in <file>:<hunk>.
Option A (PR #X): <one-line intent>
Option B (PR #Y): <one-line intent>
Which intent should be primary for this hunk?If the user chooses one side, preserve that side and salvage any non-conflicting behavior from the other side. If the user requests a hybrid, restate the hybrid rule before applying edits.
5) Resolve by Preserving Intent
For each conflict hunk:
- Explain what each side is trying to preserve.
- Keep both behaviors if they are compatible.
- If incompatible, keep repository invariants and adapt the losing side's goal into a safe equivalent.
- Never silently drop behavior that was explicitly called out in a PR description.
Avoid resolving by "take ours/theirs" unless the PR intent proves one side is obsolete.
6) Validate
Run focused checks that cover touched behavior. In this repository, prefer:
pnpm --filter libretto-cli type-check
pnpm --filter libretto-cli test -- <relevant-test-file>Run broader checks when conflict scope is wide.
7) Report
Provide a concise summary:
- Files resolved
- PR intents preserved
- Any intentional compromise and why
- Follow-up risk or test gap, if any
If intent is ambiguous after reading PR metadata, ask one specific question before finalizing.
Other versions10 projects use a version of this.
Word for word · 1
- cashew-labs/libretto★ 898100% same
Edited · 0
None found.
Wrote their own version · 9
- ulises-jeremias/agent-toolkit★ 19same name
- Scino/fstack★ 18same name
- jimyag/dotfiles★ 11same name
- cogine-ai/cogine-dev-skillset★ 4same name
- dhanji4U/skills★ 2same name
- jaydubya818/MissionControl★ 2same name
- ElyzeSolutions/skills★ 1same name
- RoyBkker/agent-skills★ 1same name
- ArchitektApx/cursor-skills-for-claude★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use loop-on-ci, check-compiler-errors and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
cogine-aiSkillloop-on-ci
Monitor PR checks and fix failures until green. Uses gh pr checks as the source of truth for PR-attached checks.
Also in 4 projects that use this
cogine-aiSkillcheck-compiler-errors
Run compile and type-check commands and report failures
Also in 3 projects that use this
MicrosoftSkillrun-smoke-tests
Run smoke tests to verify extension functionality in a real VS Code environment. Use this when checking if basic features work after changes.
Also in 3 projects that use this
- +1 more from cogine-ai
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .deepsec/AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- .opencode/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- address-reviewSkill
- cli-developmentSkill
- erroreSkill
- external-electron-appsSkill
- generate-specSkill
- generate-spec-v2Skill
- get-pr-reviewsSkill
- glimpse-changesSkill
- implement-specSkill
- improve-codebase-architectureSkill
- libretto-readonlySkill
- librettoSkill
- promptingSkill
- push-everythingSkill
- pushSkill
- reviewSkill
- spec-reviewSkill
- summarizeSkill
- technical-writingSkill
- turborepoSkill
- update-docsSkill
- writing-testsSkill
- libretto-readonlySkill
- librettoSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

