Why every PR Quorum review is posted with event:COMMENT — never request_changes — and how the advisory framing changes how teams actually use the panel.
PR Quorum reviews are posted with event:COMMENT, the system prompt asks for findings rather than demands, and the verdict at the top of the summary is a label. This is deliberate: the bot should earn attention before it earns power.
A blocking AI reviewer puts the model in the merge path. That is a place where false positives are very expensive: every wrong "request changes" makes a human do work, and the human has no good way to disagree except to override the bot. After two or three of those, the team learns to ignore it. After ten, they disable it.
Advisory framing inverts the dynamic. A useful comment is read; a useless one is dismissed; nothing about the merge changes. The bot earns trust by being right often enough to be worth reading, not by being load-bearing.
It does not mean low-effort, low-confidence, or "it is just a suggestion so we do not have to be careful." The opposite, actually — because the bot cannot block merge, it has to earn its place by being signal-dense. The min_confidence floor, the dedup, and the inline-comment cap all exist because advisory framing forces us to be ruthless about what reaches the PR.
Some teams eventually want enforcement around specific security or release rules. That should be explicit, narrow, and owned by the team. The default PR Quorum review path stays advisory because trust comes before enforcement.
PR Quorum turns specialist reviewer output into one clean GitHub review, with noise controls and predictable usage caps.