resolving-conflicts
Resolves merge conflicts during rebases, merges, and cherry-picks — reads both sides, understands intent from git history, auto-resolves clear-cut cases, and asks about ambiguous ones. Also handles end-to-end rebase workflows (fetch, rebase onto target, resolve, continue). Use when the user says "rebase onto main", "resolve conflicts", "fix these conflicts", "merge main in", "finish this rebase", or when a rebase/merge/cherry-pick has stopped due to conflicts.
What this skill does
# Resolving Conflicts Resolve merge conflicts intelligently by understanding the intent behind both sides of each conflict. ## Current context - Branch: !`git branch --show-current` - Status: !`git status --short` - Rebase in progress: !`test -d "$(git rev-parse --git-dir)/rebase-merge" -o -d "$(git rev-parse --git-dir)/rebase-apply" && echo "yes" || echo "no"` - Merge in progress: !`test -f "$(git rev-parse --git-dir)/MERGE_HEAD" && echo "yes" || echo "no"` - Cherry-pick in progress: !`test -f "$(git rev-parse --git-dir)/CHERRY_PICK_HEAD" && echo "yes" || echo "no"` ## Decision tree - What's the situation? - **Conflicts exist right now** (rebase/merge/cherry-pick in progress with unresolved conflicts) -> go to "Resolve conflicts" - **User wants to rebase onto another branch** (clean working tree, no operation in progress) -> go to "Start rebase" - **User wants to merge another branch in** -> go to "Start merge" - **Dirty working tree, wants to rebase** -> commit or stash first using the `creating-commits` skill, then go to "Start rebase" ## Start rebase ### 1. Determine the target Default target is `main` (or `master` if that's what the repo uses). If the user specified a branch, use that. ### 2. Fetch and rebase ```bash git fetch origin ``` ```bash git rebase origin/<target> ``` - **No conflicts** -> rebase completed cleanly. Go to "Finish". - **Conflicts** -> go to "Resolve conflicts" ## Start merge ```bash git fetch origin ``` ```bash git merge origin/<target> ``` - **No conflicts** -> merge completed cleanly. Go to "Finish". - **Conflicts** -> go to "Resolve conflicts" ## Resolve conflicts ### 1. Inventory conflicted files ```bash git diff --name-only --diff-filter=U ``` List all conflicted files. Process them one at a time. ### 2. For each conflicted file #### a. Read the conflict Read the file to see the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`). Understand what each side changed. #### b. Understand intent For each conflict, gather context: - `git log --oneline -5 -- <file>` on the current branch — what recent changes were made and why - `git log --oneline -5 REBASE_HEAD -- <file>` (or `MERGE_HEAD` / `CHERRY_PICK_HEAD`) — what the incoming side changed and why - Read surrounding code for context about what the conflicting section does #### c. Classify the conflict - **Clear-cut: one side only added** — the other side didn't touch those lines. Take the addition. - **Clear-cut: one side deleted, other unchanged** — the deletion wins (it was intentional). - **Clear-cut: non-overlapping edits** — both sides changed different things in the same region. Combine them. - **Clear-cut: identical changes** — both sides made the same change. Take either (they're the same). - **Clear-cut: import/dependency ordering** — both sides added imports or dependencies. Combine and sort. - **Ambiguous: both sides made substantive, different changes to the same lines** — needs human judgment. #### d. Resolve For **clear-cut** conflicts: - Edit the file to remove conflict markers and apply the resolution - Stage the file: `git add <file>` - Move to the next conflicted file For **ambiguous** conflicts: - Prepare your best resolution based on understanding both sides' intent - Show the user: - What each side was trying to do (with commit context) - Your proposed resolution - Why you chose this resolution - Use `AskUserQuestion` with options: - **Accept resolution** — use the proposed resolution - **Take ours** — keep the current branch's version - **Take theirs** — keep the incoming branch's version - Apply the chosen resolution, edit the file, and stage it ### 3. Continue the operation After all conflicts in the current round are resolved: ```bash git rebase --continue ``` (Or `git merge --continue` / `git cherry-pick --continue` depending on the operation.) If this produces **more conflicts** (common during rebase when replaying multiple commits), loop back to step 1 of "Resolve conflicts". Each round may have different files conflicting. If `git rebase --continue` needs a commit message, use the original commit message — don't modify it unless the resolution changed the commit's intent. ### 4. Repeat until done Keep resolving and continuing until the operation completes. Track progress: ```text Resolving commit 3/7: fix(auth): handle token expiry ``` ## Finish ### Show the result ```bash git log --oneline -10 ``` Show what the branch looks like after the operation. Summarize: - How many conflicts were resolved (and how many were auto-resolved vs. asked about) - Which commits were replayed (for rebase) ### Offer to push If the branch has a remote tracking branch and this was a rebase (which rewrites history): Use `AskUserQuestion`: - **Force-push** — run `git push --force-with-lease` to update the remote branch - **Don't push** — leave the changes local for now Always use `--force-with-lease` over `--force` — it's safer because it fails if someone else pushed to the branch in the meantime. For merges (which don't rewrite history), offer a regular `git push` instead. ## Aborting If the user wants to stop mid-resolution, or if the conflicts are too complex: ```bash git rebase --abort ``` (Or `git merge --abort` / `git cherry-pick --abort`.) This restores the branch to its state before the operation started. Always mention this option if the user seems unsure about a resolution.
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.