Refactor and Integrate

A human has to read, trust, and maintain this work after you leave — code, but also prose, notes, or slides. Every technique here serves that human through two concrete ends:

1. Consistency — the result reads as if one author produced the whole project. New work follows the host's existing conventions (names, utilities, and patterns in code; terminology, notation, and structure in prose), so a reader cannot tell it from what was already there.
2. Minimum reviewable diff — the surviving change is the smallest one that achieves the task. A reviewer reads only what the task needed, with no incidental noise to wade through.

Hold both ends in mind when you hit a change no rule below anticipated: keep what reads as one author's work and serves the task, prune what does not, and raise what you cannot judge.

Load whichever domain skill(s) the work actually touches; each routes its own domain-specific integration reference at the integration stage.

Establish the baseline first

Before triaging anything, fix the governing diff — the playing field for every decision below. It is the set of changes made on this branch since it diverged from the base: git diff BASE...HEAD (three-dot), equivalently git diff $(git merge-base BASE HEAD)..HEAD. When a dispatch hands you an explicit range, use that range.

The minimum net diff is the smallest set of surviving hunks in the governing diff that achieves the task objective. Everything below works toward it.