| name | git-rebase |
| description | Resolve Git merge and rebase conflicts conservatively, preserving both sides' intent, staging only understood resolutions, and leaving a git-clean conflict state. |
Git Rebase Conflict Resolution
Use this skill when Compozy asks you to resolve conflicts in an integration
worktree. The goal is a clean merge result, not a clever shortcut.
Core Rules
- Understand every conflicted hunk before editing it.
- Preserve important behavior from both sides whenever possible.
- Prefer the smallest readable merge that keeps the code idiomatic for the
affected language and project.
- Do not delete tests, weaken assertions, suppress lint, swallow errors, or
otherwise hide a failing invariant.
- Do not commit. Compozy owns the final squash commit.
- Do not leave conflict markers in any file.
- If a conflict is unsafe or unclear, leave it unresolved so Compozy can abort
and roll back honestly.
Required Workflow
- Inspect the conflicted files listed in the prompt.
- For each hunk, identify what the integration branch changed and what the
incoming task changed.
- Edit the file so both sides' required behavior is represented.
- Run only language-specific formatting commands that are clearly required for
the files you edited and are safe for this repository.
- Stage resolved files with
git add.
- Check
git status --porcelain; no unmerged entries may remain.
- Report what was resolved and any files that remain unsafe.
Resolution Guidance
- For Go files, keep error wrapping with
fmt.Errorf("context: %w", err).
- For Go files, preserve
context.Context propagation and cancellation behavior.
- Preserve synchronization ownership; do not introduce unmanaged background
work.
- Keep tests focused on behavior and invariants, not implementation details.
- When both sides add cases to a table test, combine the cases unless they prove
the same invariant twice.
- When both sides alter an interface, update every implementation instead of
guessing from the conflicted file alone.
Fail-Honestly Criteria
Stop and leave the conflict unresolved when:
- you cannot tell which side owns the invariant,
- resolving would require deleting behavior from either side without evidence,
- conflict markers remain, or
- a binary/generated file conflict cannot be validated safely.
Compozy will roll back the integration branch when resolution is exhausted, so
an honest unresolved conflict is safer than a speculative broken merge.
