Ehhhhh yeah kinda? Yes, you should spend most of your time on "API Semantics" (what does it look like using this code?), and you should spend a lot less time on "how are the tests?"

but, for example,

Writing good tests massively contributes to good implementation details and API semantics; and test code is also code that needs to be reviewed under more-or-less the same criteria as the rest.

Also - documentation (or, legibility, if you're onboard with self-documenting code) can be more important than either implementation details, and even API semantics, as it can define whether the entire work is useable or maintainable.

I might say instead:

- What will it be like reviewing this code? (style, test coverage, etc - do I have to worry about spotting typos, and other stupid stuff?)

- What will be like debugging this code? (patterns, logging, etc - which might handled by a framework)

- What will it be like altering this code? (documentation/legibility, implementation details, etc - when the business needs change or grow)

- What will it be like using this code? (API semantics, API docs - when I go to build something on top of this)

And then yeah; the top should be entirely automated, and you should (generally) spend most of your time on the bottom.