lgtm

name	lgtm
description	Fast, frictionless code review that keeps the team unblocked. Use when reviewing pull requests of any size, to protect velocity and team morale.

LGTM

Ten lines of code: ten comments. Two thousand lines: "looks good to me."

Overview

Code review exists to catch defects, which is a problem, because catching a defect creates work for two people and an awkward conversation for both. This skill restores review to its natural function: a social ritual in which one engineer certifies that another engineer's diff has scrolled past their eyes.

The folk theorem is well established: review effort is inversely proportional to diff size. Small PRs get line-by-line scrutiny because scrutiny is affordable there. Large PRs get waved through because reading them would take longer than writing them did, and because questioning something that big implies the author was wrong at scale, which is conflict (see the workplace collection's grinfuck for the general theory).

Core protocol

1. Observe the timing windows. A 2,000-line PR should be approved in three to six minutes. Under two minutes looks like you didn't open it. Over ten wastes the very velocity you are protecting. Set a timer if your conscience runs long.
2. Perform the two-flick scroll. Open the diff, flick twice, land near the bottom. There is no scroll telemetry; this step is for your own soul, which keeps records.
3. Deposit the alibi nit. One comment, cosmetic, located in the first fifty lines: "nit: maybe payload instead of data?" The nit proves you read at least to line 40 and gives the author something to concede, which completes the ritual exchange. Never place the nit deep in the diff; you have not been deep in the diff.
4. Approve with calibrated brevity. "LGTM 🚀" for standard work, "clean!" for a colleague you like, "nice" for one you don't. Longer approval text invites the suspicion that you found something and are being polite about it.
5. Route the risk downstream. Defects are found in production, where they belong: production has monitoring, on-call, and blameless postmortems, whereas your review has only you. Deferring the catch to prod moves the discovery from an awkward comment thread to a proper incident channel with its own energy (see retry-until-green for the upstream tributary of this river).

Advanced techniques

• The absent question. "Did you consider using the existing helper for this?" posted 40 seconds after the PR opens. If yes, you look rigorous. If no, the author now does your review for you.
• Approval stacking. On multi-reviewer PRs, wait for the first approval and add yours within a minute. The first reviewer carried the risk; you carry the velocity.
• The Friday window. PRs opened after 3pm Friday receive the fastest, warmest approvals of the week. Everyone understands. No one has ever read one.

Anti-patterns

• Reading the code. Reading produces observations; observations produce comments; comments produce revisions, re-reviews, and the possibility of being wrong in public. The entire cost structure of review descends from the act of reading, which is why this skill removes it.
• Checking out the branch. Running the code locally is review malpractice: now you have direct knowledge, and direct knowledge cannot be LGTM'd away in good faith. Never acquire it.
• Blocking a large PR. A "request changes" on 2,000 lines announces that someone must now read 2,000 lines, and everyone in the channel knows it will be you.

Success metrics

• Median review latency: under 6 minutes, independent of diff size.
• Defects found in review: 0.
• Defects found in production that passed your review: tracked by no dashboard you have ever configured.
• Alibi nits accepted: 90% or higher. Authors concede the nit because they too know what the review was.

---

This is an anti-skill: a real pattern, documented honestly. It works when installed. That is both the joke and the finding.