feat: context-aware reviewer selection for plan and code reviews#3
Merged
feat: context-aware reviewer selection for plan and code reviews#3
Conversation
Instead of running ALL reviewers on every PR/plan, analyze what changed and select the 3-6 most relevant reviewers. This reduces token waste, eliminates noise from irrelevant reviewers (e.g., frontend reviewers on backend-only PRs), and gives the relevant voices more prominence in Abby's synthesis. Plan review: Replace hardcoded all-8-reviewers with a selection guide. Jason Fried always runs (scope). Others selected by plan content (Avi for Rails, Greg for AI, Steve for frontend, etc.). Code review: Replace "run ALL discovered agents" with a selection guide based on file patterns. code-simplicity always runs. Others matched by what files changed (migrations → data-integrity, JS → julik-frontend-races, etc.). Target 4-6 agents per review. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New code review agent focused on Sandi Metz's object-oriented design principles: single responsibility, dependency injection, tell-don't-ask, open/closed, and duck typing over type checking. The existing pattern-recognition agent (also named "Sandi") is a code scanner for duplication, naming, and anti-patterns. This new agent is specifically about OO design quality — whether classes have clear responsibilities, interfaces are narrow, dependencies flow correctly, and code can survive future changes. Added to the reviewer selection guide for Ruby model/service PRs. Registered in plugin.json. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Problem
Both review workflows run every single reviewer on every PR/plan regardless of relevance. A backend Rails refactor triggers the frontend races reviewer. A docs change triggers the performance oracle. This wastes tokens and dilutes the signal from actually relevant reviewers.
How It Works
Plan review — Classifies the plan and selects reviewers by domain:
Code review — Analyzes the PR diff file patterns to select reviewers:
code-simplicityalways runsapp/models/→ architecture, performance, pattern-recognitiondb/migrate/→ data-integrity, data-migration, deployment-verificationapp/javascript/→ julik-frontend-racesBoth announce which reviewers were selected and why before launching.
Test plan
/workflow:2-plan-reviewon a backend plan, verify frontend/Sandy reviewers are skipped/workflow:4-code-reviewon a backend PR, verify frontend reviewers are skipped