pull-changes-resolve-conflicts

Pull changes & resolve merge conflicts

Use this skill whenever integrating another branch (usually main) into the current feature branch, or when git status shows unmerged paths after a merge or rebase. Applies to any Git-based team workflow; Flows/React apps are a common case where conflicts cluster in app shells and shared libraries.

Goals

• Preserve intentional work on the current branch; do not assume “main wins” or “ours wins” without analysis.
• Make trade-offs visible to the user before any conflict resolution edits.
• Order discussion by impact: structural / feature / API / data-model changes before styling, copy, or spacing.

Hard rules

1. No silent resolution — Do not remove <<<<<<< / ======= / >>>>>>> or run git add on conflicted files until the user has agreed to the plan (or explicitly says “use your recommendations”).
2. Stop at conflicts — If a merge or rebase introduces conflicts, pause and report; do not bulldoze through large files by picking one side wholesale unless the user explicitly requests that.
3. Prioritize impact — When presenting conflicts, group and order roughly as:
   • P0 — Structural / product: removed routes, deleted modules, dropped features, changed data or API contracts, SDK or schema changes, auth or routing shell.
   • P1 — Behavior: logic, hooks, queries, filters, error handling, loading states.
   • P2 — UI structure: layout regions, new or removed sections, navigation.
   • P3 — Presentation: tokens, spacing, class names, copy tweaks.

Pull changes & resolve merge conflicts

Use this skill whenever integrating another branch (usually main) into the current feature branch, or when git status shows unmerged paths after a merge or rebase. Applies to any Git-based team workflow; Flows/React apps are a common case where conflicts cluster in app shells and shared libraries.

Goals

• Preserve intentional work on the current branch; do not assume “main wins” or “ours wins” without analysis.
• Make trade-offs visible to the user before any conflict resolution edits.
• Order discussion by impact: structural / feature / API / data-model changes before styling, copy, or spacing.

Hard rules

1. No silent resolution — Do not remove <<<<<<< / ======= / >>>>>>> or run git add on conflicted files until the user has agreed to the plan (or explicitly says “use your recommendations”).
2. Stop at conflicts — If a merge or rebase introduces conflicts, pause and report; do not bulldoze through large files by picking one side wholesale unless the user explicitly requests that.
3. Prioritize impact — When presenting conflicts, group and order roughly as:
   • P0 — Structural / product: removed routes, deleted modules, dropped features, changed data or API contracts, SDK or schema changes, auth or routing shell.
   • P1 — Behavior: logic, hooks, queries, filters, error handling, loading states.
   • P2 — UI structure: layout regions, new or removed sections, navigation.
   • P3 — Presentation: tokens, spacing, class names, copy tweaks.