Reviewable Branch Diffs

Objective

Make the aggregate Git branch diff easy for a human to review. Coding standards describe good code; this skill decides which changes on the current branch should be made to satisfy those standards. Leave unrelated pre-existing violations in place.

The standards themselves come from user instructions, other skills, repository instructions, or tools—not from this skill.

1. Establish the Git baseline

Identify the intended integration branch using Git only:

1. If the user or repository workflow explicitly identifies the integration branch, use it.
2. Otherwise, determine the relevant remote with git remote. If more than one exists, use available Git tracking/configuration information to select the right one; do not silently pick an arbitrary remote.
3. Resolve that remote's default branch via git symbolic-ref --quiet --short refs/remotes/<remote>/HEAD. If the symbolic ref is missing, consult git ls-remote --symref <remote> HEAD when network access is appropriate. This queries the remote's HEAD, not the current checkout's HEAD.
4. Use the resulting remote-tracking branch as the candidate integration branch. A remote default is not proof of the branch's actual merge destination. If evidence conflicts or is ambiguous, establish the target before applying scope-sensitive rules.
5. Ensure the candidate ref is present and sufficiently current (fetch when appropriate).

Inspect the committed changes and the prospective complete working-tree diff: