LGTM

LGTM asks the reviewer two or three questions about the pull request they just approved. The questions come from the diff, and the result is reported as a check run.

It is not a code reviewer. It has no opinion on whether the change is good, only on whether anyone read it.

What it is not

Friendly by design. It hands you the docs first, gives unlimited attempts, keeps no score, and can never mark a review as failed. The worst it does, and only when you ask it to, is hold a merge until someone answers. See enforcing.

Shape

• A GitHub Action. Two workflow files, two secrets, no server. Each repo supplies its own model key, so adoption costs the adopter.
• No database. Quiz state lives in the comment and the check run, configuration in .github/lgtm.yml.
• The answer key is never published. The comment carries a keyed hash per correct option, authenticated so an edited quiz is reissued rather than graded.
• Approvals reach privileged code by relay, because pull_request_review gets no secrets on a fork pull request. The relay artifact is treated as untrusted.

How the questions are generated

The file list is screened first, so the common skip (too many files, all generated, all exempt) costs nothing. Then three stages run on the diff:

1. Propose. One call reads the hunks and writes candidates about what the change does: what a new guard prevents, which edit touches existing rows, what an error path now returns. It is told not to ask about statistics, naming, or formatting.
2. Verify. Each candidate goes to an independent call that never saw the proposer's reasoning and is told to refute it. A candidate survives only if that call agrees the answer is right, the question is answerable from the diff alone, and someone who skipped the diff could not guess it.
3. Ground. The cited file and hunk are checked against the parsed diff in code, and the options are checked for structural tells, such as a correct answer much longer than its distractors.

Everything is conservative in one direction. A candidate that cannot be confirmed is dropped, and a quiz with no survivors is not posted: the check concludes neutral. Asking nothing is fine. Asking something wrong fails a reviewer who did their job, which is the one failure this tool cannot recover from.

Asking a question back

Mention @lgtm at the start of a line in a pull request comment. Background questions get answered, with web search where a source helps: what is a CRDT, why SELECT FOR UPDATE here, link me the idempotency docs.

Questions that ask LGTM to read the pull request for you are declined: what does this do, is this safe to merge, any bugs. You get a pointer at which file answers it, never the answer. Ambiguous questions resolve toward declining, because answering one of those costs you the understanding you are about to put your name on.

Write access only, meaning OWNER, MEMBER or COLLABORATOR, the same standing a waiver requires. Everyone else is ignored silently, and the reason goes to the workflow log rather than the thread. Set answerQuestions: false to turn the feature off.

Next

• Install, which is two workflow files and two secrets.
• Configuration, every field of .github/lgtm.yml.
• Enforcing, for when an unanswered quiz should hold a merge.

The same questions run in your terminal before you push, from sp lgtm, and both read the same configuration file.