Code Review Workflow

Core Principles

MCP-first analysis — Use Roslyn MCP tools before reading source files. detect_antipatterns catches more than manual scanning, get_diagnostics finds what the compiler knows, and find_references reveals blast radius. Only read files for context that tools can't provide.
Structured output — Every review follows the same format: Summary → Critical → Warnings → Suggestions → Architecture Compliance → Test Coverage → What's Good. Consistent structure makes reviews actionable and scannable.
Severity-based findings — Categorize every finding as Critical (must fix before merge), Warning (should fix, creates tech debt), or Suggestion (nice to have). Never mix severities — a cosmetic issue next to a security bug buries the important finding.
Actionable suggestions — Every finding includes: what's wrong, why it matters, and how to fix it. "This is bad" is not a review comment. "This creates N+1 queries because X. Fix by adding .Include() or using a projection" is.
Acknowledge good work — Always include a "What's Good" section. Positive reinforcement of good patterns is as important as flagging bad ones.

Use for non-trivial PRs (3+ files changed, new features, refactors). Execute steps in order: