Resolve Conflicts

Core Question

What conflict resolution preserves the intended changes from all relevant sides, avoids unrelated staging, and can be verified before continuation?

When To Use

Use this skill when:

• git status shows unmerged paths,
• conflict markers exist,
• merge, rebase, cherry-pick, or revert is in progress,
• the user asks to inspect, explain, resolve, stage, or continue after conflicts.

When Not To Use

Do not use this skill for branch sync before conflicts exist, destructive recovery, ordinary commit splitting, or tag/version/release work.

Route to:

• branch-workflow for starting sync, pull, merge, or rebase before conflicts exist.
• undo-recover for abort, reset, clean, reflog, destructive recovery, or broad unstaging by default.
• atomic-commits after conflicts are resolved and the user wants commits organized.
• conventional-commits for message-only work.

Required Evidence

Before resolution, inspect or establish:

• git status --short --branch,
• current operation type: merge, rebase, cherry-pick, or revert,
• unmerged path list,
• conflict markers and conflicted file contents,
• ours/theirs/base versions when needed,
• semantic context around each conflict,
• generated-file or lockfile policy,
• relevant tests/build commands when discoverable,
• secret-like values in conflict text.

Operating Contract

This skill owns conflict inventory, explanation, file-level resolution, validation, staging of resolved files, and explicitly requested continue operations after verification.

Abort, reset, cleanup, and recovery are owned by undo-recover unless the user explicitly asks this skill to perform a narrow abort after the risk has been explained.

You MAY:

• inspect conflicts and operation state,
• resolve conflicted files narrowly,
• stage only resolved files,
• run targeted verification,
• continue an operation only after verification and explicit request.

You MUST:

• inspect both sides before choosing a resolution,
• preserve valid changes from all relevant sides when possible,
• remove all conflict markers before staging,
• explain assumptions in semantic conflicts,
• verify no unresolved paths remain before continue,
• treat rebase/cherry-pick continuation as R4/R5 when history may be affected.

You MUST NOT:

• use global ours/theirs,
• stage unrelated files,
• continue or abort automatically,
• delete files to resolve conflicts without explicit evidence and confirmation,
• overwrite generated/lock files without project evidence,
• expose secret-like conflict content.

State / Risk Table

Workflow

1. Identify operation type and user goal.
2. Inspect status, unmerged paths, and conflicted files.
3. Classify conflict type and risk.
4. Inspect ours/theirs/base and semantic context as needed.
5. Choose the narrowest resolution or ask when intent is ambiguous.
6. Edit only conflicted files required for the resolution.
7. Verify no conflict markers and no unresolved paths remain.
8. Stage only resolved files when requested and safe.
9. Run targeted verification when available.
10. Continue operation only when explicitly requested and verified.
11. Report evidence, resolution, verification, and remaining risk.

Decision Rules

• Prefer semantic preservation over mechanical side selection.
• Do not use global ours/theirs.
• Do not stage unrelated files.
• Do not continue or abort operations automatically.
• For rebase, explain ours/theirs semantics before applying a side-based resolution.
• If conflict resolution work already exists, aborting may discard it; require explicit confirmation.
• For additive non-overlapping changes, preserve both sides when semantically valid.
• For generated files, prefer regeneration when project evidence identifies the generator.
• For lockfiles, prefer the package manager when project evidence identifies the ecosystem.
• If tests are unavailable, report verification limitation.

Workflow Guardrails

Abort / Continue Operation

Trigger:

• The user asks to abort, continue, skip, or finalize a merge, rebase, cherry-pick, or revert while conflict work may exist.

Default: <!-- guardrail:conflict-transition.inventory-before-abort-continue -->

• Inventory operation state and resolution work before running abort, continue, skip, or finalize commands.

Must:

• Inspect git status --short, git diff, and git diff --cached.
• Identify operation type, conflicted files, staged resolutions, unstaged resolutions, and files that would be discarded or finalized.
• Route destructive abort/recovery to undo-recover unless the user explicitly asks for a narrow abort here after risk is explained.

Must not: <!-- guardrail:conflict-transition.no-auto-continue-or-abort -->

• Treat conflict resolution progress as permission to continue.
• Treat abort as a harmless cleanup action.
• Continue or abort automatically after resolving files.
• Run git merge --abort, git rebase --abort, git rebase --continue, git cherry-pick --abort, or git cherry-pick --continue without the required inventory and exact confirmation.

Requires explicit confirmation:

• Exact operation action and command class: abort, continue, skip, or finalize.
• Acknowledgement of staged or unstaged resolution work that may be discarded or committed into the operation.

Verification:

• Verify operation state and git status --short after the confirmed abort or continue.
• For rebase or cherry-pick continuation, verify log/status context after the operation step.

Tool Rules

Allowed:

• inspect conflict state and side versions,
• edit conflicted files narrowly,
• run targeted tests/builds,
• stage only resolved files.

Requires explicit confirmation:

• side-based resolution for a file,
• delete/modify decisions,
• continue operation,
• abort operation,
• generated/lockfile overwrite,
• any R4/R5 history-impacting action.

Forbidden:

• global ours/theirs,
• unrelated staging,
• reset/clean/destructive cleanup,
• remote/shared mutation.

Verification

Minimum verification:

• no conflict markers remain in resolved files,
• git status or equivalent shows no unresolved paths for files marked resolved,
• staged files are exactly resolved files,
• targeted tests/builds run when discoverable and proportional,
• continuation state verified after explicit continue.

For R5 history-impacting continuation or abort:

• show operation state,
• show current commit/ref context,
• state rescue/rollback or route to undo-recover,
• verify resulting status/log.

Output Contract

Final response should include:

## State

- Operation type and conflicted files.

## Resolution

- Files resolved and rationale.

## Evidence

- Ours/theirs/base/context inspected.

## Verification

- Marker/status/tests/continue checks.

## Remaining Risk

- Ambiguous semantics, unrun tests, or follow-up operation steps.

Stop / Confirmation Rules

Stop when the repository state is dirty, conflicted, diverged, missing required evidence, or ambiguous in a way that could overwrite user work, invalidate the requested scope, or require a gated action.

Requires explicit confirmation for:

• delete/modify choices,
• side-based file resolution,
• operation continuation,
• operation abort,
• destructive cleanup,
• history-impacting rebase/cherry-pick continuation.

Lazy-load References

Load:

• references/conflict-types.md for conflict classification.
• references/resolution-strategies.md for semantic resolution choices.
• references/commands.md when command choice is needed.
• references/failure-modes.md for risky or ambiguous states.
• references/verification.md for continuation or R4/R5 verification.