Pull request review agent
We're adding an agent that does a first pass on every pull request before a human reviewer arrives. Define its lane: what categories of feedback it's allowed to leave, what it must never comment on, and whether it can approve or block anything. How do you keep it from drowning reviewers in nits? Describe the evaluation you'd run before turning it on for the whole team, and then make the case for it to a skeptical staff engineer.
select_pr_comments(comments: list[str], max_comments: int, min_severity: int) → list[str][["missing-tests|8|c1","architecture|9|c2","dead-code|5|c3","naming|7|c4","null-handling|6|c5"],5,4]out["c1","c5","c3"][["doc-mismatch|3|d1","missing-tests|9|d2"],5,4]out["d2"][["missing-tests|4|a","dead-code|9|b","null-handling|7|c","doc-mismatch|6|d","missing-tests|8|e","dead-code|5|f"],3,1]out["b","e","c"]Turn the fuzzy goal into a bounded agent task. Say what the agent reads, what it may do on its own versus draft for a human, and what it must never touch. Then earn the trust: how you’d verify it before rollout, and the pitch (the problem, what you built, why it matters).
Agent build: design the agent in plain language (or narrate it). The coach grades the decomposition, the guardrails, the verification plan, and the pitch.