GitHub suggestion block (```suggestion```)
A GitHub suggestion block is a fenced code block (```suggestion) inside a PR comment that renders as a one-click "Commit suggestion" button. GitHub applies the suggestion as a new commit on the PR branch when the reviewer accepts. LGTM emits suggestion blocks for mechanical single-line fixes.
What a suggestion block is
GitHub's PR review UI recognises a special fenced code block: ```suggestion\n<replacement text>\n```. Whenever this block appears inside a review comment anchored to a line range, GitHub renders it as a diff preview with a "Commit suggestion" button. Clicking the button creates a new commit on the PR branch that replaces the anchored lines with the suggestion's contents.
Multiple suggestions can be batched into a single commit via "Add suggestion to batch" — reviewers accept many at once and GitHub squashes them.
The commit is authored by the reviewer, not the PR author. History stays clean.
When LGTM emits a suggestion block
LGTM's schema exposes a codeSuggestion field on each finding. The LLM opts in per-finding when the fix is mechanical, single-line, and unambiguous. Typical cases: == → ===, missing parseInt radix, md5 → sha256, missing await on a Promise, hardcoded string that should be a constant, unpinned action ref that should be a SHA.
The 6 review agents each decide per-finding whether to emit a suggestion. The synthesizer keeps suggestions attached to their findings; the GitHub adapter wraps them in a ```suggestion block before posting the inline comment.
Multi-line refactors, semantic fixes that require judgement, and anything the model isn't confident about deliberately don't emit suggestions. Half-right suggestions are worse than no suggestion.
Detecting acceptance via GraphQL
When a user clicks "Commit suggestion", GitHub fires a pull_request.synchronize webhook (a new commit landed on the PR). It does NOT tell you which suggestion was accepted — that has to be inferred.
LGTM polls the PR's reviewThreads via GraphQL after every synchronize event, looking for threads that are (a) resolved and (b) whose top comment contains a codeSuggestion we emitted. When both conditions hold, we record a positive ReviewFeedback event for that specific finding.
The polling is cheap (one GraphQL call per synchronize) and the signal is high-quality — a user who resolved the thread almost certainly accepted or intentionally applied the suggestion. This gives us the first per-finding acceptance metric that isn't self-reported.
Why this matters for AI review
AI code review has an accountability problem: the tool tells you something is wrong, you fix it, you don't tell the tool whether it was right. There's no feedback loop.
Suggestion-block acceptance closes the loop for the mechanical-fix subset. When 80% of md5-→-sha256 suggestions get accepted and 30% of missing-await suggestions get accepted, we know which agent + finding-type combinations are actually useful and which are noise.
The signal feeds prompt iteration (which findings should the agent stop emitting?) and per-agent precision tracking on the admin analytics dashboard.
Examples
**🎯 Actionable · bugs · L42**
The `==` comparison here silently coerces types. Use `===` to compare strictly.
```suggestion
if (user.id === expectedId) {
```
<sub>Flagged by: bugs, best-practices · click "Commit suggestion" to accept</sub>See LGTM's suggestion-block pipeline
Mechanical fixes only · one-click accept · acceptance tracked via GraphQL
Go to the product pageFAQs
Do suggestion blocks work on private repos?
Yes. Suggestion blocks are a GitHub UI feature, not tied to public/private. Works on both.
Can I disable suggestion blocks?
Suggestion emission is per-finding, chosen by the agent. There's no user-facing toggle today because if a suggestion is emitted, it's already gated on the LLM being confident about a mechanical fix. If you want to skip a suggestion, just don't click the button.
What if the suggestion is wrong?
Don't click it. GitHub only applies the change when the reviewer confirms via the UI. Wrong suggestions are still visible as a code block in the comment — you can copy-paste the diff for context and write your own fix.
Does accepting a suggestion invalidate the review?
GitHub fires pull_request.synchronize when the suggestion commit lands. LGTM re-runs the review on the new head SHA. The acceptance is recorded before the re-review, so it counts even if the new review no longer flags the same line.
Related across LGTM
Related terms
AI code review
AI code review uses large language models (and increasingly multi-agent pipelines) to review pull requests for bugs, security issues, performance regressions, readability, and style — automatically, on every PR, in 30-90 seconds.
LLM code review pipeline
An LLM code review pipeline is the end-to-end system that ingests a GitHub PR webhook, fetches the diff, gathers repo context, runs one or more LLM agents in parallel, synthesizes their outputs, and posts the result back to GitHub as a review with inline comments.
Adversarial verifier (LLM review)
An adversarial verifier is a second LLM pass whose job is to refute every finding produced by the primary review agents. Findings that survive refutation are kept; findings that don't are dropped before they reach the user.