Code review

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 page

FAQs

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