| name | review-pr |
| description | Use when reviewing a pull request, checking a diff, or doing code review in the SMG repository — enforces systematic subsystem-aware review |
SMG PR Review
The Iron Law
NO REVIEW APPROVAL WITHOUT CHECKING ALL TOUCHED SUBSYSTEMS
If you haven't mapped the changed files to checklist sections, you cannot start reviewing.
The Hard Gate
Do NOT write review comments, approve, or provide feedback until you have:
1. Fetched the full diff
2. Listed every changed file
3. Mapped each file to the checklist sections below
4. Created a task for each applicable section
Process
1. FETCH: Get the PR diff (gh pr diff <number>)
2. MAP: List changed files → match to sections using the file-to-section table
3. TASK: Create one review task per matched section
4. CHECK: Work through each task, flag issues as blocker/suggestion/nit
5. ANTI-PATTERNS: Read @anti-patterns.md for the touched subsystems
6. SUMMARIZE: List all findings with severity and file:line citations
File-to-Section Mapping
| Files Changed | Review Sections |
|---|
crates/protocols/src/ | 1 (Layering), 3 (Worker Lifecycle) |
model_gateway/src/config/ | 2 (Config Plumbing) |
model_gateway/src/main.rs | 2 (Config Plumbing) |
model_gateway/src/service_discovery.rs | 3 (Worker Lifecycle) |
model_gateway/src/worker/, model_gateway/src/workflow/steps/local/ | 3 (Worker Lifecycle) |
model_gateway/src/policies/ | 4 (Routing Policy) |
model_gateway/src/routers/ (incl. anthropic/, gemini/, responses/, conversations/, grpc/) | 1 (Layering), 4 (Routing Policy) |
model_gateway/src/middleware/ (scheduler, tenant_resolution, rate limit) | 1 (Layering), 10 (Architecture) — no dedicated section yet |
crates/tool_parser/src/ | 5 (Parser Changes) |
crates/reasoning_parser/src/ | 5 (Parser Changes) |
crates/data_connector/src/ | 6 (Storage) |
bindings/ | 2 (Config Plumbing) |
| Any file | 7 (Error Handling), 8 (Testing), 9 (Code Quality) |
Sections 7, 8, 9 always apply. Section 10 applies to PRs touching 3+ files or adding new types.
Review Checklist
1. Layering & Separation of Concerns
2. Config Plumbing
3. Worker Lifecycle & Label Pipeline
4. Routing Policy
5. Parser Changes (Tool / Reasoning)
6. Storage / Data Connector
7. Error Handling
8. Testing
9. Code Quality
10. Architecture Smell Tests
- "If I remove K8s, does this change still make sense?" → shouldn't be in
crates/protocols/
- "Can existing config overrides or labels achieve this?" → may be unnecessary
- "Does this compose with DP-aware mode, PD disagg, mesh HA?" → don't break existing
- "Is this Send + Sync safe under concurrent load?" → all routing state thread-safe
- "Did I check both HTTP and gRPC paths?" → dual-mode is easy to forget
See @anti-patterns.md for subsystem-specific anti-patterns.
Rationalization Prevention
| Excuse | Reality |
|---|
| "This change is small, I can eyeball it" | Small changes cause the biggest bugs — the two-path config rule is a one-line omission. |
| "I know this code well" | Familiarity breeds blindness. Use the checklist. |
| "It's just a config change" | Config changes touch the most layers (CLI → types → main.rs → bindings). Check section 2. |
| "Tests pass so it's fine" | Tests don't catch layering violations, missing bindings, or one-path config bugs. |
Red Flags — STOP
- About to approve without mapping files to sections
- Skipping a section because "it doesn't apply" without checking the mapping table
- No file:line citations in review comments
- Approving a config change without verifying both conversion paths
- Reviewing without fetching the actual diff first