Your code review agent's findings are dismissed by the team about 30% of the time — and the same patterns keep getting dismissed. Specifically, the agent flags every // eslint-disable-next-line as a "suppressed warning that should be re-evaluated," but the team uses these intentionally and consistently rejects the finding. The team has no easy way to analyze which patterns produce dismissals because the findings don't capture what triggered them.
What's the right schema improvement?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
A detected_pattern field turns dismissal data into a learnable signal. Without it, all you know is "30% of findings are dismissed" — a number you can't act on. With it, you can see "94% of eslint-disable-comment findings are dismissed; 6% of unhandled-error findings are dismissed" — and now you know exactly which patterns to suppress in the prompt and which to keep. Naming the trigger turns vague feedback into specific feedback.
Lowering the bar produces fewer findings of all kinds, including the genuinely useful ones. You're cutting both signal and noise rather than separating them.
Some eslint findings are real — disabling the whole category to suppress one common false positive throws out the useful ones too.
Personal ignore lists fragment the team's quality bar — the same finding gets flagged for one developer, dismissed for another. Team-level analysis of dismissal patterns produces team-level prompt updates.