Finding tier (๐ฏ Actionable / ๐ก Suggestion / ๐ Nitpick)
A finding tier is the priority tag LGTM stamps on every inline review comment: ๐ฏ Actionable (fix before merge), ๐ก Suggestion (worth considering), ๐ Nitpick (take it or leave it). Tiers let reviewers triage a wall of comments in seconds.
Why tiered findings matter
A PR with 12 inline comments is intimidating. A PR with 12 inline comments โ 2 ๐ฏ Actionable, 3 ๐ก Suggestion, 7 ๐ Nitpick โ is a triage list. The reviewer knows immediately: fix the two red ones, glance at the three yellow ones, ignore the seven grey ones if you're in a hurry.
Without tiering, every finding demands the same amount of reviewer attention. The 7 nitpicks drown out the 2 real problems. Tiering reverses that.
The three tiers
๐ฏ Actionable โ critical or high severity. The finding describes something that will cause a bug, security incident, performance regression, or user-visible failure in production. The synthesizer's verdict weights these heaviest; a single Actionable finding is usually enough to Request Changes.
๐ก Suggestion โ medium severity. The finding describes a real improvement โ a cleaner pattern, a more idiomatic API, a missing edge-case handler โ but not something that blocks merge. Reviewer discretion.
๐ Nitpick โ low severity or informational. Style preferences, minor naming, opportunities for future refactor. Post-only; the synthesizer never Requests Changes on these alone.
How the tier is decided
Each finding's severity (critical / high / medium / low / info) maps deterministically to a tier: critical + high โ ๐ฏ Actionable, medium โ ๐ก Suggestion, low + info โ ๐ Nitpick. The mapping is not LLM-decided โ it's a fixed function of the severity field, which itself comes from the agent's structured output.
Security-agent findings carry an additional category from the 40-class vulnerability taxonomy (sql-injection, xss-reflected, jwt-alg-confusion, prompt-injection, etc.). Categories like sql-injection default to critical โ Actionable; categories like weak-random-generator can be low โ Nitpick depending on context.
How the synthesizer uses tiers
The verdict logic is: any ๐ฏ Actionable finding โ REQUEST_CHANGES. All ๐ก Suggestion or below with no Actionable โ COMMENT. All ๐ Nitpick or below โ APPROVE (or COMMENT if the PR asked for review). Confidence scores on top of that: an APPROVE with 8 Nitpicks reads different from an APPROVE with 0 Nitpicks; both surface on the dashboard.
The tier tag also gates the cross-agent dedup logic. When multiple agents flag the same line at different tiers, the highest tier wins โ a bug-agent Actionable trumps a readability-agent Suggestion on the same expression.
See tiered findings on a real review
๐ฏ Actionable ยท ๐ก Suggestion ยท ๐ Nitpick ยท deterministic severity mapping
Go to the product pageFAQs
Can I filter my PR view by tier?
Not in the GitHub UI (GitHub renders all comments in-line). The dashboard does filter by tier โ the /review/<id> view lets you toggle Actionable-only to focus on merge-blocking issues.
Do the emoji render everywhere?
๐ฏ ๐ก ๐ are core Unicode with wide font support (they render on GitHub, Slack, email clients, terminals). We chose them specifically because they degrade gracefully โ even in a plain-text email digest, the shape is recognisable.
Are tier emoji searchable in the PR conversation?
Yes โ GitHub's PR search matches on the emoji. Query "๐ฏ" inside a PR to see just the Actionable comments. Useful for post-review triage.
Related across LGTM
Related terms
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.
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.