{"id":17551,"plugin_id":"plugins_6a78e83987748191afc0c56e12172fce","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:15.523Z","digest":"25f9002b6287241b5a711fa583aa169ec409cb873bce21ff94ce172cf764fd0d","against":null,"payload":{"description":"Resolve in-progress git merge or rebase conflicts by intent traced to primary sources. Use when hit with merge conflicts, CONFLICT markers in files, rebase pauses, or when git prompts to resolve conflicted hunks — even if the user just says \"fix this merge\". Do NOT use for creating new branches or routine rebasing without conflicts.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":113}],"name":"resolving-merge-conflicts","skill_md_contents":"---\nname: resolving-merge-conflicts\ndescription: \"Resolve in-progress git merge or rebase conflicts by intent traced to primary sources. Use when hit with merge conflicts, CONFLICT markers in files, rebase pauses, or when git prompts to resolve conflicted hunks — even if the user just says \\\"fix this merge\\\". Do NOT use for creating new branches or routine rebasing without conflicts.\"\n---\n\n# Resolving Merge Conflicts\n\nSystematically resolve in-progress Git merge and rebase conflicts by identifying the semantic intent of both branches and verifying integration integrity with automated test gates.\n\n---\n\n## Core Invariants\n\n1. **3-Way Intent Reconstruction**: Understand the common merge-base ancestor, the incoming changes (`THEIRS`), and the target branch changes (`OURS`) before altering conflicted code.\n2. **Never Blindly Choose Ours or Theirs**: Inspect every conflict hunk individually; synthesize solutions that preserve the functional requirements of both branches.\n3. **Zero Orphaned Conflict Markers**: Verify that all `<<<<<<<`, `=======`, and `>>>>>>>` markers are completely eliminated before staging.\n4. **Non-Destructive Resolution**: Preserve adjacent unchanged code, comments, and docstrings; avoid accidental line deletions outside conflict hunks.\n5. **Mandatory Post-Resolution Test Pass**: Execute the full build, typecheck, and test suite before concluding the merge (`git commit`) or rebase (`git rebase --continue`).\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Merge/Rebase Conflict Detected ] ──► [ Identify 3-Way Merge Base & Commits ] ──► [ Hunk-by-Hunk Semantic Synthesis ] ──► [ Build & Test Gate ]\n```\n\n| Phase | Responsibility | Verification Command |\n|---|---|---|\n| **Conflict Discovery** | Identify all unmerged files | `git status --porcelain | grep \"^UU\\|^AA\\|^DU\\|^UD\"` |\n| **Ancestor Inspection** | View base version of conflicted file | `git show :1:<file>` (Base), `:2:<file>` (Ours), `:3:<file>` (Theirs) |\n| **Integration Gate** | Run compiler, linter, and unit tests | Project build / test command |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Identify Conflicted Files and Merge Context\n- **Action**: Run `git status` to enumerate all conflicted files and inspect recent commit logs on both branches:\n  ```bash\n  git log --oneline -n 5 HEAD\n  git log --oneline -n 5 MERGE_HEAD # or REBASE_HEAD\n  ```\n- **Key Point**: Determine what feature or bug fix each branch was attempting to deliver.\n- **Why**: Understanding developer intent prevents resolving conflicts with syntax-valid but semantically broken hybrids.\n\n### Step 2: Resolve Conflicting Hunks Semantically\n- **Action**: Open each conflicted file, analyze the diff hunks between `HEAD` (Ours) and incoming (Theirs), and rewrite the block to satisfy both requirements.\n- **Key Point**: If both branches added new imports, dependencies, or routes, combine them cleanly without duplicates.\n- **Inline Checklist**:\n  - [ ] All conflict markers (`<<<`, `===`, `>>>`) removed\n  - [ ] Duplicate imports and exports deduplicated\n  - [ ] New functionality from both branches retained\n\n### Step 3: Verify with Build & Test Suite\n- **Action**: Run the repository's typechecker, linter, and test suite across the resolved working tree.\n- **Key Point**: If tests fail, investigate whether resolving the conflict broke subtle runtime assumptions.\n- **Why**: Many merge conflicts compile cleanly but introduce logical regressions that only tests catch.\n\n### Step 4: Stage and Conclude Merge/Rebase\n- **Action**: Stage the resolved files (`git add <files>`) and complete the operation:\n  - For merge: `git commit` (preserving standard merge commit message).\n  - For rebase: `git rebase --continue`.\n- **Key Point**: Check `git status` to ensure the working tree is clean.\n- **Why**: Clean conclusion ensures upstream CI pipelines can build the merged branch without human intervention.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"Accept 'ours' or 'theirs' completely with `git checkout --ours` to be fast.\"* | **Forbidden on semantic conflicts.** | Blanket checkouts overwrite valid work and revert critical bug fixes from one branch. |\n| *\"Delete the failing test to get the merge commit through.\"* | **Fix the code to make tests pass.** | Deleting tests lowers coverage and introduces regressions into production. |\n| *\"Assume the code is fine without running the full test suite.\"* | **Mandatory test pass before committing merge.** | Resolving conflicts manually frequently introduces syntax errors and broken imports. |\n\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}