Warden

The deciding trait is that the rule you write runs in both places. You define a review once as a Skill, and the same thing runs from your terminal before you push and again on the pull request, so the feedback you get in CI is never a surprise you could not have seen earlier. That symmetry is what makes teams actually keep their review rules current.

You will need someone to write those Skills, and a generic one will not earn its keep. Pick it if you have conventions worth encoding. Pick a hosted review bot if you want opinions ready-made.

The --fix flag is the part to think about. The same system that decided something was wrong then writes the correction and applies it, with no independent check between the finding and the change. A false positive stops being a comment you dismiss and becomes a commit you have to notice.

There is a second concern in the same place: findings arrive as suggested fixes on a pull request, which is exactly the format people accept without reading. What it does right is the reporting path. Everything lands in Checks, so a review that ran and found nothing is distinguishable from one that never ran.

1. There is an eval framework for the reviews themselves, which is the rarest thing on this board: a tool that treats its own output as something to be measured rather than asserted. A review agent without one is a source of opinions with no error rate. 2. That framing also makes the Skill the unit of evaluation, so a team can improve one rule without disturbing the others.

2. No results from that framework are published, so the apparatus exists and the numbers do not. Still, the apparatus is the harder half.

This is the only entry in its group with a real company behind it, and that changes every answer. Sentry has revenue, a sales motion and an existing relationship with the exact buyer this needs, which is why the eighteen-month question does not really apply here; the risk is deprioritisation, not death.

Moat: distribution, which is the only durable one in this category. Moving upstream from watching production failures to preventing them in review is the obvious adjacent market and they are early. Likely acquirer: none, they are the acquirer. Position: the safest longevity bet among the review tools on this board.

It runs as a GitHub Action on every pull request, which is the only integration point that matters to me: no seats to provision, no desktops to manage, and the cost is a model key rather than sixty licences. The whole rollout is a workflow file and a review of what we let it comment on.

The gaps are the usual ones for a young tool: no identity integration of its own and no retention statement. It comes from a vendor we can already put a contract in front of, which is worth more than any feature here. Approved with conditions: comment-only until we have watched it for a quarter.

The licence is the catch. FSL-1.1-ALv2 is source-available, not open source, with a delayed conversion to Apache-2.0, which means today I can read it and tomorrow somebody else decides what I may do with it. I would rather have that stated plainly than dressed up, and Sentry does state it plainly.

The design decision I like is that Skills come from the conventional directories other tools already use, so the rules I wrote for one agent are the rules this one runs. No MCP client and no local endpoint, so the review always happens against somebody's hosted model.