The asymmetric-information problem of code review is that the reviewer doesn’t have your context — and it’s your job to close that gap before you ask for review. This skill structures that closing. Most late-start engineers either over-explain (long PR descriptions nobody reads) or under-explain (one-line “fixed bug”); both failures cost reviewer goodwill. This skill helps land the middle.

What it does

Walks you through preparing a piece of work for review: summarizing what changed, why it changed, what you tested, what you couldn’t test, and what kind of feedback you actually want (correctness check? design review? final approval?). Returns a PR description and reviewer-orientation note that respects the reviewer’s time.

Who it’s for

MS holders early in their first industry role, where social capital with senior engineers is a real currency
Career-switchers whose previous-career writing instincts (long, complete) don’t translate to engineering review etiquette (short, structured)
PhDs whose default communication style is the dissertation chapter — and the receiver expects a one-page summary

What to watch for

Don’t substitute the description for the work. A great PR description on a half-baked diff just tells the reviewer you wasted both your time
Specify the kind of review you want. “Looking for correctness” and “looking for design feedback” produce very different reviews. Saying which up front saves a round trip
Self-review before requesting. The skill helps you write the description; reading your own diff first catches things that would have wasted the reviewer’s time

Verdict

The communication half of code review, finally treated as a skill instead of a vibe. Install before your first big PR in a new role. Pair with receiving-code-review for the other half of the loop.