Resolve Git merge and rebase conflicts by reconstructing both sides' intent, classifying conflict types, preserving invariants, and verifying the integrated result before Git continues.
A conflict can disappear from git status while the code is still wrong. One side's validation can vanish, a deleted file can quietly return, or a clean textual merge can leave duplicate registrations and incompatible assumptions across files. This skill reviews the operation as an integration problem, not a marker-removal exercise.
It inventories the Git state and unrelated changes, reconstructs both sides from commits and tests, classifies each conflict, records the invariants the result must keep, and chooses a path-level resolution. It has specific rules for rebases, modify-delete conflicts, renames, migrations, generated files, lockfiles, binaries, submodules, and semantic conflicts with no markers. The final report separates checks that passed from checks that were only proposed and gives an honest continue, risk, decision, evidence, or unresolved verdict.
Use it during a merge, rebase, cherry-pick, or revert, or before integrating two refs that are likely to conflict. A bundled read-only checker validates the structure and internal references of a JSON resolution record. It does not inspect Git or claim that commands ran.
Input
Our target branch added per-tenant rate limits and changed `TooManyRequests` to include `retryAfter`. The incoming branch adds a global circuit breaker and edits the same middleware. Git shows one content conflict. Existing API clients depend on error code `RATE_LIMITED`; the new circuit-breaker tests expect `SERVICE_BUSY`. Resolve the conflict without dropping either behavior.
Output
A merge-state inventory; target and incoming intent ledger tied to commits, contracts, callers, and tests; separate tenant-limit and circuit-breaker invariants; a composed middleware decision that preserves both documented error contracts; a note about ordering and retry metadata; targeted and integration verification; and a continue verdict only if both behaviors and the clean-index checks pass.
Provide the repository or relevant diffs, the merge, rebase, cherry-pick, or revert state, the target and incoming refs, and any local issue or PR context. The skill starts read-only, builds a two-sided intent ledger, resolves or plans each path from explicit invariants, and reports whether Git can safely continue. It will not use destructive Git shortcuts or treat a clean index as proof that the integrated behavior is correct.
A local repository with the relevant commits or refs. An exported status, diff, and commit history can support a plan when direct repository access is unavailable.
The intended merge, rebase, cherry-pick, or revert goal plus any locally available issue, PR, API, schema, migration, or product-decision context. Missing authority stays visible.
Targeted tests, type checks, builds, linters, generators, package-manager versions, or other repository-specific checks when available. Unrun checks are never reported as passed.
Required only for the optional read-only JSON resolution-record checker. It uses the standard library and writes findings to stdout.
SKILL.md; conflict classification, evidence, stop-gate, and verification rubric; human-readable and machine-checkable resolution report templates; read-only resolution-record checker; Agent Skills interface metadata
No reviews yet.
Input
While rebasing a six-commit branch, commit three conflicts in `pnpm-lock.yaml` and migration `0042_add_status.sql`. Main already has a different migration numbered 0042 and uses pnpm 10. The feature migration has been applied on a shared staging database. Explain the safe resolution and what must happen before `rebase --continue`.
Output
A rebase-aware explanation that names commits instead of trusting ours/theirs labels; a deployed-history stop gate for the migration identifier; a plan that preserves applied migration history rather than renumbering blindly; lockfile regeneration from reconciled manifests with pnpm 10; targeted schema, frozen-install, build, and migration checks; and a blocked verdict until staging history and the authoritative migration decision are confirmed.
Input
The target branch deletes `legacy-export.ts` as part of a cleanup. The incoming branch modifies it to support CSV escaping requested by one enterprise customer. The delete commit says 'unused', but a scheduled job still imports the module through a dynamic path and there is no product decision about ending the export. Decide how to resolve it.
Output
A modify-delete classification; evidence that the file deletion and export behavior are separate decisions; the dynamic consumer and customer request recorded as conflicting intent; a narrow temporary compatibility option and its trade-off; tests and owner questions; and `blocked-on-decision` rather than silently restoring the file or deleting the capability.
Creator
Mmerquo
