v2.23.0

resolve-conflicts now owns the whole merge rather than just the conflicted parts of it, and verifies the cases git reports as clean. Every git behaviour below was checked against real repositories before being written down; two claims the skill previously made turned out to be wrong.

Added

• Cross-side consistency check in resolve-conflicts, with a shipped companion. A merge can combine both sides cleanly and still leave code that no longer agrees with itself — one side renames a declaration while the other adds a reference to the old name. Git reports no conflict, and a diff against either side looks exactly as it should, because the removal and the stale reference never appear in the same comparison. The new scripts/dangling-symbols.sh companion sweeps both directions (they removed something you call, and you removed something they call) and reports surviving references. Retarget it at any language with --keywords; --help documents the rest.
• Clean-tree preflight. A dirty tree does not reliably stop a merge: git aborts only when the incoming change would overwrite the dirty file, so unrelated work-in-progress otherwise survives into the verification diffs with nothing marking it as unrelated. Untracked files stay excluded from the gate — they never reach a diff — but now carry their own documented abort path, since an incoming file landing on an untracked path stops the merge outright.
• bash -n syntax gate for shipped .sh companions, mirroring the existing node --check path for .mjs assets.

Changed

• resolve-conflicts merges with --no-commit. A conflict-free merge previously committed itself before any of the prescribed verification ran, leaving a failed check fixable only by amending or resetting. Conflicted and clean merges now behave identically: the merge stays staged until the commit phase. Fast-forwards are unaffected and need no verification.
• Marker-less conflicts are handled. Modify/delete and rename/delete conflicts (DU/UD) carry no <<<<<<< markers — git leaves the surviving side's content in place, so deciding what is left to resolve by grepping for markers skips those files entirely while they look finished. Conflicts are now enumerated by status code, with the opposite side read through git show :N:.
• Failing tests are baselined against both parents. Red on your branch was previously enough to call a failure pre-existing and move on. But a test red on your side may have been fixed on the incoming one, in which case a red result after the merge means the resolution dropped that fix — the exact dropped-functionality bug the skill exists to prevent. All four ours/theirs combinations now have a verdict.
• Verification split by the question it answers. "Did the resolution keep both sides?" (a diff) and "do those changes still agree with each other?" (the sweep and the test suite) are separate checks, and the second runs even when git reported no conflict.
• pull-requests, pr-review-feedback, and jira-rework route their whole base-sync merge through resolve-conflicts, not just the conflicted case. Each previously restated the post-merge verification itself, precisely because a clean merge never reached the skill. All three now declare boost-requires: resolve-conflicts.

Fixed

• merge-tree exit taxonomy in resolve-conflicts. Unrelated histories exit 128 with fatal: refusing to merge unrelated histories, not exit 1 with the not something we can merge message the skill attributed to them. Exit 128 is now documented as its own case, covering both that and the rejected --quiet + --name-only combination.

Full Changelog: 2.22.0...2.23.0