Prepare a branch for review

Three gates, in this order. Each one is cheap to skip and expensive to skip.

1. Evidence — the suites actually ran, and what's green is what you're pushing.
2. History — the reviewer sees the final logical shape of the change, not the iteration diary.
3. Authorship — the commits and the MR are the developer's, with no tooling signature.

Announce at the start: "I'm using the prepare-merge-request skill before pushing."

When NOT to use: during development — run the single class you're working on and commit freely. This is the pre-push pass.

Gate 1 — Evidence

Core principle: BUILD SUCCESSFUL is not evidence. Two things produce it with zero tests executed — the wrong Gradle task, and the build cache. Evidence is a count of executed tests, read from the JUnit XML result files.

Step 1 comes before the tests on purpose: a green suite on a dirty working tree proves nothing.