Implement the work described by the user in the spec or tickets.

Use /tdd where possible, at pre-agreed seams.

One tree owns the expensive verification, and it is the reviewed one. A gate is priced per tree, and a review changes the tree — so a full suite, a full build or the project's gate run before the review is work over bytes nobody will ship. The measurements that set this rule came from a Swift gate that is now deleted (#1758), and the rule outlived it: run the gate once, on the tree the review left behind. See docs/agents/code-review.md.

The order is the whole of this skill, and nothing runs out of it.

Focused checks while you build. Typecheck often, and run the single test files for the code you changed. Not the full suite, not a full build, not the project's gate.
One review, once the implementation is complete. /code-review, both axes in parallel, in a fresh context that never saw your reasoning. Paste this into every axis prompt, verbatim:

implement